Linux Desktop Environments and Window Managers made a lot of progress in recent years. They sustain by far the comparison with other systems like MacOS or Microsoft Windows.
However, we can expect a bit more, and there is an elephant in the room that no one seems taking care.
You know WMCtrl? You should not
You probably know some command-line tools like WMCtrl, useful to display the list of windows, and to do various tasks, like changing the geometry of a window, list desktops, moving windows, etc.
Most of geeks are using this tool to fine-tune or to perform automated tasks in their Window Manager.
However, the simple usage of such a tool is a sign of a big issue: it’s used because most of DEs do not have a good command-line API.
What I would expect from a good DE/Window Manager is to expose a good command-line API. I mean: every action that can be performed within the GUI should also be performed in console.
Sounds obvious, no?
Yes.
But it’s not done.
Coding is not a user-friendly API
To understand better the issue, let’s take as an example two different DE/Window Manager: AwesomeWM and KDE.
- KDE has amazing features, directly accessed from the GUI.
- AwesomeWM has amazing possibilities, directly accessed from LUA code.
I guess you already understood the issue, but I will develop.
In KDE, you can perform several things through the command line, mainly by using the D-BUS, leading to commands like:
qdbus org.kde.kglobalaccel /component/kwin org.kde.kglobalaccel.Component.invokeShortcut "Window Maximize Vertical"These commands are not well documented (I’m gentle). This is perfectly a “hack”, this is ugly.
For AwesomeWM, this is different. To interact with your Window Manager with scripts, you will need to produce some LUA Code. So you’ll need to know LUA first. I don’t say LUA is particularly complicated, but it’s an additional effort to learn a new language just to deal with some windows and screens.
It would not be a problem if you had just to code “your custom features”, but the issue with Awesome if that everything is a custom feature. So, except if you want to copy paste a config you do not understand, you’ll have to “code” every aspect of your Desktop Environment.
It seems there is no balance between the two: a working and nice environment while offering a good command-line API. Coding is great, but a command-line is better as it opens the way of simple bash scripts.
The issue with events
I know, a Window Manager sends events. With AwesomeWM your can listen to these events and react accordingly. As soon with speak about events, we are tied to a particular system or language.
But hey, geeks want to do simple things. I feel there is no particular need, for a user-friendly API, to get a push event in real-time. Pulling events on a regular basis is probably enough in 99% of cases.
Like mine, explained below.
A typical use-case
I have two monitors connected to my laptop, and I undock my laptop often. I like activities (KDE) or tags (Awesome). I often code “client/server” stuff. Usually, to dissociate the two environments, I open two Kitty terminals. Alt+1 to access the server and associated tools, Alt+2 to access the client and associated tools. Both are located on the “Dev” activity/tag.
If I open a new Kitty session, I expect it to be associated to the “Alt+3” shortcut, but only if Nvim is opened in one of it’s tab.
All terminals should be on screen 1, while my browser is on screen 2, when the laptop is docked.
If I undock my computer, I want all my Kitty terminals to be minimized, and my browser to be maximized.
Good luck to implement that, despite such “algo” is very simple.
Wayland may change the game
Apparently, Wayland is more strict when it comes to Windows Management. You can’t easily control windows, so the “wmctrl” (and other tools) may not be so easily available.
It may change the game, forcing developers to implement a real command-line API to their Desktop Environments.
This is what I hope.
My feeling is that the way DEs and Window Managers expose their features is a bit old-school.
With web 2.0, we have seen the emergence of user-friendly API’s, and it’s like that Windows Managers are still locked in the 1.0 space.
What do I expect?
I am pretty tough and unfair as usual, but the docs of DEs/Window Managers are still locked in the past, visually.
You just have to compare the documentation of a web-API and a Window-Manager API, you’ll smile I guess.
Do you think this page is good?
Or this one?
A lot of effort has to be made to modernize everything.
At the feature level:
- If the DE asks me to make the design of the clock or other icons in the task bar, it’s not for me anymore. I’m too old for this bullshit.
- If I cannot bash-script most of the DE features in X and Wayland using the exact same syntax, I know it’s bad.
To be short:
I expect a full-featured DE which just works on day-1, but with a full command-line API working with Wayland and X, with a user-friendly documentation as we see it for the Web.
And no, don’t reply: “it’s free/open source, contribute”, as I would be ready to pay for the next-level Desktop Environment.
Leave a Reply