181–190 of 756 posts
You will find lots of such examples of a feature which you personally find very important and wonder why such a simple thing is not supported yet. I guess everyone has such examples. And you will also find such examples for MacOSX or Windows. For me personally, I wonder why mouse wheel/scroll acceleration is still not implemented. I implemented it a while ago for Xorg, which is outdated now, and also the maintainer w…
There's more serious reasons this file picker is broken. Here's a trivial to reproduce and obvious issue that's been there for several years now: 1. Open a directory that loads slowly (e.g. one with thousands of files on a smb3 mount) 2. While the list is loading, select a file (but do not open it) 3. Wait for the whole list to load Once the list finishes loading, the file on the very top of the list gets automatical…
Even worse is when you know the exact file name that you want to open, and the interface fights against you writing it! For example I want to open /tmp/a.png, but there's thousands of files on /tmp and the cursor disappears while "loading" them, and and some characters of the file name are lost, or typed on different parts of the interface.
It's a design decision. There is no right or wrong.
It's a design decision if both sides have competing benefits and you choose one. In this case it's a planning / engineering decision: other work is prioritised higher than implementing the previews.
There's more serious reasons this file picker is broken. Here's a trivial to reproduce and obvious issue that's been there for several years now: 1. Open a directory that loads slowly (e.g. one with thousands of files on a smb3 mount) 2. While the list is loading, select a file (but do not open it) 3. Wait for the whole list to load Once the list finishes loading, the file on the very top of the list gets automatical…
This, other UX and even performance (!) issues that have been mentioned in siblings as well as TFA makes the Gtk file pickers easily one of the TOP10 reasons to avoid Gtk and Gnome for anything.
The interaction design of these dialogs is simply shit. Windows (and also KDE, which has been using a copy of the Windows dialog for about 20 years) show how to do it correctly.
Linux was always a Terminal-first OS. The UI efforts never came close to the depth that MacOS and Windows have. Take for example the scaling issue. It has been now almost half a decade with 4k Displays, and Linux still does not know how to deal with it other than 100% or 200%. Currently Linux is unusable for anyone with a modern display. I appreciate the work that all the contributors put -for free- in projects like…
Earlier quoted context omitted.
Even worse is when you know the exact file name that you want to open, and the interface fights against you writing it! For example I want to open /tmp/a.png, but there's thousands of files on /tmp and the cursor disappears while "loading" them, and and some characters of the file name are lost, or typed on different parts of the interface.
Or when you have the full path name already and want to paste it in to GtkFileChooser. It turns out this is possible, but you'd never know it from the UI.
The Xfce file manager, Thunar, has thumbnails. For casual use at least, it is very similar to the Gnome file manager.
Thunar is great, however it does no good here. Your various programs like GIMP will always use the Gnome/GTK file picker because that's what they've been programmed to do. Or, if not based on GTK they will use whatever other file picker their toolkit provided.
Well, not really. Anymore.
Recently (give or take few years), toolkits and applications started to use desktop portal - mainly as a preparation for sandboxing (i.e. putting the app inside flatpak & co). The application, optionally inside sandbox, doesn't use the framework's common dialog - because that would not give it access to files outside sandbox - but talks to the desktop provided one via dbus.
That desktop provided one does not have to be implemented by the framework that the application uses. It is implemented by the DE that the user chooses.
Linux was always a Terminal-first OS. The UI efforts never came close to the depth that MacOS and Windows have. Take for example the scaling issue. It has been now almost half a decade with 4k Displays, and Linux still does not know how to deal with it other than 100% or 200%. Currently Linux is unusable for anyone with a modern display. I appreciate the work that all the contributors put -for free- in projects like…
Earlier quoted context omitted.
>I’m having trouble even imagining the insane event-processing architecture that results in keystrokes being processed out of order. It's relatively simple: the picker executes file-opening asynchronously, and only checks which file was selected at some indeterminate point after enter is pressed. In the meantime, the down arrow input in the main GUI changes the selection. The keypresses are always in order. Whether o…
Why wouldn't the key interrupt or freeze the keypress queue? I don't think you need some advanced async logic to get this right. The only potential downside would be if people expected to be able to cancel the action. But that would be unusual, I think.
In this case, the async logic is not advanced. In fact, I'm willing to bet that this is what happened: at first, the file-opening was synchronous in the GUI. People complained that opening certain files locked up the file picker, so a developer sticks the file-opening code in a background thread. This produces the above bug, without complicating the input design - in fact, preventing the bug requires making additional changes to the code in some way.