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.
--
v28: win32u: add SNI driver for systray handling
win32u: add a SystrayRunLoop driver interface
win32u: Refactor NotifyIcon driver interface into separate calls.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2808
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.
--
v27: win32u: add SNI driver for systray handling
win32u: add a SystrayRunLoop driver interface
https://gitlab.winehq.org/wine/wine/-/merge_requests/2808
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.
--
v26: win32u: add SNI driver for systray handling
win32u: add a SystrayRunLoop driver interface
win32u: Refactor NotifyIcon driver interface into separate calls.
win32u: add a ShowBalloon driver interface
https://gitlab.winehq.org/wine/wine/-/merge_requests/2808
This MR has a similar goal !3259, but the difference is that this MR aims to only isolate the XDG user dirs and nothing else. This is entirely possible to do through winecfg, but the problem with using winecfg is that you would have to manually run it on every new wineprefix, and therefore to automate this process without winecfg would require a manual removal of the symlinks. My solution was to create a simple on/off environment variable to disable or enable the creation of the symlinks.
--
v2: shell32: Add environment variable to prevent symlinking home folders.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4584
On Sun Dec 3 10:05:54 2023 +0000, Shmerl wrote:
> Ability to use whatever Wayland supports that X11 doesn't. Like proper
> HDR work and such.
I've noticed more overloading in Xwayland when playing oldrunescape, so I'm playing Wayland despite having no keyboard input.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4522#note_54780
>You should test applications to see if a stub actually helps before
sending in an MR.
I do test , if the program is free, but this one isn't, so cannot test.
I think it's just fine to add the stub so that user can test it in the next
release to see if it helps workaround the bug and report back.
Apparently you have access to this program, and already knew the answer.
Please share this info in future in bugreport then.
Op vr 1 dec 2023 om 03:15 schreef Mohamad Al-Jaf (@maljaf) <
gitlab(a)winehq.org>:
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4555#note_54778
On Sun Dec 3 09:48:00 2023 +0000, Snowiiii wrote:
> what are actually are all the advantages of using native wayland ?
Ability to use whatever Wayland supports that X11 doesn't. Like proper HDR work and such.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4522#note_54774
On Sun Dec 3 09:14:08 2023 +0000, Shmerl wrote:
> No particular difference in performance. But I can't compare input due
> to it being broken.
what are actually are all the advantages of using native wayland ?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4522#note_54773