Or you could just use a window manager that doesn’t change? I’ve had the same desktop env for over a decade and nothing has changed at all. In contrast with windows and osx where we literally cannot opt out.
I just checked, and GNUstep is pretty much alive. Even that change was caused by me wanting to try tiling window managers, not support failure.
It's a little unsettling that there are two ways to get a stable experience: using window manager from 1998 (OK, ok, WindowMaker is still maintained-ish, in fact a very tiny portion of the code written after 1998 is mine :-) ), or getting used to a workflow akin to that of Windows 1.01 (i.e. a tiling WM).
On the bright side, though, yeah, at least we have a choice!
If you don’t like KDE then use LXCE or Enlightenment or any of the other Linux desktop environments that have been pretty static (and have been even longer than KDE).
So yeah, there actually is a lot of choice on Linux and not all of it looks dated.
Not really, unless it's a tong-in-cheek remark. Tiling window managers use virtual desktops and programmable positioning of windows to produce a predictable layout. Windows 1.01 had neither of those.
Add muscle memory to it and, if you can endure the learning/customization curve, you get a very efficient window manager. Whenever I'm alt-tabbing in search of windows in Windows or OSX I feel I'm using old software.
https://github.com/Airblader/i3
The setting
smart_gaps inverse_outer
As far as windows being too small to read comfortably I'd advise you to place no more than 2-3 windows per workspace. For the benefit of those who don't use i3 workspaces are per monitor.
Given 2 monitors you can easily show 4-6 windows which is easily enough context for about any task.
As for this part:
> As far as windows being too small to read comfortably I'd advise you to place no more than 2-3 windows per workspace. For the benefit of those who don't use i3 workspaces are per monitor.
Yeah, this is pretty much where the fiddling comes from.
I don't want to use 2-3 windows per workspace. I sometimes have to work on a piece of code and have 8-10 PDFs open for it -- datasheets, reference guides, schematics and whatnot, at which I want to be able to look from time to time. Sometimes while I'm also looking at the code, sometimes in full-screen (because I'm looking at a big diagram). Sometimes I need to look at a part of a diagram while I'm looking at the code. So I need them to be in the same view as the code. All in all -- including specs, standards, the code window(s), a few xterms -- I easily have 12-15 windows open in order to work on one thing, and it's not really optional.
i3's tabbed view is sort of what I wanted for the PDFs but it's annoying that, if you want to switch to the right one using nothing but the keyboard, you have to go through all of them. You go back and forth, not to the Nth tab (or at least you couldn't back when I tried i3).
That's actually what I liked about ratpoison. Instead of trying to be smart, it just let me multiplex my screen, which is what I really wanted.
I could sort of bend my workflow around all this and, through a complicated set of chords, make use of the whole thing in a productive manner. However, it was anything but convenient. I'm way happier with a floating WM and do a lot less fiddling with the windows.
Of course, I typically end up sticking a terminal or editor or chat window or music player or something in there anyway, because why not?
I have 2x4K monitors at home. Moving to i3 is the best thing that happened to me.
You still have to open them and move them around, especially if you do change your layout eventually.
I actually didn't have that problem when I was using ratpoison, but some applications (looking at you, Eclipse...) don't really work with it. (I know about stumpwm, and I do know Common Lisp, but alas, we just don't get along too well). When I moved to i3, which is greedy with screen space, I actually wrote myself a couple of scripts to handle this situation "gracefully" (automatically pad the screen with empty X11 windows, automatically un-pad them when needed) and bound them to a couple of key combinations.
I mean it sort of worked but at one point I decided I want to spend more time doing fun/useful things and less time hacking on my window manager.
herbstluftwm also has containers something similar
I used to have a screen shot showing me running something like 5 different GUI apps on a Linux system, all of them trying to open a file, each with a completely different file chooser dialog. That's because one app used Motif, one use GTK, one used Qt, and I have no idea what the others used.
https://i.imgur.com/JG7I2hu.png
Odds that it's even worse since this was created?
It's nice, actually; it's finally making the file selection process feel uniform. Too many Java apps are still using random Swing dialogs though...
The push to force sandboxed apps to use the system dialog had the nice side effect of forcing many GUI APIs to actually use the native file pickers, which meant that a lot of non-app-store apps started to use the native file picker. But Java apps don’t automatically get that upgrade.
But they all perform the same function of choosing a file right? What does it matter if they all look the same? I don't understand why anyone would care so much whether the file choosing windows match eachother visually between different apps. As long as I can pick a file effectively, I wouldn't really care if the app had pink sparkles or something. As long as it does what it's supposed to.
File choosers typically allow one to bookmark commonly used directories unfortunately this is per chooser purely for reasons of lack of coordination.
Further despite people asking for it for the last 15 years the gtk version doesn't have a very good way to visually pick out an image in their picker. To date the only good way to pick out an image in a gtk app even GIMP is to open a file manager alongside the application and drag the file into the application or file chooser.
I find it unlikely that most people figure this out.
It's that some have a file type filter and some don't. Some show all files while others hide dotfiles and provide a checkbox to show them. Some show files and directories in the same pane while others show directories in one pane and files in another. Some show ".." in their directory list and you go up by opening that, others do not show ".." and provide a button for going up.
With windows you have an API provided by windows for ui programs, there will be more consistency between apps because of this.
Linux providing a standardized ui API would go against the core philosophy of it and you're not likely going to be able to convince every developer making gui apps for linux to agree on and use only one graphical toolkit.
Like with anything, every os has tradeoffs and downsides, personally I prefer modularity and control over my system to ui consistency.
You do this by having several available implementations of the API as dynamic libraries--one using Motif, one using GTK, one using Qt, and so on.
There would be a per user config setting specifying which implementation the user prefers. If a program wants to put up a file chooser, it can read that, then load the right library and use the API. A program might also have per program settings to override that, to handle the case where a user really does prefer, say, GTK file choosers for most programs but Qt file choosers for some specific programs.
This gives you more UI consistency, makes things more modular than having every program include file chooser dialog code, and gives more control to the user, and doesn't interfere with the developer choosing whatever toolkit they prefer for things other than standard dialogs.
OK, now who's going to do this? At what level would this be implemented at? Would this be at the windows server level? Would I have to pull in GtK, motif, qt and every other library that this API will rely on just to install Wayland or xorg? Will it be at the window manager level? Will I need to pull in GfK, qt, motif etc. for every desktop environment and window manager relying on this API? Which versions of these libraries will this API rely on?
The last graphical app i wrote, I used dlangui for a GUI, should I have been forced to use Gtk or qt despite them being heavier and more complicated than what I needed?
char * result = dlangui_choose_file(...)
char * result = 0;
char * (*standard_choose)() = get_standard_choose();
if (standard_choose)
result = (*standard_choose)(...);
if (result == 0)
result = dlangui_choose_file(...)
1. Check a standard set of configuration locations to see if the system administrator or user has configured a standard file choose dialog [1].
2. If a standard file choose dialog has been configured, the configuration information includes the path to a library that implements it. get_standard_choose() loads that library, gets a pointer to the standard_choose() functions from it, and returns that pointer.
3. get_standard_choose() returns 0 if no standard choose dialog is configured or it runs into problems trying to load it.
If the user wants GTK or Qt file chooser dialogs instead of dlangui file chooser dialogs, you don't have to use GTK or Qt. The user installs a GTK or Qt file chooser library and points to it in their standard dialog configuration.
(I'd expect at some point that toolkits like dlangui would incorporate get_standard_choose() functionality themselves. After that, you'd then just write
char * result = dlangui_choose_file(...)
Same idea for other common dialogs, like color picking, printing, and font selection.
[1] Probably something like check an environment variable first. If it doesn't find a match there, probably then a config file in $XDG_CONFIG_HOME. If no match, then something in /etc.
Inconsistency comes not from modularity but rather from incompetence.
Everyone doubleclicks anyway though.