00:01 znarf: I should probably add that im testing on hyprland, with the libwayland compiled from latest master
03:25 DemiMarie: When using Xwayland, is there a way to be informed when something clicks outside my window?
03:37 karenw: There is no portable way no. There might be compositor specific ways?
03:37 karenw: But generally, X allowing unprivlidged applications to get global input events is considered a mis-feature and wyaland intentionally doesn't allow that by default.
03:41 DemiMarie: The context is that I have a menu I need to dismiss and switching to native Wayland is going to be hard.
03:43 DemiMarie: One option is to rely on focus changes, but focus changes don’t happen when the user clicks on something that can’t receive focus.
03:43 Consolatis: usually you'd use xdg_popup.grab() for that
03:43 Consolatis: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/main/stable/xdg-shell/xdg-shell.xml#L1253
03:44 karenw: Hmm, if they click something inside an X window, you would be able to get the event. If they click on a wayland window, you'd get a focus lost event.
03:44 karenw: I assume
03:45 DemiMarie: 1. This application currently uses Xwayland, because GTK3 never implemented tray icons for native Wayland.
03:45 DemiMarie: 2. Even with native Wayland this would have problems, because a layer shell surface will used instead of a popup for absolute positioning reasons.
03:46 DemiMarie: Changing the UX might or might not happen before the end of 2025.
03:46 Consolatis: IMHO re-implementing xdg_popups using layershell surface will give you nothing but headaches
03:46 DemiMarie: Consolatis: there is no alternative
03:47 DemiMarie: I can create a popup from the layer-shell surface, but the initial surface must be a layer-shell surface because nothing else provides absolute positioning.
03:48 DemiMarie: The “proper” solution is to reimplement the UI as a desktop-environment-specific plug-in for each supported panel, which won’t happen.
03:48 Consolatis: personally I'd still need to see an actual reason for absolute positioning
03:48 DemiMarie: Consolatis: tray icon menus that cannot be expressed using dbusmenu
03:49 Consolatis: I suggest extending the ext-foreign protocol with a get_popup() request, is there a reason that doesn't work for your use-case?
03:49 DemiMarie: Consolatis: no compositor supports it, and forking them is also not an option
03:49 Consolatis: right. but if you get the change through compositors may support it in the future
03:50 DemiMarie: xdg-foreign would also need to be extended to support layer shell
03:50 Consolatis: otherwise you will throw workarounds on top of workarounds
03:50 Consolatis: re xdg-foreign: no it does not. its all a wl_surface and nothing specific to layershell surfaces at all
03:51 Consolatis: another option is to run the panel applets in-process obviously
03:51 DemiMarie: which requires reimplementing them 3 different ways, unless I can run a Qt6 program in a GTK menubar
03:55 Consolatis: IMHO: if you try to move something to wayland and see that there is an issue not supported with the current wayland protocols (e.g. external processes for something like panels in your case) the best option is to enhance the protocols. This is a long term game. Otherwise the next person does have the exact same issue and comes up with their own work-around or outright says screw that wayland thing.
04:05 DemiMarie: I agree that enhancing the protocols is the right thing to do, but I also need an interim solution until compositors implement the enhanced protocols.
04:10 soreau: is w-p !52 relevant?
04:19 DemiMarie: No, since this menu is (far) too complex for any of the D-Bus protocols.
04:21 DemiMarie: !26 (surface-transactions) would be relevant because it would allow the cross-client sync needed for “every frame is perfect”, but I can’t wait until I get a solution that allows that.
04:22 DemiMarie: That’s my main problem with Wayland: if one only needs something that mostly works, and can’t wait for a proper solution, things get very ugly.
04:27 Consolatis: note that there are also potential solutions outside of the whole embedding thing like having a dedicated xdg_toplevel or (depending on the required UX) dedicated layershell surface that simply gets shown / hidden via SNI at a position either controlled by the compositor (in case of xdg_toplevel) or on a fixed position based on user-config (in case of a layershell surface)
04:28 Consolatis: e.g. just *not* using menus at all but a tray icon triggering an application
04:31 soreau: DemiMarie: I think your main problem is that you're expecting to lean on other compositors to implement things largely specific to your usecase instead of biting the bullet and adopting/writing your own
04:31 soreau: if you control your own compositor, you can just make whatever special protocols you want and be done with it
04:32 Consolatis: including the benefit of your stuff not working anywhere else and other stuff not working on your compositor :p
04:32 DemiMarie: Consolatis: exactly!
04:33 DemiMarie: soreau: A custom Qubes OS-specific compositor is a complete non-starter. If that means hacky solutions that break in corner cases that don’t happen in practice, then so be it.
04:34 DemiMarie: Consolatis: a tray icon triggering an application is the long-term plan, but it still needs to close when the user clicks outside of it.
04:35 soreau: btw, is there any simple app that uses dbusmenu and tray icon?
04:35 DemiMarie: nm-applet is the first one that comes to mind
04:35 Consolatis: from the client side there is also libayatana-indicators
04:36 soreau: so I just ran nm-applet in wayfire and the icon appears in wf-panel tray widget and the menu seems to work fine..
04:36 soreau: no idea if it's dbusmenu or what
04:36 Consolatis: dbusmenu is limited to some basic UI elements
04:38 DemiMarie: soreau: basically, when one only has a limited amount of time, one does what it takes to get stuff working.
04:38 Consolatis: DemiMarie: just from a user perspective, what is wrong with some keybind + showing a fullscreen (potentially partly transparent) layershell overlay and reacting to ESC? Additionally there could be a second path via some tray icon or button + Hide/Close button in the overlay
04:39 DemiMarie: Consolatis: Would the overlay allow dismissing when the user clicks outside?
04:39 Consolatis: and if you prefer it hacky, make parts of the layershell surface transparent to catch clicks and hide it when a click is detected there
04:39 DemiMarie: What is hacky about that? Serious question.
04:40 Consolatis: just feels weird to me. /me likes dedicated buttons rather than undocumented side effects like clicking outside of surfaces
04:41 soreau: but what if the user tries to click on another surface 'through' the transparent window?
04:41 soreau: wouldn't you need to forward the click or else they have to click twice?
04:41 Consolatis: yeah, that is also one of "hacky" parts
04:41 Consolatis: of the "hacky" parts*
04:42 DemiMarie: What about creating a layer-shell surface, then immediately creating a popup from it?
04:42 Consolatis: yeah, that should also work
04:43 DemiMarie: Will that need any of the hacky workarounds, or will it just works?
04:44 Consolatis: if the layershell surface is created by the external process that also creates the popup I *think* it should just work
05:13 DemiMarie: Consolatis: the problem is that there is no serial to be used for xdg_popup::grab
05:14 Consolatis: you could try to use the one from the tray icon click I guess
05:14 DemiMarie: wrong process
05:14 DemiMarie: serials are per-connection
05:14 Consolatis: but no clue if that works for all compositors as its coming from a different client
05:14 Consolatis: yeah.. right
05:16 DemiMarie: when will a click not cause a focus change?
05:17 Consolatis: can't follow
06:14 dviola: is anyone familiar with how xwayland calculates the DPI? my Qt issue disappears if I change those two lines: https://gitlab.freedesktop.org/xorg/xserver/-/blob/xwayland-24.1.4/hw/xwayland/xwayland-output.c?ref_type=tags#L203-204 and set it to monitorResolution
06:16 dviola: that issue: https://github.com/keepassxreboot/keepassxc/issues/8758#issuecomment-2526387774
06:16 dviola: monitor going off/on -> fonts missing
06:16 dviola: not saying it's xwayland fault but I wonder if the DPI is being calculated properly
06:17 dviola: Qt5 is doing:
06:17 dviola: - return QDpi(std::max(virtualDesktopPhysicalDPi.first, 96.0),
06:17 dviola: - std::max(virtualDesktopPhysicalDPi.second, 96.0));
06:17 dviola: rather than set it to 96.0
06:19 dviola: I wonder what this 25.4 is
06:19 dviola: setting it to monitorResolution makes it huge first, but at least the fonts don't go missing after my monitor goes off/on
06:20 dviola: I would appreciate some help there
06:25 dviola: Qt6 changed it to 96 but I want to see if xwayland could make it work properly after my monitor goes off/on
06:41 dviola: I mean, reading that commit sounds like xwayland is doing that on purpose: "However, if the Wayland outputs get reconfigured, or new outputs added, or existing outputs removed, Xwayland will recompute and update the physical size of the screen, leading to an unexpected change of DPI."
06:41 dviola: https://gitlab.freedesktop.org/xorg/xserver/-/commit/b0413b6e99c6b5fbc04229ce64ddf1f41b08e63e
06:42 dviola: but are then apps expected to force the DPI to 96? which is what Qt6 does
06:44 dviola: toolkits/apps
06:56 dviola: I see there's also -dpi but that's probably for non-rootless mode right?
07:34 ofourdan: dviola: check what the compositor reports as the size of the output with "wayland-info -i output"
07:35 ofourdan: (also, keep in mind that are values for the *screen* which may include multiple monitors depending on your setup)
07:37 dviola: ofourdan: http://0x0.st/XhSr.txt
07:37 dviola: single monitor
07:38 ofourdan: these seem plausible
07:40 ofourdan: 25.4 is the size of an inch in mm
07:40 dviola: oh
07:41 ofourdan: the maths are pretty basic really
07:42 ofourdan: I fail to see how there could be a bug there, if something goes wrong it's more likely with the data
07:43 dviola: I see
07:43 dviola: thanks
07:44 ofourdan: there is also an Xft.dpi value in XRDB that some older apps used, check what "xrdb -q" gives
07:45 dviola: it's empty, I've not set anything
07:46 ofourdan: that's not the user feeding it. usually, it's a setting daemon - Have you tried different Wayland compositors?
07:50 dviola: I've tried weston and hyprland, the issue with those
07:50 dviola: nothing in xrdb -q with those either
07:51 dviola: I'm using sway currently
07:52 ofourdan: ah, I was thingking more kde or gnome
07:52 ofourdan: *thinking
07:53 dviola: haven't tried those with this issue but I guess I could
07:58 dviola: let me try kde first
08:02 dviola: ofourdan: yeah, I can't reproduce it on plasma
08:02 dviola: I see it adds Xft.dpi 96 automatically
08:03 dviola: http://0x0.st/XhSH.txt output of xrdb -q in plasma
08:13 dviola: gnome also sets it to Xft.dpi 96 and can't reproduce the issue: http://0x0.st/XhSK.txt
08:19 dviola: I didn't know KDE/GNOME did this by default, and that older software like Qt 5.x required it to work properly, thanks for letting me know
12:12 Ramattack: Hi!
12:13 Ramattack: in terms of hdipi 4k and so... does it matter using wayland or xorg?
12:13 Ramattack: I say because I use some tools like xdotool which seem not to work in wayland and... I had to switch to xorg (with gnome both cases) and wanted to know if wayland could have improvements in this aspect
12:14 Ramattack: in the aspect of hdipi handling
12:14 Ramattack: because in that case perhaps I would have to find alternatives to xdotool or whatever
12:22 soreau: Ramattack: I'm not sure about hidpi, but there is https://git.sr.ht/~brocellous/wlrctl for wlroots compositors
12:24 soreau: but for wayland, usually the compositor has some scale option
12:25 Ramattack: but you mean for just increasing all or.... only the text and icons... I mean for doing it well or... just making twice or... the size?
12:28 soreau: well the clients (apps) should take scale into account
20:24 Consolatis: dviola: QT_FONT_DPI=96 indeed seems to work around the Qt 5 bug for me. Thanks for mentioning it.
20:26 bjorkintosh: is QT 5 not by now obsolete?
20:27 dviola: Consolatis: sure, glad it helps
20:28 dviola: bjorkintosh: yes, there are some apps that still use it unfortunately, but they're in the process of being ported over to qt6
20:30 soreau: same situation with X and wayland.. :P
20:32 dviola: :D
20:33 soreau: dviola: nice find on the qt5 bug, you really went the extra miles :)
20:42 dviola: thanks :)
20:57 dviola: still want to figure out what is causing: https://github.com/ValveSoftware/steam-for-linux/issues/11479
20:58 dviola: not sure it's realistic to find out though (steam being proprietary)
23:51 soreau: dviola: it seems there are reports in that thread saying it happens on X too, and caused by recent steam updates, so yea, probably a client bug and nothing to do with wayland per se