This comment reminds me of this meme image that I saved a few years ago:

https://i.imgur.com/JG7I2hu.png

Odds that it's even worse since this was created?

I found my screen shot: https://i.imgur.com/Wcwaiwu.jpg

Nice. Actually some of these remind me of Windows, too. It's less common on Windows but plenty of applications seem to link against antiquated libraries which provide really unusable and nonstandard file selection dialogs. One thing I remember being annoyed with is old-style ones that are very small and you can't resize. Here are some, but I've seen weirder ones:

https://i.imgur.com/jYa3qX8.png

With sandboxing, macOS is now forcing devs to use their file selection dialog because it will grant access to the selected files - a custom dialog box has no such blessing.

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...

How do the java apps use their own file selection dialogs if they're sandboxed?

Sandboxed Java apps don’t. Here I’m talking about apps that you can’t get on the App Store, many of which are older Java programs which haven’t been updated to use the newer APIs.

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.

>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.

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.

The aesthetics are not a completely invalid consideration. People recognize patterns and find choosing behaviors/reactions easier when recognizing a common pattern. It takes more effort to respond to unfamiliar stimulus. Aesthetics aren't the only consideration though.

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.

The devil is in the implementation details. Are favorites/shortcuts in the same part of the screen? Are they in the same order? Does the dialog remember sort and view configuration between folders? Does the dialog differentiate between mounts, symlinks, and tangible files? Does it display networked machines properly? Are file icons consistent in design if not color scheme? The problem most people have (in my experience) is behavioral. The mismatching visuals is just the most jarring aspect that's easiest to point to.

It's not that there are aesthetic difference like pink sparkles on some.

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.

I understand this, but modularity is one of the philosophies and benefits behind linux, with modularity unfortunately comes inconsistency. As many of the apps available on linux are open source and open source developers are mostly free to use whatever toolkits they want or are comfortable with, you're not likely to get the consistency you want with linux.

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.

A standard API can provide more modularity and control than the current approach.

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.

>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.

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?

Your program in dlangui would do something like this (but in D rather than the C-like pseudocode I'm going to use...). At the place where you want to put up a file chooser dialog, which now presumably does something like this:

  char * result = dlangui_choose_file(...)

you would do this instead:

  char * result = 0;
  char * (*standard_choose)() = get_standard_choose();
  if (standard_choose)
    result = (*standard_choose)(...);
  if (result == 0)
    result = dlangui_choose_file(...)

get_standard_choose is a small function that would:

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(...)

and it would deal with using the user preferred dialog if available. It would be completely transparent to the programmer using dlangui).

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.

Actual modularity would imply a common way to plug in different file choosers so you could use file mangager A with desktop b with application from desktop c.

Inconsistency comes not from modularity but rather from incompetence.

And NONE of them have usable keyboard shortcuts so you can avoid using the mouse.

Don't worry, soon it will be 'systemui' and there will only be one way to do anything. /s

Apparently a lot of people care, but programs not having the same style across a system always seems to be a top 3 issue with electron apps.

Windows has this same problem, with 3rd party and its own apps. I don't know why it needs 3 different file open dialogs, and it confuses the crap out of normies. Don't even ask me about people getting upset about not knowing when to click or double-click.

I tell people that if the cursor changes to a hand, then it's a single-click.

Everyone doubleclicks anyway though.