Comments (32)
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.
from labwc.
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.
from labwc.
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.
from labwc.
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 ?
from labwc.
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.
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
All
context.
An 'All' context would be perfect for my needs if that is easier.
from labwc.
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.
from labwc.
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.
from labwc.
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.
from labwc.
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.
from labwc.
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?
from labwc.
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.
from labwc.
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.
from labwc.
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.
from labwc.
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!
from labwc.
It's still an action. Normal keybinding should work, depending on how the patch is implemented.
mod + scroll should be bindable, yes?
from labwc.
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.
from labwc.
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
from labwc.
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.
from labwc.
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?
from labwc.
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.
from labwc.
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.
from labwc.
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).
Correct - Frame catches the main application menu on our panel, for example, which doesn't have a frame or any other decorations.
from labwc.
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?
from labwc.
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.
from labwc.
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.
from labwc.
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.
from labwc.
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"
from labwc.
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.
from labwc.
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?
from labwc.
Yes - but it needs to be as a mouse binding so that users can change what triggers it if they wish to.
from labwc.
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.
from labwc.
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.
from labwc.
Related Issues (20)
- middle click button and active applications? HOT 1
- Inhibit idle question HOT 2
- Debian Packaging - Fixing Terminal Recommends HOT 4
- Add user-configurable blocklist for the security-context implementation
- Touchscreen bindings? HOT 4
- tilde symbol in pipemenus might be causing issues with commands? HOT 1
- Set the LANG in $HOME/.config/labwc/environment , It don't take effect on the menu of windows title. HOT 2
- firefox --kiosk: starts but does not show a window at all HOT 10
- Conditional actions example HOT 1
- Flickering with magnifier and gammastep HOT 11
- Plan for release `0.7.3`
- Dual graphic card HOT 1
- gamma control of output 43 failed when launching wlsunset HOT 2
- DnD between wayland and xwayland not working
- [Question] max_render_time adjustment setting? HOT 6
- Labwc allegedly slow to send fractional scale to applications HOT 3
- Assertion failed at `wlr_libinput_get_device_handle()` in nested session HOT 2
- Very odd Thonny behaviour when unmaximising a window HOT 3
- XDG configure state gets out of sync when clients timeout HOT 4
- Modal dialogs appear behind toplevel window if set by layer-shell-qt
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from labwc.