Whenever I use Lubuntu (any version since the dawn of time including 19.10), I always edit the openbox conf file to make alt-tab and alt-shift-tab switch between windows on all desktops, not just windows on the present desktop. I know I could just ctrl-alt-left or ctrl-alt-right to get to the next desktop and then alt-tab, but it seems counter-intuitive and cumbersome to have to do that. I think new users coming from macOS or Windows would expect alt-tab to switch between all programs on any desktop, so I suggest adding that feature in the openbox conf file.
Description
Status | Assigned | Task | ||
---|---|---|---|---|
Open | tsimonq2 | T100 Lubuntu 20.04 | ||
Resolved | kc2bez | T128 Alt-Tab and Alt-Shift-Tab feature request (openbox conf) |
Event Timeline
I don't oppose this. In fact, I didn't know that was the case. Want to use this as an opportunity to learn packaging/development, @EinarMostad? I'd be happy to teach!
That sounds very interesting, but I am afraid to take on responsibilites that I am unable to fulfil properly. I already have some work waiting with translating LXQt and tsujan tools to Norwegian Bokmål that I should finish before taking on more. But thank you for the offer! :-)
You are right. I have plenty of time to translate the rest. If the offer still stands, I'd be curious to learn about packaging and development! :-)
It's just one of those things that having synchronous communication would be really helpful with. If you join #lubuntu-devel on Freenode, not only will I be there, but so will our whole team of developers, so we can all help together.
It would be good to look into whether or not we can do this with lxqt-globalkeys rather than openbox. You might want to start playing around with that. We made a big effort last cycle to ensure that as much as possible, shortcuts are defined in globalkeys. This has many advantages, among them that we, like LXQt-itself, are more window manager agnostic.
You also may want to take a peek at all the Packaging documentation. It's kind of a mess right now and needs a better entry point (see T114), but Packaging Tutorial and Packaging Example are probably the best places to start.
OK. I am going to brush my teeth in 29 minutes and go to bed. Tomorrow, I have a long work day from 8 to around 20 with some open time in the middle. I will start to read up on the packaging documentation then. Maybe I could get in touch on IRC in that break or in the evening after I come home? (I have a one hour commute home as well.) I am at Central European Time (UTC+1), so that would be somewhere around 15-17 UTC or after 20 UTC.
It makes a lot of sense to do that in LXQt instead of in openbox. Maybe it is possible to pass some xdg-defined command to openbox /xfwm ... Hm.
I'd highly recommended that you get a bouncer and idle in the channel. Otherwise, use Telegram or Matrix. :)
Ok. I would have to look into that as well. It's been a few years since I was on IRC last time.
I *might* be awake 15-17 UTC. 20 would probably be better. Of course, like I said, others are there.
Regarding lxqt-globalkeys, it has three options:
- run an arbitrary shell command
- run a dbus command
- run a few functions that are implemented in globalkeys itself
The last one is poorly documented. We often joke about the "cpp manual," which is to say you need to read the code to figure out how it works. I just spent 10 minutes and couldn't find anything about them, so clearly more than a cursory look is required. Needless to say, that's likely where the solution is.
Ok, so maybe 20 is a good bet then. I am not fluent in C++ (or any other programming language really. In the 90s I did some very entry level 68k Assembler on a microcontroller and played a lot with HyperTalk/HyperCard, so unless the source code is really well commented, the cpp manual will probably be greek to me. I have just started reading a bit about python to dip my toes into the programming water again, but maybe C++ would be more useful?). I like to learn stuff, so hopefully that will help...
For what it's worth, I'm no C++ programmer myself, although I can follow the logic enough to at least try to figure out what's happening. I imagine if you've had any experience with any programming language, you probably know enough to do that.
Maybe I can to a certain degree? I haven't tried, so I wouldn't know. Ok. I need to brush my teeth and go to bed now, but I am looking forward to learning more and hopefully contribute something useful to Lubuntu. :-)
Thank you! I'll be in touch soon. And thank you for giving me this chance to learn and hopefully contribute something! :-)
Just wanted to say that although I am not on IRC right now, I haven't forgotten about this. This day just turned out a bit heavier than expected at work, so I haven't got as far as I thought I would by now. I have read a bit on freedesktop.org about standards for window handling, but haven't had time to look into the source of lxqt-globalkeys or dive deeper into packaging. I also need to set up a VPS with an IRC bouncer. I think tomorrow afternoon and the weekend will be a good time to dive deeper...
I have done some digging and this is what I have found thus far.
Almost possible solution (lxqt-globalkeys):
Add
"[Alt-something] (could not find tab in the conf file, so unsure how it would look here...)
Comment=Next task
Enabled=true
path=/panel/taskbar/next_task" (if the function exists)
to ~/.config/lxqt/globalkeyshortcuts.conf
One might implement it with lxqt-globalkeys with a call to the main panel's Task manager if such a function exists there. However, the problem is that this will only work if the taskbar is in the current main panel. It is by default in Lubuntu, but I (and probably others) change the default look of Lubuntu to my own taste (I have an autohiding panel on the left with only menu, clock, system tray and applet indicators for occasional use and use the runner to launch everything to maximize screen real estate) and hence, none of the shortcuts that use the desktop swithcer or the task bar in this way from the main panel work on my machine presently. I thought I would file a bug, but that bug was already found and no solution to this problem seems near. https://github.com/lxqt/lxqt-globalkeys/issues/139
I have yet to check if there is a function for Next task in the taskbar's source since it seems like a hazardous solution that will only work if people do not change their panel from the default.
Possible solution right now:
Add <allDesktops>yes</allDesktops> to the ~/.conifg/openbox/lxqt-rc.xml in the section that handles window switching (I wrote a blog post to remember how some years ago: https://www.mostad.eu/how-to-make-alt-tab-show-windows-from-all-desktops-in-lubuntu/ ). Lubuntu ships this file anyway. To move the alt-(shift-)tab functionality away from openbox into lxqt-globalkeys, we would have to change the lxqt-rc.xml anyway to remove the window switching and the solution, unless the code changes upstream, would not be dependable for users that customize their desktop by removing the taskbar from the panel (like me).
After some looking in the source of lxqttaskbar (part of the source for lxqt-panel), I was unable to find a function for switching to the next task. I only found the code for switching to a specific task number from 1-10 as is already implemented in Lubuntu at the end of the source code. This means that even if we want to, we cannot use LXQt-globalkeys to get alt-tab and alt-shift-tab to switch between programs on all desktops. Even if we could (say if we made a feature request that was granted), it would only work if the panel was unchanged by the user as the issue above suggests, so it is probably better to just fix this in the config file for openbox.
Sorry for the long delay. I can indeed confirm that the clientActions in lxqt-panel do little more than desktop switching or task switching to a particular task number. I can also confirm that it will likely be problematic even if it was supported based on the bug you mention. I *do* think this is worth mentioning as something to improve. On the other hand, another part of me thinks they'll probably say this is a job for the window manager. And indeed, this is a bit of a window manager-specific task.
That said, I like your fix. How can I help you make this a reality?
Hi again! No need to apoligize! I have been slow to contribute or show up at IRC myself. I have been very busy with work and haven't had the time or energy to do anything more. I am also behind on my previous commitment to translating LXQt, so I think I should avoid taking on extra responsibility with Lubuntu. Maybe I'll be able to contribute more at a later time, but for now I think the money on patreon and the translation is probably all I can give.
Someone just needs to add a few lines to the config file and ship it with Lubuntu and this problem is solved.
This fix is hanging out in proposed and hasn't migrated to the release pocket yet. If someone is adventurous they can upgrade from there and test.