ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
<znarf>
I should probably add that im testing on hyprland, with the libwayland compiled from latest master
znarf has quit [Remote host closed the connection]
znarf has joined #wayland
znarf has quit [Remote host closed the connection]
fmuellner has quit [Ping timeout: 480 seconds]
riteo has joined #wayland
exxxxkc has quit [Remote host closed the connection]
mclasen has quit [Ping timeout: 480 seconds]
KarenTheDorf has joined #wayland
karenw has quit [Ping timeout: 480 seconds]
KarenTheDorf has quit [Remote host closed the connection]
karenw has joined #wayland
bjorkintosh has quit [Quit: "Every day, computers are making people easier to use." David Temkin]
glennk has quit [Ping timeout: 480 seconds]
bjorkintosh has joined #wayland
kts has joined #wayland
kts has quit [Ping timeout: 480 seconds]
rv1sr has quit []
rv1sr has joined #wayland
Brainium_ has quit []
garnacho has quit [Ping timeout: 480 seconds]
<DemiMarie>
When using Xwayland, is there a way to be informed when something clicks outside my window?
<karenw>
There is no portable way no. There might be compositor specific ways?
<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.
<DemiMarie>
The context is that I have a menu I need to dismiss and switching to native Wayland is going to be hard.
<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.
<Consolatis>
usually you'd use xdg_popup.grab() for that
<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.
<karenw>
I assume
<DemiMarie>
1. This application currently uses Xwayland, because GTK3 never implemented tray icons for native Wayland.
<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.
<DemiMarie>
Changing the UX might or might not happen before the end of 2025.
<Consolatis>
IMHO re-implementing xdg_popups using layershell surface will give you nothing but headaches
<DemiMarie>
Consolatis: there is no alternative
<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.
rgallaispou has joined #wayland
<DemiMarie>
The “proper” solution is to reimplement the UI as a desktop-environment-specific plug-in for each supported panel, which won’t happen.
<Consolatis>
personally I'd still need to see an actual reason for absolute positioning
<DemiMarie>
Consolatis: tray icon menus that cannot be expressed using dbusmenu
<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?
<DemiMarie>
Consolatis: no compositor supports it, and forking them is also not an option
<Consolatis>
right. but if you get the change through compositors may support it in the future
<DemiMarie>
xdg-foreign would also need to be extended to support layer shell
<Consolatis>
otherwise you will throw workarounds on top of workarounds
<Consolatis>
re xdg-foreign: no it does not. its all a wl_surface and nothing specific to layershell surfaces at all
<Consolatis>
another option is to run the panel applets in-process obviously
<DemiMarie>
which requires reimplementing them 3 different ways, unless I can run a Qt6 program in a GTK menubar
<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.
<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.
<soreau>
is w-p !52 relevant?
<DemiMarie>
No, since this menu is (far) too complex for any of the D-Bus protocols.
karenw has quit [Ping timeout: 480 seconds]
<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.
<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.
<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)
<Consolatis>
e.g. just *not* using menus at all but a tray icon triggering an application
<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
<soreau>
if you control your own compositor, you can just make whatever special protocols you want and be done with it
<Consolatis>
including the benefit of your stuff not working anywhere else and other stuff not working on your compositor :p
<DemiMarie>
Consolatis: exactly!
<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.
<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.
<soreau>
btw, is there any simple app that uses dbusmenu and tray icon?
<DemiMarie>
nm-applet is the first one that comes to mind
<Consolatis>
from the client side there is also libayatana-indicators
<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..
<soreau>
no idea if it's dbusmenu or what
<Consolatis>
dbusmenu is limited to some basic UI elements
<DemiMarie>
soreau: basically, when one only has a limited amount of time, one does what it takes to get stuff working.
<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
<DemiMarie>
Consolatis: Would the overlay allow dismissing when the user clicks outside?
<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
mxz_ has joined #wayland
<DemiMarie>
What is hacky about that? Serious question.
<Consolatis>
just feels weird to me. /me likes dedicated buttons rather than undocumented side effects like clicking outside of surfaces
<soreau>
but what if the user tries to click on another surface 'through' the transparent window?
<soreau>
wouldn't you need to forward the click or else they have to click twice?
<Consolatis>
yeah, that is also one of "hacky" parts
<Consolatis>
of the "hacky" parts*
<DemiMarie>
What about creating a layer-shell surface, then immediately creating a popup from it?
<Consolatis>
yeah, that should also work
<DemiMarie>
Will that need any of the hacky workarounds, or will it just works?
<Consolatis>
if the layershell surface is created by the external process that also creates the popup I *think* it should just work
mxz has quit [Ping timeout: 480 seconds]
crazybyte has quit [Ping timeout: 480 seconds]
mxz__ has quit [Ping timeout: 480 seconds]
mxz_ is now known as mxz
<DemiMarie>
Consolatis: the problem is that there is no serial to be used for xdg_popup::grab
<Consolatis>
you could try to use the one from the tray icon click I guess
<DemiMarie>
wrong process
<DemiMarie>
serials are per-connection
<Consolatis>
but no clue if that works for all compositors as its coming from a different client
<Consolatis>
yeah.. right
<DemiMarie>
when will a click not cause a focus change?
<dviola>
setting it to monitorResolution makes it huge first, but at least the fonts don't go missing after my monitor goes off/on
<dviola>
I would appreciate some help there
<dviola>
Qt6 changed it to 96 but I want to see if xwayland could make it work properly after my monitor goes off/on
andymandias has quit [Remote host closed the connection]
andymandias has joined #wayland
mxz_ has joined #wayland
<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."
mclasen has quit [Remote host closed the connection]
mclasen has joined #wayland
kts has joined #wayland
fmuellner has joined #wayland
Ramattack has joined #wayland
<Ramattack>
Hi!
<Ramattack>
in terms of hdipi 4k and so... does it matter using wayland or xorg?
<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
<Ramattack>
in the aspect of hdipi handling
<Ramattack>
because in that case perhaps I would have to find alternatives to xdotool or whatever
___nick___ has quit [Remote host closed the connection]
<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
ryanneph has quit [Quit: ryanneph has disconnected]
DodoGTA has quit [Read error: Connection reset by peer]
yrlf has quit [Read error: Connection reset by peer]