"Desktop" context for mouse bindings doesn't work
spl237 opened this issue · comments
When creating a mouse binding, the "Desktop" context appears to be the same as the "Root" context - in context_from_str in src/config/mousebind.c, both options are translated to LAB_SSD_ROOT.
If I have no application running to draw a desktop, then this works ok - the Root context is then valid. But if I am running an application to draw a desktop (pcmanfm in our case) then the Root context is no longer in effect, so binding to the Desktop context means the binding is no longer in effect. The Frame context also doesn't work for the desktop background.
Is there some valid context for the desktop background?
(Or even a context for "anywhere at all"? I am trying to define a global mouse binding, and I had hoped that setting it for Frame and Desktop would work.)
Is there some valid context for the desktop background?
No, there isn't. I don't think we even check any mousebinds for interactions with a layershell surface.
You could theoretically make your desktop implementation use an empty wayland input region, that should then let clicks "go through" the desktop and thus trigger the Desktop / Root context. That is what for example swaybg is doing.
I am trying to define a global mouse binding, and I had hoped that setting it for Frame and Desktop would work.
Hm.. Maybe we could add some Layershell context (or individual ones like LayerBackground / LayerBottom / LayerTop) or something along that line. Or an All context. Thoughts @johanmalm ?
You could theoretically make your desktop implementation use an empty wayland input region, that should then let clicks "go through" the desktop and thus trigger the
Desktop/Rootcontext.
I don't think that will work for us - the user needs to interact with icons on the desktop, so presumably making it an empty input region will prevent that?
Or an
Allcontext.
An 'All' context would be perfect for my needs if that is easier.
I don't think that will work for us - the user needs to interact with icons on the desktop, so presumably making it an empty input region will prevent that?
Yes, that would prevent any mouse interaction with the surface that owns the empty input region.
Your desktop app is simply another application, not what's referred to as "the desktop" ie, root.
That's why all the settings have the word "context" in front of the name.
When you completely cover the root window, with your desktop app,
then indeed you quit interacting with the root window. Not unlike having a fullscreen window and not being able to interact with the root window.
AFAIK, there is no such thing as a global binding.
What are you trying to accomplish with a global binding?
Edit to add: and yes I'm aware that desktop is not exactly 100% the root, but it's more in the way you look at it. And in wayland, there really is no root window, per se, thus the workarounds to shoehorn
X apps in.
Your desktop app is simply another application, not what's referred to as "the desktop" ie, root. That's why all the settings have the word "context" in front of the name.
When you completely cover the root window, with your desktop app, then indeed you quit interacting with the root window. Not unlike having a fullscreen window and not being able to interact with the root window.
True - but in that case, I would expect the Frame context to respond to mouse bindings on the desktop background, and it doesn't. So there is something different about it from other applications.
AFAIK, there is no such thing as a global binding.
What are you trying to accomplish with a global binding?
I want to have a mouse binding which has the same effect no matter where on the screen the mouse pointer happens to be - I want to be able to set the magnification of the zoomed mode with the mouse scroll wheel, and it makes no sense for that to be location-specific. So I either need a global binding - which I think ought to be fairly easy to implement, and I will try do so tomorrow - or I need some combination of other bindings which cover every possible mouse location, but as far as I could establish in testing today, there is no context which matches the desktop.
I think some global All context (insert-better-name-for-it-here) is the easiest solution, however if you want to use the scroll wheel as trigger I guess we also need some don't relay event to window under the cursor argument for the mousebind. Otherwise it might be slightly confusing to have the magnifier also scroll a website when enabled.
I don't understand the use-case for <context name="All">. If we bind button-press / scroll / whatever to that, it would always happen, wouldn't it? Or are you thinking of combining it with some unusual key-combo?
Well, frame only counts if you have a border, with or without a title/titlebar.
A window with no decorations, no border has no frame.
For something like a zoom mode, I would set a normal key/mouse bind. It's not a menu, it's an action.
I don't understand the use-case for
<context name="All">. If we bind button-press / scroll / whatever to that, it would always happen, wouldn't it? Or are you thinking of combining it with some unusual key-combo?
On our other platforms, Windows key + mouse scroll changes magnification in the zoom plugin. So yes, combining mouse scroll with a keyboard modifier.
Well, frame only counts if you have a border, with or without a title/titlebar. A window with no decorations, no border has no frame.
In which case there is even more of an argument for an "All" context, as that means any other undecorated window will also not respond to the binding.
For something like a zoom mode, I would set a normal key/mouse bind. It's not a menu, it's an action.
See below - for adjusting zoom, a scroll wheel is the best control. I use this myself for adjusting magnification, and it is by far the most intuitive way of doing it.
On our other platforms, Windows key + mouse scroll changes magnification in the zoom plugin. So yes, combining mouse scroll with a keyboard modifier.
Okay, fair enough. Hadn't thought of that one!
It's still an action. Normal keybinding should work, depending on how the patch is implemented.
mod + scroll should be bindable, yes?
It's still an action. Normal keybinding should work, depending on how the patch is implemented. mod + scroll should be bindable, yes?
Yes, but the problem is the context. There is no way I can find at present to have that binding respond at all mouse locations, which is what I need to happen - as above, this binding needs to be global, not specific to certain mouse locations.
Why do you need context, isn't the focused window what you want something done to?
These are the bindings I use when using wayfire
'# Change opacity by scrolling with Super + Alt.
[alpha]
modifier = super+alt
' # zoom window by scrolling with Super + Shift.
[winzoom]
modifier = super+shift
Why do you need context, isn't the focused window what you want something done to?
No. The zoom applies to the area around the mouse cursor, not to a particular window. It is effectively a magnifying glass centred on the mouse cursor; it zooms an area of the screen.
I think some "All" context is fine for mouse buttons and should always eat the events. It would be very strange to have labwc actions bound to any mouse event that is also passed through the window.
Well, it's problematic when you go that direction.
If zoom were applied to the window, just before outputting wouldn't that work better?
ie fractional scale the focused window?
Well, frame only counts if you have a border, with or without a title/titlebar. A window with no decorations, no border has no frame.
AFAIR the Frame context also catches usual windows and popups (but not layer surfaces, xwayland popups or the labwc menu).
If zoom were applied to the window, just before outputting wouldn't that work better?
ie fractional scale the focused window?
Yes that would be better but I don't think that is currently possible with the scene graph API.
If zoom were applied to the window, just before outputting wouldn't that work better? ie fractional scale the focused window?
That isn't the way accessibility magnification works on any other desktop I have seen. They all work by magnifying an area around the cursor.
Well, frame only counts if you have a border, with or without a title/titlebar. A window with no decorations, no border has no frame.
AFAIR the
Framecontext also catches usual windows and popups (but not layer surfaces, xwayland popups or the labwc menu).
Correct - Frame catches the main application menu on our panel, for example, which doesn't have a frame or any other decorations.
Yes that would be better but I don't think that is currently possible with the scene graph API.
I though the scene graph was designed so transforms could be applied just before ouputting to monitor, not correct?
But an application menu or any menu is not a normal window.
Just because something works with a popup, doesn't mean it would or even should work with a normal window, ie application window, the same way.
That isn't the way accessibility magnification works on any other desktop I have seen. They all work by magnifying an area around the cursor.
Then where the pointer is, in this case is the context.
A pointer over an area with scroll should work using the cursor as the center.
No other context needed unless I'm missing something.
You just have to decide how big of an area to zoom.
That isn't the way accessibility magnification works on any other desktop I have seen. They all work by magnifying an area around the cursor.
Then where the pointer is, in this case is the context. A pointer over an area with scroll should work using the cursor as the center. No other context needed unless I'm missing something. You just have to decide how big of an area to zoom.
Yes - but there is no currently-named context which does that; that is my point. If there was a context called “Cursor”, great, but there isn’t.
There is no context currently defined that can be used in a binding which does what I need.
Lets sum this up for now as: we need some kind of All / Global mouse context that either eats events (e.g. doesn't relay them to the underlying surface) or has an additional attribute to do so.
That isn't the way accessibility magnification works on any other desktop I have seen. They all work by magnifying an area around the cursor.
Then where the pointer is, in this case is the context. A pointer over an area with scroll should work using the cursor as the center. No other context needed unless I'm missing something. You just have to decide how big of an area to zoom.
Yes - but there is no currently-named context which does that; that is my point. If there was a context called “Cursor”, great, but there isn’t.
There is no context currently defined that can be used in a binding which does what I need.
bind modifier and scroll key to action, wherever the cursor is, is zoomed, doesn't matter if cursor is over
background, a window, spanning two windows, etc. I don't even see a use for "context"
That isn't the way accessibility magnification works on any other desktop I have seen. They all work by magnifying an area around the cursor.
Then where the pointer is, in this case is the context. A pointer over an area with scroll should work using the cursor as the center. No other context needed unless I'm missing something. You just have to decide how big of an area to zoom.
Yes - but there is no currently-named context which does that; that is my point. If there was a context called “Cursor”, great, but there isn’t.
There is no context currently defined that can be used in a binding which does what I need.bind modifier and scroll key to action, wherever the cursor is, is zoomed, doesn't matter if cursor is over background, a window, spanning two windows, etc. I don't even see a use for "context"
But as far as I know, you have to set a context in all mouse bindings; it’s not an optional parameter. Is that not the case?
If it is possible to just leave the context blank, and that then means that the binding occurs anywhere on the screen, great, that does what I want. But I do not believe that to be the case.
Those context bindings are basically for UI elements, you don't really care about those in what you're trying to do. You want to zoom a certain size are around some point, ie the cursor. Yes?
Yes - but it needs to be as a mouse binding so that users can change what triggers it if they wish to.
Labwc tries to not hardcode behavior if possible. That also includes setting zoom for a potential magnification feature.
So those should be actions (e.g. something like MagnifierIncrease / MagnifierDecrease) that can then be bound to key- or mousebinds. Mousebinds require a context in which they operate and we don't currently have a global context that always matches.
I was just about to ask that question, then if mousebinds don't work outside of context, then you would
need a global context. Though I think it better to make mousebinds the same as keybinds, with the contexts
possibly overridding.
Edit to add: or make scroll wheel a special case, not strictly a part of mousebind.
Since this actions would use the scroll wheel.
PR created - trivial change, seems to work fine. On testing, scrolling over a window without the modifier key held causes the window to scroll; scrolling with the modifier held only triggers the desired mouse binding - so this appears to do what would be expected.