Koge, thanks for the code sample (Bard, thank you, too! ![:-)]( "Smile")
),
The code sample is very useful. However, in the past few days (or is it weeks? anyhow...) I have tried several similar hacks, to no avail. The main reason seems to me to be that Gtk/Gdk (and the underlying Wayfire implementation, limited by the capabilities of the Wayland protocol) does not expose to a Widget like this (obviously, part of a shell, like the wf-panel-pi shell that ships with Raspberry Pi OS) the keyboard layout of the currently focused surface (window, if you prefer), but the keyboard of the Widget itself.
Another weak point I have found by endless browsing through the code (I was and am not a window env expert in any way, I am just learning) is that there seems to be no ready mechanism for such a Widget to get notifications of what happens in other surfaces. I.e., if you type Alt-Shift or whatever your layout switch combo is on another window, the layout in your currently focused window (say, chromium, lxterminal or whatever) changes from EN to EL (or whatever) or vice versa, but Wayfire does not notify anyone. There is no event for layout change that is emitted for anyone (not even the kbdd plugin I posted, which works within the address space of Wayfire) to catch that change.
After searching around, I found that such a "protocol" (in Wayland's own terminology) was once upon a time proposed to be added to Wayland, but never made it. Don't ask me why. Depending on the repository (Wayland has migrated between a couple...) this was Pull Request #31 or #30. Bottom line, there is no such protocol as of today in production Wayland, and of course, Wayfire does not implement it since it does not exist.
In all, it seems to me that a strategy for tackling this would be much more complicated. Google Bard may need one or two generations of upgrades till it can answer this like a human can (by "human" I do not necessarily mean myself...). This strategy would consist of the following:
Disclaimer #2, I am not sure how a Language Switcher Widget (a better version of what you have posted) would be ever able to affect the layout of other surfaces. I fear it would not. Some code I have seen manages to do this in an "on-screen keyboard", which "grabs" the keyboard from all other surfaces. While we hold such a "grab', yes, a switch could work. But when we release it and the focus returns to some other window, in the presence of kbdd which would restore the layout of that window, it does not seem very easy to me, unless we again resort to DBus events. Maybe one day... But anyway, other than for purposes of accessibility for disabled persons, I consider a mouse-click language switch an awful UI/UX, so if I ever manage to make everything else work but click-switching layouts doesn't, I won't weep.
I will keep this thread posted on whatever I manage to accomplish.
),The code sample is very useful. However, in the past few days (or is it weeks? anyhow...) I have tried several similar hacks, to no avail. The main reason seems to me to be that Gtk/Gdk (and the underlying Wayfire implementation, limited by the capabilities of the Wayland protocol) does not expose to a Widget like this (obviously, part of a shell, like the wf-panel-pi shell that ships with Raspberry Pi OS) the keyboard layout of the currently focused surface (window, if you prefer), but the keyboard of the Widget itself.
Another weak point I have found by endless browsing through the code (I was and am not a window env expert in any way, I am just learning) is that there seems to be no ready mechanism for such a Widget to get notifications of what happens in other surfaces. I.e., if you type Alt-Shift or whatever your layout switch combo is on another window, the layout in your currently focused window (say, chromium, lxterminal or whatever) changes from EN to EL (or whatever) or vice versa, but Wayfire does not notify anyone. There is no event for layout change that is emitted for anyone (not even the kbdd plugin I posted, which works within the address space of Wayfire) to catch that change.
After searching around, I found that such a "protocol" (in Wayland's own terminology) was once upon a time proposed to be added to Wayland, but never made it. Don't ask me why. Depending on the repository (Wayland has migrated between a couple...) this was Pull Request #31 or #30. Bottom line, there is no such protocol as of today in production Wayland, and of course, Wayfire does not implement it since it does not exist.
In all, it seems to me that a strategy for tackling this would be much more complicated. Google Bard may need one or two generations of upgrades till it can answer this like a human can (by "human" I do not necessarily mean myself...). This strategy would consist of the following:
- Create indeed a widget like this, it is mostly useful for displaying the current layout (see below about why switching may not work)
- Define a signal in Wayfire that would be emitted for layout changes (requires rebuilding Wayfire, but I have done this already and it is not hard
- Tweak Wayfire's keyboard handling so that it emits this signal when the layout is changed
- Add code to kbdd (or it could be a different plugin) to catch the emitted layout change signal
- Add code to kbdd or to that new Wayfire plugin to emit a DBus signal for other widgets to catch (this is how Wayfire communicates with the shell, so for example, this is what happens if you press the Super (Windows) key on your keyboard, and triggers the drop-down Menu of wf-panel-pi)
- Arrange for the Widget to catch and display the current language
Disclaimer #2, I am not sure how a Language Switcher Widget (a better version of what you have posted) would be ever able to affect the layout of other surfaces. I fear it would not. Some code I have seen manages to do this in an "on-screen keyboard", which "grabs" the keyboard from all other surfaces. While we hold such a "grab', yes, a switch could work. But when we release it and the focus returns to some other window, in the presence of kbdd which would restore the layout of that window, it does not seem very easy to me, unless we again resort to DBus events. Maybe one day... But anyway, other than for purposes of accessibility for disabled persons, I consider a mouse-click language switch an awful UI/UX, so if I ever manage to make everything else work but click-switching layouts doesn't, I won't weep.
I will keep this thread posted on whatever I manage to accomplish.
Statistics: Posted by avarvit — Thu Jan 18, 2024 6:22 am