You are not logged in.

#1 2022-02-14 17:59:18

c03b474d
Member
Registered: 2022-02-14
Posts: 2

ImWheel Alternative Wayland Server

Hello,
I have a little problem with Chromium based software : Brave, Electron, Chrome, Chromium, Freetube, etc.
It seem with the better support of Wayland they start to detect and use native Wayland support so imwheel settings isn't followed (imwheel work only on x11 after all).
So i would like to know if there is an alternative to imwheel or any "patch" to fix the scrolling problem.

Note: please do not propose extension for chromium, brave, because Freetube and electron app in general does not support them.
Note 2: I know it's possible to actually override settings of electron / chromium to force Xwayland and force imwheel to work (what i'm using for now) but i would like a fix to rest on Wayland who is the futur and not rely on Xwayland to long.

Thanks

Offline

#2 2022-02-14 18:57:49

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 30,499
Website

Re: ImWheel Alternative Wayland Server

imwheel interacts with the Xorg server - there is no equivalent in wayland as there is no "wayland server" to interact with.  Wayland is just a protocol.  There are many different compositors that implement the protocol, but there is no shared "server".

So any tool that would replicate imwheel's features would be specific to a given compositor and would require cooperation of the compositor authors.  Really it'd have to be part of the compositor itself, or the compositor would have to expose specific interfaces for the tool.  This is why it's highly unlikely that anyone would write such a tool as it would not be "for wayland" it would be - at best "for sway" or "for plasma" or "for gnome" (these are XORs not ORs).

The only way a imwheel like tool could be used across different compositors would be if there was a new wayland protocol written for it and adopted by the major compositors.  The xdg-shell protocol is an example of such work.  All major compositors now implement the xdg-shell protocol on top of the base wayland protocol, so client programs that use the xdg-shell protocol can run on any of these compositors.  (And all clients do - wayland was really kinda' a joke prior to xdg-shell's wide adoption).

There could not even be menus like dmenu/bmenu that could work on different compositors at first.  Any such menu would have to be built as part of the compositor itself.  Now the layer-shell protocol is fairly broadly supported and allows for these types of menus to function in any compositor that implements layer-shell (though that protocol itself is still technically considered non-standard or "experimental" - though it has become a defacto standard and undoubtedly will be formalized soon enough).

As of yet, there are no protocol drafts that I'm aware of that would allow for the features provided by imwheel.  Someone would have to first write the protocol, then convince all the major compositor authors to implement the protocol, and only then write the actual imwheel-like software.

There may very-well be some software to replicate it, but it would be in the category of browser plugin which you are not looking for.  In theory, there could also be electron settings that could do something like this that would apply more widely - but that'd be up to the electron devs to implement.

Last edited by Trilby (2022-02-14 19:09:07)


"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman

Offline

#3 2022-02-14 20:15:14

c03b474d
Member
Registered: 2022-02-14
Posts: 2

Re: ImWheel Alternative Wayland Server

Trilby wrote:

imwheel interacts with the Xorg server - there is no equivalent in wayland as there is no "wayland server" to interact with.  Wayland is just a protocol.  There are many different compositors that implement the protocol, but there is no shared "server".

So any tool that would replicate imwheel's features would be specific to a given compositor and would require cooperation of the compositor authors.  Really it'd have to be part of the compositor itself, or the compositor would have to expose specific interfaces for the tool.  This is why it's highly unlikely that anyone would write such a tool as it would not be "for wayland" it would be - at best "for sway" or "for plasma" or "for gnome" (these are XORs not ORs).

The only way a imwheel like tool could be used across different compositors would be if there was a new wayland protocol written for it and adopted by the major compositors.  The xdg-shell protocol is an example of such work.  All major compositors now implement the xdg-shell protocol on top of the base wayland protocol, so client programs that use the xdg-shell protocol can run on any of these compositors.  (And all clients do - wayland was really kinda' a joke prior to xdg-shell's wide adoption).

There could not even be menus like dmenu/bmenu that could work on different compositors at first.  Any such menu would have to be built as part of the compositor itself.  Now the layer-shell protocol is fairly broadly supported and allows for these types of menus to function in any compositor that implements layer-shell (though that protocol itself is still technically considered non-standard or "experimental" - though it has become a defacto standard and undoubtedly will be formalized soon enough).

As of yet, there are no protocol drafts that I'm aware of that would allow for the features provided by imwheel.  Someone would have to first write the protocol, then convince all the major compositor authors to implement the protocol, and only then write the actual imwheel-like software.

There may very-well be some software to replicate it, but it would be in the category of browser plugin which you are not looking for.  In theory, there could also be electron settings that could do something like this that would apply more widely - but that'd be up to the electron devs to implement.

Thanks for the answer i was expecting something like that (for wayland even if it's a bad way to name it, saying equivalent wayland, is more clear (at least for me), than naming all the implementation, but i agree it's technically false), it's a shame that Google (chromium) and electron (too many software use it), do not fix these "trivial" (yet extremely annoying) bug.

Last edited by c03b474d (2022-02-14 20:15:55)

Offline

Board footer

Powered by FluxBB