Adds the tray icons implementation based on org.kde.StatusNotifierItem interface usage. Does allow restarting StatusNotifierWatcher object, but will fallback to XEMBED or internal tray, if wine gets initialized when there is no StatusNotifierWatcher object registered.
--
v11: configure: fix winesni.drv not getting disabled
https://gitlab.winehq.org/wine/wine/-/merge_requests/2808
On Thu May 18 20:36:57 2023 +0000, Giovanni Mascellani wrote:
> No, I don't think the caller gets to decide anything. The optimizing
> pass can either decide to alter the instruction stream (if it thinks
> there is some optimization to be done) or leave it unchanged. In the
> first case it returns `true`, in the second `false`. The caller will
> receive whatever stream the pass decides to leave.
> In this case, however, I don't think there is any question about whether
> to touch or not the instruction stream. We definitely want to fold the
> absolute value operation, since it's pretty clear that for the native
> compiler `abs(INT_MIN) == INT_MIN`. The only care we have to use is to
> never call `abs(INT_MIN)` in C, because that's UB. If you use the
> statement I provided above that should never happen and everything is fine.
Ahh, okay that makes sense - I'll go ahead and make this change now; knowing the native compiler's result cleared this up right away!
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/203#note_33148
On Thu May 18 20:32:04 2023 +0000, Ethan Lee wrote:
> If I'm understanding correctly, the folding pass makes a temporary node
> that the fold functions write into - the fold function can either
> successfully inline an op into a constant that can replace the op node,
> or it can't and the temporary node is discarded, leaving the original
> node list alone.
> It sounds like the intended change to the current revision is to always
> assign the full constant value even if it turns out to be invalid - that
> is, the caller can either listen to the return value and discard the dst
> node, or use it at their own risk... does that make sense?
No, I don't think the caller gets to decide anything. The optimizing pass can either decide to alter the instruction stream (if it thinks there is some optimization to be done) or leave it unchanged. In the first case it returns `true`, in the second `false`. The caller will receive whatever stream the pass decides to leave.
In this case, however, I don't think there is any question about whether to touch or not the instruction stream. We definitely want to fold the absolute value operation, since it's pretty clear that for the native compiler `abs(INT_MIN) == INT_MIN`. The only care we have to use is to never call `abs(INT_MIN)` in C, because that's UB. If you use the statement I provided above that should never happen and everything is fine.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/203#note_33147
On Thu May 18 20:30:01 2023 +0000, Giovanni Mascellani wrote:
> I think that what we want is:
> ```
> dst->value.u[k].i = src->value.u[k].i == INT_MIN ? INT_MIN : abs(src->value.u[k].i);
> ```
If I'm understanding correctly, the folding pass makes a temporary node that the fold functions write into - the fold function can either successfully inline an op into a constant that can replace the op node, or it can't and the temporary node is discarded, leaving the original node list alone.
It sounds like the intended change to the current revision is to always assign the full constant value even if it turns out to be invalid - that is, the caller can either listen to the return value and discard the dst node, or use it at their own risk... does that make sense?
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/203#note_33144
On Thu May 18 20:28:51 2023 +0000, Zebediah Figura wrote:
> I don't understand, why would it break the result?
I think that what we want is:
```
dst->value.u[k].i = src->value.u[k].i == INT_MIN ? INT_MIN : abs(src->value.u[k].i);
```
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/203#note_33143