Gnome has no thumbnails in the file picker and my toilets are blocked (2021)(jayfax.neocities.org)
jayfax.neocities.org
Gnome has no thumbnails in the file picker and my toilets are blocked (2021)
https://jayfax.neocities.org/mediocrity/gnome-has-no-thumbnails-in-the-file-picker.html
299 comments
This is a pet peeve of mine - why is it that in Linux it's idiomatic to start like 5 processes and pipe their outputs together to find a file containing a certain word from the shell, but something like a file chooser cannot be its own program?
> … but something like a file chooser cannot be its own program?
That's happening! Gtk 3 and 4 include GtkFileChooserNative[1]. It works like a file dialog except the application doesn't know about its widgets. That means it can proxy another application.
So if you're running a Gtk app in a sandbox like Flatpak or Snap, Gtk will use the Xdg file chooser portal[2]. In GNOME, this is implemented by an application (in the host) which, itself, creates a GtkFileChooser. In the future, it could be a beefier application. One benefit of that taking a while to happen is, once the implementation gets fancier, there won't be too many weird mismatched applications.
(Also, I mention GNOME, but it's important to notice the file chooser portal is itself platform neutral; KDE apps use this, too, and the implementation depends on what desktop you are running. Yay, decoupling!).
Not everything uses GtkFileChooserNative, but pretty much any recent Gtk app that doesn't have weird requirements probably does. Off the top of my head, Firefox, Secrets, Bottles, GNOME Builder and GNOME Text Editor (although they still ask for access to all of the of the files for other reasons), … even Slack and VS Code! (Electron switched over recently).
[1] https://docs.gtk.org/gtk4/class.FileChooserNative.html
[2] https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.free...
That's happening! Gtk 3 and 4 include GtkFileChooserNative[1]. It works like a file dialog except the application doesn't know about its widgets. That means it can proxy another application.
So if you're running a Gtk app in a sandbox like Flatpak or Snap, Gtk will use the Xdg file chooser portal[2]. In GNOME, this is implemented by an application (in the host) which, itself, creates a GtkFileChooser. In the future, it could be a beefier application. One benefit of that taking a while to happen is, once the implementation gets fancier, there won't be too many weird mismatched applications.
(Also, I mention GNOME, but it's important to notice the file chooser portal is itself platform neutral; KDE apps use this, too, and the implementation depends on what desktop you are running. Yay, decoupling!).
Not everything uses GtkFileChooserNative, but pretty much any recent Gtk app that doesn't have weird requirements probably does. Off the top of my head, Firefox, Secrets, Bottles, GNOME Builder and GNOME Text Editor (although they still ask for access to all of the of the files for other reasons), … even Slack and VS Code! (Electron switched over recently).
[1] https://docs.gtk.org/gtk4/class.FileChooserNative.html
[2] https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.free...
What I don't understand is why it took so long.
That bundling file chooser with a GUI framework is a bad idea should be obvious since well, ... Java Swing?.
And a easy to use system interface for a file chooser isn't hard to make, could have been (preferable) a binary you call and communicate with pipes with or similar or could have been something else (e.g. shared object).
It's kinda sad that the various Linux communities where so focused on their GUI framework being the best that it didn't happen until it was technically needed (for sandboxing) ...
EDIT just to be clear 95+% of applications could use a cmd with Linux style arguments which once done emits the selected file(s) to stdout, but there are a minority of advanced use-cases which require a bit of two way communication. Through most of them are bad ideas anyway, so maybe that could have been ignored.
That bundling file chooser with a GUI framework is a bad idea should be obvious since well, ... Java Swing?.
And a easy to use system interface for a file chooser isn't hard to make, could have been (preferable) a binary you call and communicate with pipes with or similar or could have been something else (e.g. shared object).
It's kinda sad that the various Linux communities where so focused on their GUI framework being the best that it didn't happen until it was technically needed (for sandboxing) ...
EDIT just to be clear 95+% of applications could use a cmd with Linux style arguments which once done emits the selected file(s) to stdout, but there are a minority of advanced use-cases which require a bit of two way communication. Through most of them are bad ideas anyway, so maybe that could have been ignored.
Was it a thing anywhere except recently? Going through some different native Windows apps, I see a host of different file choosers (many of which were once "the one" for their version of Windows), and they all belong to the same process as their respective applications. Definitely not to a privileged service. (Unless Windows is doing something exceptionally fancy here?).
A lot of this stuff was "decided" back when we had serious memory constraints, and less technology to manage them. Switching processes was costly. Running the file chooser in the same application was an excellent compromise. A solution. (I remember an article about this problem in the context of early MacOS, along with drag & drop and the like. Will share if I find it).
In addition, having the file chooser in-process makes sense if you're trying to appease app developers, who think they want the ability to change everything. In particular, they'd really like to add a custom preview widget and some other gizmos to the file chooser. Photoshop puts all sorts of buttons in its Export dialog, for instance. And because Photoshop does it, a bunch of other applications think they should, too. And they still want to, even if they're using Gtk.
Saying "this is dumb, we need this dialog to be a simpler interface for [reasons] and if your app has a weird file dialog you'll have to deal with it" is a very decisive action, and it is not without friction. So I think the reason this took so long is partly an accident of history (the bad solution stuck because it was too late by the time we could afford the good solution), and partly just luck: things reached an inflection point where app developers actually get something (sandboxing and clever app containers) in exchange for the inconvenience.
A lot of this stuff was "decided" back when we had serious memory constraints, and less technology to manage them. Switching processes was costly. Running the file chooser in the same application was an excellent compromise. A solution. (I remember an article about this problem in the context of early MacOS, along with drag & drop and the like. Will share if I find it).
In addition, having the file chooser in-process makes sense if you're trying to appease app developers, who think they want the ability to change everything. In particular, they'd really like to add a custom preview widget and some other gizmos to the file chooser. Photoshop puts all sorts of buttons in its Export dialog, for instance. And because Photoshop does it, a bunch of other applications think they should, too. And they still want to, even if they're using Gtk.
Saying "this is dumb, we need this dialog to be a simpler interface for [reasons] and if your app has a weird file dialog you'll have to deal with it" is a very decisive action, and it is not without friction. So I think the reason this took so long is partly an accident of history (the bad solution stuck because it was too late by the time we could afford the good solution), and partly just luck: things reached an inflection point where app developers actually get something (sandboxing and clever app containers) in exchange for the inconvenience.
> A lot of this stuff was "decided" back
But the time where the overhead mattered in any way is over since well over a decade.
Even when e.g. GTK3/QT5 was released the overhead of a out-of-process file chooser was more then irrelevant.
> makes sense if you're trying to appease app developers,
I have yet to see a single application which uses that for any reassemble thing which couldn't also work with a native file chooser (e.g. custom preview images) or can be handled well outside of the file chooser (but then I'm on Linux since quite a while, but this is about Linux in the end).
I have been hearing complains about non-native file chooser pretty much since I started using Linux 12? years ago. In difference to very few Linux programs customizing anything but filters in a file chooser.
So I don't buy that it's inconvenient for developers to any relevant degree (wrt. Linux) the very few application which insist on it still can roll their own file picker by using on of the "guaranteed to pop up" custom file picker libraries.
One the other hand having file picking as a system service would have lead to more consistent appearance, more convenience (consistent system interactions) and more accessibility (e.g. alternative system file picker specialized for blind people).
So you will have a hard time convincing me that it wasn't dump to not switch to native file picker around a decade ago when GTK3/QT5 came out, sure there where reasons, but there had been much more reasons in favor of it then against. It's just not a decision anyone ever did actively I guess, because not making a decision is easier then people across distros/GUI frameworks agreeing to making a decision.
But the time where the overhead mattered in any way is over since well over a decade.
Even when e.g. GTK3/QT5 was released the overhead of a out-of-process file chooser was more then irrelevant.
> makes sense if you're trying to appease app developers,
I have yet to see a single application which uses that for any reassemble thing which couldn't also work with a native file chooser (e.g. custom preview images) or can be handled well outside of the file chooser (but then I'm on Linux since quite a while, but this is about Linux in the end).
I have been hearing complains about non-native file chooser pretty much since I started using Linux 12? years ago. In difference to very few Linux programs customizing anything but filters in a file chooser.
So I don't buy that it's inconvenient for developers to any relevant degree (wrt. Linux) the very few application which insist on it still can roll their own file picker by using on of the "guaranteed to pop up" custom file picker libraries.
One the other hand having file picking as a system service would have lead to more consistent appearance, more convenience (consistent system interactions) and more accessibility (e.g. alternative system file picker specialized for blind people).
So you will have a hard time convincing me that it wasn't dump to not switch to native file picker around a decade ago when GTK3/QT5 came out, sure there where reasons, but there had been much more reasons in favor of it then against. It's just not a decision anyone ever did actively I guess, because not making a decision is easier then people across distros/GUI frameworks agreeing to making a decision.
You'd need some way to inform the window manager that "windows from this process should be considered modals over this window of mine" - probably something that's in the realm of the possible to hack together?
>You'd need some way to inform the window manager that "windows from this process should be considered modals over this window of mine"
Why though? Am I the only one that hates modal windows? Why does the parent window have to be blocked by the dialog window? Can't it be like the color picker dialog in GIMP?
Why though? Am I the only one that hates modal windows? Why does the parent window have to be blocked by the dialog window? Can't it be like the color picker dialog in GIMP?
There are/were Linux window managers or desktop environments where the file picker was not held if focus above the main window. Or at least they can be configured that way. I know because I've done it.
It turns out, that when that happens, the user can accidentally focus the main window while the file picker is up, and then the file picker gets hidden underneath it. As a fun bonus, the application now _probably_ appears to be frozen/crashed because it's waiting for input from the file picker that the user can no longer see.
It's just a bad idea, man. For most people anyway.
It turns out, that when that happens, the user can accidentally focus the main window while the file picker is up, and then the file picker gets hidden underneath it. As a fun bonus, the application now _probably_ appears to be frozen/crashed because it's waiting for input from the file picker that the user can no longer see.
It's just a bad idea, man. For most people anyway.
Then, if the user interacts with the main window, just close the file chooser and don't freeze the application.
Or set the right window properties including WM_TRANSIENT_FOR so that the window manager knows that the dialog should be displayed above the window.
As much as I hate modals they are usually a product of single threaded or poor event loop design.
What happens if I hit File->Save, then while the file picker helper process is spawning I get an urgent instant message and tab away, and when I alt-tab back focus returns to GNOME and I close the tab because I forgot I didn't finish saving? Does the file picker go away? If I type a filename in the picker afterward and hit Save, does it save the file even though I closed the tab?
Just like webpages in browser can capture its closing and ask you if you really want to quit.
Same with your proposed workflow, when you try to close the tab, the file picker will pop up again (within the visible area of the tab, not on another monitor), tab stays opened.
Same with your proposed workflow, when you try to close the tab, the file picker will pop up again (within the visible area of the tab, not on another monitor), tab stays opened.
For X11 there was no need to "hack" that - Window IDs are global so the file chooser just needs to be passed the value to set for its WM_TRANSIENT_FOR property.
Wayland might be more difficult since it likes to isolate processes more but considering this should have been common before Wayland was designed it could and should have influenced that design.
Wayland might be more difficult since it likes to isolate processes more but considering this should have been common before Wayland was designed it could and should have influenced that design.
"Here are my screen coordinates, I'm going modal while you're running" seems like a perfectly adequate answer to that.
How do message box (alert) popups work?
in GTK when you instantiate the window you pass what is called the "transient for" property (https://docs.gtk.org/gtk4/method.NativeDialog.set_transient_...). That informs the dialog what it belongs to. If you were to re-engineer this to make the file picker its own process, then you would have to fundamentally change the way it functions, sadly.
Edit: And I think Wayland would make this impossible? Someone correct me if I'm wrong here, but don't you lose basically all inter-window introspection with it? There may be some negotiation process, but I don't know how you would go about accessing an entirely separate application's context under that pipeline.
Edit: And I think Wayland would make this impossible? Someone correct me if I'm wrong here, but don't you lose basically all inter-window introspection with it? There may be some negotiation process, but I don't know how you would go about accessing an entirely separate application's context under that pipeline.
I bet this info isnt written down explicitly except in this comment.
The freedesktop.org community really needs it's own Raymond Chen pass down all the accumulated arcane knowledge.
The freedesktop.org community really needs it's own Raymond Chen pass down all the accumulated arcane knowledge.
> I bet this info isnt written down explicitly except in this comment.
The comment links to the documentation, which says it explicitly...
And then, many other places in the documentation, e.g. https://docs.gtk.org/gtk4/method.Window.set_modal.html
> Modal windows prevent interaction with other windows in the same application. To keep modal dialogs on top of main application windows, use gtk_window_set_transient_for() to make the dialog transient for the parent; most window managers will then disallow lowering the dialog below the parent.
The comment links to the documentation, which says it explicitly...
And then, many other places in the documentation, e.g. https://docs.gtk.org/gtk4/method.Window.set_modal.html
> Modal windows prevent interaction with other windows in the same application. To keep modal dialogs on top of main application windows, use gtk_window_set_transient_for() to make the dialog transient for the parent; most window managers will then disallow lowering the dialog below the parent.
> inter-window introspection
This oxymoron is a pet peeve of mine. If it's inter-window, then it's just inspection. Introspection is when something inspects itself, but people seem to think it just means inspecting anything technical.
Great post though, I just needed to get that off my chest
This oxymoron is a pet peeve of mine. If it's inter-window, then it's just inspection. Introspection is when something inspects itself, but people seem to think it just means inspecting anything technical.
Great post though, I just needed to get that off my chest
Mine too! (Perhaps we should introspect each other to determine why we feel this way....)
I find it particularly ironic or confusing because introspection seems so much less likely/more rarely to occur in anything technical; so why does it get that association? Because you're right, people do seem to use it as though it means 'highly technical inspection' or something.
I find it particularly ironic or confusing because introspection seems so much less likely/more rarely to occur in anything technical; so why does it get that association? Because you're right, people do seem to use it as though it means 'highly technical inspection' or something.
Technically its still the computer inspecting itself.
pixelat3d(1)
GNOME often rejects the ideas from the rest of the ecosystem.
It's a matter of human resources, gtk3 is an extremely small team compared to its influence.
Haven't the GTK developers basically admitted that GTK exists to serve the needs of GNOME, and if anyone else gets good use out of it, that's accidental and unsupported?
I really wish we had another popular GUI toolkit that isn't Qt.
I really wish we had another popular GUI toolkit that isn't Qt.
Why do you need a toolkit different from Qt? Because of the C++ API? Because the licensing (LGPL now so should be good)? Not lean enough for you? Just want something run by the community and no beholden to a single corporate overlord?
I'd much rather have one single toolkit standard so that everything can look and behave the same TBH.
I'd much rather have one single toolkit standard so that everything can look and behave the same TBH.
>> It's unfixable behavior because the GNOME devs stopped respecting their own gsettings, org.gtk.Settings.FileChooser location-mode, to FORCE the path-bar experience on everyone. Because no one needs to type file paths, apparently. So why bother respecting the settings for path-bar or filename-entry?
Control + L will turn the path bar into a simple string w/ autocomplete. Am I missing something here or are you talking about pasting a path into the filename portion of the dialog?
Control + L will turn the path bar into a simple string w/ autocomplete. Am I missing something here or are you talking about pasting a path into the filename portion of the dialog?
Hiding important features behind arbitrary keyboard shortcuts is definitely on my list of things I hate about modern desktop environments. (Not to mention, extremely unfriendly to accessibility.)
i installed a new debian box for work and i forgot to choose xfce4 so went with the default. gnome 3. i tried. i tried so hard to get used to it. for 2 horrible months i tried.
i only need a terminal, emacs, browser, thunderbird, the occasional screenshot and it was still horrific.
to be clear it was only the usability that was a nightmare. i experienced no bugs. it's solid. but wow it is unusable.
please, please, please someone at gnome headquarters ... can you make it usable? look at win10, win11, macos, kde, chromeos they all work fine. can't you do something like that? i believe you have the best software stack out there, and you're throwing it away with that frightful design.
this is tragic.
i only need a terminal, emacs, browser, thunderbird, the occasional screenshot and it was still horrific.
to be clear it was only the usability that was a nightmare. i experienced no bugs. it's solid. but wow it is unusable.
please, please, please someone at gnome headquarters ... can you make it usable? look at win10, win11, macos, kde, chromeos they all work fine. can't you do something like that? i believe you have the best software stack out there, and you're throwing it away with that frightful design.
this is tragic.
This is purely my impression and not something I could prove, but it feels like Gnome wanted to have an out-of-the-box Mac-like experience, while not really understanding while people like using Macs. "You don't have a million configuration options on a Mac, so neither should we!" doesn't account for Apple having whole departments working on UI things, choosing sane defaults, etc. People don't like macOS because it doesn't give them options, but because it tried to make good decisions and patterns so that they won't need to tweak everything.
I know lots of people don't like Macs because they're not super tweakable, and that's fine. It's still my impression that Gnome is aiming for that target, while not quite understanding why a lot of people do like Macs.
I know lots of people don't like Macs because they're not super tweakable, and that's fine. It's still my impression that Gnome is aiming for that target, while not quite understanding why a lot of people do like Macs.
100% my impression as well.
and you're right. macos is fine from a usability point of view. everything in gnome UI feels like they started strong, stayed strong, and then gave up half way ... (so many examples there's no point listing them anymore) and yeah put the clock in the middle of the bar while we're at it too.
and yet, you feel the potential no? no bugs whatsoever for me.
:/
back to xfce4. clunky, but consistent. some bugs. it's ok.
and you're right. macos is fine from a usability point of view. everything in gnome UI feels like they started strong, stayed strong, and then gave up half way ... (so many examples there's no point listing them anymore) and yeah put the clock in the middle of the bar while we're at it too.
and yet, you feel the potential no? no bugs whatsoever for me.
:/
back to xfce4. clunky, but consistent. some bugs. it's ok.
For sure. It's so close to being amazing, which makes it all the more frustrating.
No idea what problems you encountered, but I find Gnome to be a joy to use. It was such a relief after years on Windows. Gnome Boxes is such a smooth experience compared to VirtualBox. Maximizing content area by putting UI elements in the title bar is also something I appreciate.
The problem is that nobody puts the right elements in the titlebar. It has just become a place where they improperly put "SAVE" for dialog boxes, when there was plenty of room in the dialog to begin with. It's kind of just become a dumping ground to put the shit that everybody doesn't want to deal with. It's like the hamburger menu, it might have some benefits, but now everybody just throws all the shit in there that they don't wanna deal with. Why would you fill out a form going down the list, and then have your save button all the way at the top of the window? Why bother trying to make a good, intuitive UI, when you can just make a giant heap of shit and put all your leftover stuff there? And then to top it off, now I can't move the fucking window, because the titlebar is full of trash.
The biggest problem with GNOME is that the organization needs to get their shit together. Their priorities and design choices are awkward at best so I must say they don't care for their users at all.
GNOME's design choices are either extremely good or extremely bad. I like the general workflow, but the panel looks like some crummy i3 config. You could almost get rid of GNOME's panel altogether, placing the network icon etc on the "Applications" view. You can't even switch Audio or Bluetooth devices using the panel. It's dead real estate.
this is seriously a mystery to me. how do people use gnome? how can you be productive with it? i tried so hard: https://news.ycombinator.com/item?id=31782882
I use GNOME and honestly like it despite the many flaws. May be some sort of Stockholm syndrome, IDK. As I see I spent most of my time on the CLI or on the browser so the DE in itself doesn't matter that much and GNOME advantage is that I don't have to waste time troubleshooting and customizing it (not even possible sometimes) so I can focus on the things that matter. If you compare DEs pages on Arch Wiki, GNOME by far has the smaller 'Troubleshooting' section. Also when you use something for a long time you know how to workaround it's limitations and fix things while.
How come does every distro default to it, make it incredibly hard to opt-out, and then decide it's the best one available because it has more than double the installed base of the next option?
I simply do not understand people.
I simply do not understand people.
I use GNOME only because my favorite OS right now is Pop OS and it's what they ship by default. Otherwise, I'd still probably be laboring to get KDE, XFCE, or MATE to be a satisfactory experience.
The only thing that makes GNOME bearable for me are a handful of extensions and post-install tweaks. Specifically Dash-to-Panel and ArcMenu.
The biggest thing that still annoys me is the GNOME folks have this fetish about stuffing as many widgets as they can into the titlebars of windows.
The only thing that makes GNOME bearable for me are a handful of extensions and post-install tweaks. Specifically Dash-to-Panel and ArcMenu.
The biggest thing that still annoys me is the GNOME folks have this fetish about stuffing as many widgets as they can into the titlebars of windows.
It's like using MacOS- there is a set of limited utility it provides, and anything else must be achieved externally, ie- with another DE, WM, or in terminal.
For very basic desktop usage, GNOME 3 does about 65% of what I need. Because it's Linux, I can have TTYs that run KDE, i3, or more customized shells that accomplish the rest.
Not doing this would be an exercise in learned helplessness, which is exactly what I chose Linux to get away from.
For very basic desktop usage, GNOME 3 does about 65% of what I need. Because it's Linux, I can have TTYs that run KDE, i3, or more customized shells that accomplish the rest.
Not doing this would be an exercise in learned helplessness, which is exactly what I chose Linux to get away from.
I use GNOME technically, but in earnest I use whatever Pop!_OS decides to go with. It’s been fine transitioning off LXDE and macOS for me. That said, I don’t feel like a Linux power user or anything.
The file chooser has been broken since at least gnome 2, and was antiquated in the gnome 1 days. I don't believe it will work in gnome 4.
[deleted]
I understand how things get this way, but it is a super easy problem to fix:
1. spin up a new file picker: GTKFilePicker.c
2. add a deprecation warning to gtkfilechooserwidget.c
3. wait 20 years, then git rm gtkfilechooserwidget.c
1. spin up a new file picker: GTKFilePicker.c
2. add a deprecation warning to gtkfilechooserwidget.c
3. wait 20 years, then git rm gtkfilechooserwidget.c
>The biggest problem with GNOME right now is Gtk3 and gtkfilechooserwidget.c. It is so spaghetti and so many things rely on it that no one at GNOME is willing to work on it for fear of breaking something.
I wonder, why can't they introduce something like gtkfilechooserwidget2.c leaving the original widget intact?
I wonder, why can't they introduce something like gtkfilechooserwidget2.c leaving the original widget intact?
The big guest Jon for me is, in 2022, why write UI code in C? (I say this as one who contributed to GNOME a little (all icons) back in like ’98–’02 and who writes high-performance C++ professionally.)
Try typing the name of a folder that will be found by the integrated tracker search into a gnome file chooser that’s trying to save a file. Then double-click that folder. The results are poor, to say the least.
My favourite idiocy is that gnome-terminal will offset the items in the right click menu and display hex and and octet translation of a number you happen to have highlighted... for reasons.
When someone posted this as a bug because of the obvious unintended idiocies with this a being a default immutable behavior, the maintainer essentially told him to f off and go build his own version.
https://bugzilla.redhat.com/show_bug.cgi?id=1644986
Made another MacOS covert with that exchange, I'm sure.
When someone posted this as a bug because of the obvious unintended idiocies with this a being a default immutable behavior, the maintainer essentially told him to f off and go build his own version.
https://bugzilla.redhat.com/show_bug.cgi?id=1644986
Made another MacOS covert with that exchange, I'm sure.
I don't get your last comment? Everything is going to move into gtk4 or move to other toolkits as gtk3 gets obsoleted, it's the way of the world.
Suspect one of the impetuses behind such stagnation is that in reality not that many Linux users use GUIs to do file stuff as so many of us live in the command line.
>> Suspect one of the impetuses behind such stagnation is that in reality not that many Linux users use GUIs to do file stuff as so many of us live in the command line.
GTK is a GUI toolkit. It is literally made for building GUI applications. The Gnome developers are building a graphical DE. Your reasoning doesn't seem to sensible to me.
GTK is a GUI toolkit. It is literally made for building GUI applications. The Gnome developers are building a graphical DE. Your reasoning doesn't seem to sensible to me.
It makes sense to me. Developers work on a project (and most definitely open source developers) because they feel some friction with a system. Maybe it’s a task they want to automate, or a bug in some software they need to use. But either way — there must be some pain point that is causing them friction. This is what causes some program/feature to be written or updated or fixed.
If those developers have a perfectly good work around, then there is no pain point for them. It doesn’t matter if it is a pain point for their GUI-exclusive users. If they don’t feel the pain, it won’t be prioritized.[*]
This isn’t a criticism of Gnome per se, but rather a reality of time management. There is only so much time to go around, which means features and bugs get triaged. If none of the developers feel like this is enough of a pain to get into the quagmire that is the GtkFileChooser (?) widget, then it will not be touched.
[*] That is, of course unless they are being paid to do the work. If you are volunteering, then you get to choose what work to do. If you’re getting paid, the suddenly not working on the file chooser could become a pain point for the developer (as they might not get paid). Which is the major advantage commercial OSes have over their open source competition.
If those developers have a perfectly good work around, then there is no pain point for them. It doesn’t matter if it is a pain point for their GUI-exclusive users. If they don’t feel the pain, it won’t be prioritized.[*]
This isn’t a criticism of Gnome per se, but rather a reality of time management. There is only so much time to go around, which means features and bugs get triaged. If none of the developers feel like this is enough of a pain to get into the quagmire that is the GtkFileChooser (?) widget, then it will not be touched.
[*] That is, of course unless they are being paid to do the work. If you are volunteering, then you get to choose what work to do. If you’re getting paid, the suddenly not working on the file chooser could become a pain point for the developer (as they might not get paid). Which is the major advantage commercial OSes have over their open source competition.
GNOME devs want the users to use drag and drop instead of the file pciker, in their mind file picker is outdated and should be removed, in their mind having thumbnails there is duplicating having thumbnails in the File manager.
I am joking but I think they considered removing tabs because you should use multiple windows and ENJOY the cool Window manager their designed to switch between windows.
I am joking but I think they considered removing tabs because you should use multiple windows and ENJOY the cool Window manager their designed to switch between windows.
You're joking, but this is literally the line of logic that GNOME's maintainers have used for the past ~5 years.
> "Xorg is outdated and should be removed, everyone port everything over to Wayland!"
> "AppIndicator is outdated and should be removed, if anyone uses it (see: everyone), they can impliment it themselves!"
> "Native packaging is outdated and should be removed, Flatpak is the future now!"
> "Having a proper library of native widgets is outdated and should be removed, so we're replacing it with Libadwaita!"
...and so on and so forth...
> "Xorg is outdated and should be removed, everyone port everything over to Wayland!"
> "AppIndicator is outdated and should be removed, if anyone uses it (see: everyone), they can impliment it themselves!"
> "Native packaging is outdated and should be removed, Flatpak is the future now!"
> "Having a proper library of native widgets is outdated and should be removed, so we're replacing it with Libadwaita!"
...and so on and so forth...
i find most (if not all) technical decisions of the gnome team sensible.
but that fucking design and UI paradigm? WTF! the whole thing is so jekyll and hyde it beggars belief.
but that fucking design and UI paradigm? WTF! the whole thing is so jekyll and hyde it beggars belief.
Seeing no one complain about broken drag-and-drop functionality (in Gnome File Manager) in this thread has had me realise I must have a somewhat unique problem.
For the life of me I can't drag files out of File Manager into a program without a struggle.
This is an issue for drag-and-dropping e.g. images from FM -> Chrome (Jira stories / Gitlab comments / etc) or from FM -> Slack. Don't think I have tried much dragging into other programs.
What happens is either:
(~90%) nothing is dragged
(~7%) the file path is dragged and either causes an error or just pastes the path
(~3%) the actual file is dragged as expected
I've figured out some ways to improve the likelihood of the drag working - instead of just clicking and dragging the item, I first spin around in my chair twice, give a very specific exasperated sigh, and then use my arrow keys to select the file I want to drag and only then click and drag with my mouse. This works much more often - probably about 50% of the time.
Recently started always trying copy in FM -> paste in destination program and that generally works.
(I've had the issue for over a year, since the start of my OS install. Currently on latest Gnome (41? 42?) on Arch. Wayland. If someone sees this and has any ideas please let me know.)
For the life of me I can't drag files out of File Manager into a program without a struggle.
This is an issue for drag-and-dropping e.g. images from FM -> Chrome (Jira stories / Gitlab comments / etc) or from FM -> Slack. Don't think I have tried much dragging into other programs.
What happens is either:
(~90%) nothing is dragged
(~7%) the file path is dragged and either causes an error or just pastes the path
(~3%) the actual file is dragged as expected
I've figured out some ways to improve the likelihood of the drag working - instead of just clicking and dragging the item, I first spin around in my chair twice, give a very specific exasperated sigh, and then use my arrow keys to select the file I want to drag and only then click and drag with my mouse. This works much more often - probably about 50% of the time.
Recently started always trying copy in FM -> paste in destination program and that generally works.
(I've had the issue for over a year, since the start of my OS install. Currently on latest Gnome (41? 42?) on Arch. Wayland. If someone sees this and has any ideas please let me know.)
From what I can see, Gnome users do not complain. They know what works and what doesn't, and deal with it.
Not seeing anybody complaining about some Gnome brokeness is perfectly normal.
Not seeing anybody complaining about some Gnome brokeness is perfectly normal.
You should give KDE a try, it's pretty frikkin good. The file manager defaults are a bit weird but it's OK.
>> GNOME devs want the users to use drag and drop instead of the file pciker...
That's funny. Just replace the file dialog with opening the file manager. Drag and Drop. Better yet, just modify the file manager to have an option to self-close after selecting a file and a way to pass that selection to the app (using MIME types would not allow the DE to get it to the correct app in all cases).
That's funny. Just replace the file dialog with opening the file manager. Drag and Drop. Better yet, just modify the file manager to have an option to self-close after selecting a file and a way to pass that selection to the app (using MIME types would not allow the DE to get it to the correct app in all cases).
the impetuses are shrouded in mystery, what with the metaphorical GTK+, and the whatever it is the gnomers are doing over there. a graphical DE it is not, but it has "graphics".
sigh
it could be so awesome if a non-schizo designer got involved. it's frustrating really. so much potential, such thick window bars.
it is so stupid.
sigh
it could be so awesome if a non-schizo designer got involved. it's frustrating really. so much potential, such thick window bars.
it is so stupid.
I recall heavily using gnome 2?/KDE 2? (indeed I had to test things on them for work) Circa 2005 and indeed when Sun heavily invested in gnome to make the "java desktop" on Solaris to add accessibility etc so they could win institutional contracts. Was perfectly on the way to being great.
Then the great childish "let's rewrite everything from scratch" for both Linux DEs happened. It was a decade? before KDE was remotely viable again.
The gnome/gtk Devs focusing on zero configuration options possibly the most rubbish redesign I've ever seen.
KDE/Plasma only became viable to me in the last 24 months. Felt like a POC
Then the great childish "let's rewrite everything from scratch" for both Linux DEs happened. It was a decade? before KDE was remotely viable again.
The gnome/gtk Devs focusing on zero configuration options possibly the most rubbish redesign I've ever seen.
KDE/Plasma only became viable to me in the last 24 months. Felt like a POC
I felt kind of lost when Gnome 3 landed, but I discovered MATE, which forked off of Gnome 2. Gnome 2, IMHO, was the peak Unix desktop experience, and I felt so relieved to discover it does live on.
Gnome 3 confused (and continues to confuse) me to no end every time I tried it (which admittedly was not all that often. KDE 2 was cool, but I did not like KDE 3, although I do not remember why. I stopped paying much attention to KDE at that point. Xfce is nice, but not as nice as Gnome2/Mate.
Gnome 3 confused (and continues to confuse) me to no end every time I tried it (which admittedly was not all that often. KDE 2 was cool, but I did not like KDE 3, although I do not remember why. I stopped paying much attention to KDE at that point. Xfce is nice, but not as nice as Gnome2/Mate.
My point is that due to lack of users it doesn't get better. I've modified gnome in the past to meet my requirements
Gtk3 filechooser worked fine until 2014. Distros with gtk3 released before this have a gtk3 lib that handles pasting file paths in the file chooser and the gsettings still work. My last desktop with functional Gtk3 is Ubuntu 14.04 on Extended Service Mantainance (ESM) support. But it'll age out of support fairly soon.
My top gtk3/gnome 30 wtfs:
- the (all too well-known) file picker issue where when you type something it interprets it as file name filter rather than, you know, the file name you want to save under
- missing top menu (but a bar is still there wasting space for a ... clock wtf)
- general window positioning; like, if you open an app, rather than just opening a window as new top window, gnome opens it behind others and pushes a notification "FF is ready" wtf
- mainstream desktop apps not ported to dark mode, so those icons look even more puzzling
I could go on, but I'm definitely leaving gnome/gtk apps behind. I've eyed KDE Plasma which could give me everything I ever wanted from a DE, but I was using Ubuntu/gnome because it was mainstream enough that everything just works OOTB. I'm also totally not looking forward to wayland, containerize-all-the-things such that basic file workflows stop working, and other attitudes, all the while the apps I'm using are exactly the same I've used 15 or 20 years ago, without new ones coming.
I think I'm going back to Mac.
- the (all too well-known) file picker issue where when you type something it interprets it as file name filter rather than, you know, the file name you want to save under
- missing top menu (but a bar is still there wasting space for a ... clock wtf)
- general window positioning; like, if you open an app, rather than just opening a window as new top window, gnome opens it behind others and pushes a notification "FF is ready" wtf
- mainstream desktop apps not ported to dark mode, so those icons look even more puzzling
I could go on, but I'm definitely leaving gnome/gtk apps behind. I've eyed KDE Plasma which could give me everything I ever wanted from a DE, but I was using Ubuntu/gnome because it was mainstream enough that everything just works OOTB. I'm also totally not looking forward to wayland, containerize-all-the-things such that basic file workflows stop working, and other attitudes, all the while the apps I'm using are exactly the same I've used 15 or 20 years ago, without new ones coming.
I think I'm going back to Mac.
>> the (all too well-known) file picker issue where when you type something it interprets it as file name filter rather than, you know, the file name you want to save under
That one drives me insane.
>> general window positioning
I want my applications to come up where they were when I last closed them. This used to be up to the app under X, and I'm fully on board with the Wayland idea that an application shouldn't know or be able to modify its window position. But that means putting things where they were is the DE/compositors responsibility now, and I fear they're going to fight that idea forever. I hope I'm wrong though.
That one drives me insane.
>> general window positioning
I want my applications to come up where they were when I last closed them. This used to be up to the app under X, and I'm fully on board with the Wayland idea that an application shouldn't know or be able to modify its window position. But that means putting things where they were is the DE/compositors responsibility now, and I fear they're going to fight that idea forever. I hope I'm wrong though.
> I'm fully on board with the Wayland idea that an application shouldn't know or be able to modify its window position
Why? Genuine question - that sounds like an incredibly opinionated position for the display server to force up the stack, and I don't have a good intuition for why it should be necessary.
Why? Genuine question - that sounds like an incredibly opinionated position for the display server to force up the stack, and I don't have a good intuition for why it should be necessary.
>> Why? Genuine question - that sounds like an incredibly opinionated position for the display server to force up the stack...
The security model in Wayland seems to keep the application largely isolated from its environment. No warping the mouse pointer, no reading pixels, no understanding of what the user might be doing outside the application window. I can agree with all of that in principle. It is not the applications place to move anything on the desktop including itself. Those are to be done by the user. Also for consistency this kind of thing has to be done by the DE.
It was also nonsensical to have have applications be responsible for remembering their own positions instead of the "window manager". Read that again "window manager" ;-)
The security model in Wayland seems to keep the application largely isolated from its environment. No warping the mouse pointer, no reading pixels, no understanding of what the user might be doing outside the application window. I can agree with all of that in principle. It is not the applications place to move anything on the desktop including itself. Those are to be done by the user. Also for consistency this kind of thing has to be done by the DE.
It was also nonsensical to have have applications be responsible for remembering their own positions instead of the "window manager". Read that again "window manager" ;-)
> The security model in Wayland seems to keep the application largely isolated from its environment.
I really don't see what good that is when considered in the greater context of the Linux desktop paradigm, wherein any application running under your user almost certainly has write access to your entire $HOME, including the ability to tamper with your shell configuration, edit your $PATH, and do all manner of nasty subversive shit. To get any real security benefit from Wayland over X, you'd have to abandon the entire Linux desktop paradigm and use a completely new ecosystem as different from the traditional linux desktop as Android is.
If you just use Wayland as a drop-in replacement for X (as GNOME/Wayland and KDE/Wayland are essentially doing), you're still screwed six ways to Sunday.
I really don't see what good that is when considered in the greater context of the Linux desktop paradigm, wherein any application running under your user almost certainly has write access to your entire $HOME, including the ability to tamper with your shell configuration, edit your $PATH, and do all manner of nasty subversive shit. To get any real security benefit from Wayland over X, you'd have to abandon the entire Linux desktop paradigm and use a completely new ecosystem as different from the traditional linux desktop as Android is.
If you just use Wayland as a drop-in replacement for X (as GNOME/Wayland and KDE/Wayland are essentially doing), you're still screwed six ways to Sunday.
> I really don't see what good that is when considered in the greater context of the Linux desktop paradigm, wherein any application running under your user almost certainly has write access to your entire $HOME, including the ability to tamper with your shell configuration, edit your $PATH, and do all manner of nasty subversive shit. To get any real security benefit from Wayland over X, you'd have to abandon the entire Linux desktop paradigm and use a completely new ecosystem as different from the traditional linux desktop as Android is.
It doesn’t require changes as deep as you’re implying (although I would say moving away from the traditional UNIX permissions model would ultimately be a good thing). It can be beneficial with existing application confinement mechanisms like Flatpak. You can restrict a Flatpak app from accessing your $HOME, but if it’s given access to your X server it has a lot more access than it likely needs. My understanding is the situation is better with Wayland, provided you only give it access to the Wayland socket and not the X11 socket.
It doesn’t require changes as deep as you’re implying (although I would say moving away from the traditional UNIX permissions model would ultimately be a good thing). It can be beneficial with existing application confinement mechanisms like Flatpak. You can restrict a Flatpak app from accessing your $HOME, but if it’s given access to your X server it has a lot more access than it likely needs. My understanding is the situation is better with Wayland, provided you only give it access to the Wayland socket and not the X11 socket.
Why do Linux heads this needless containerization thing to themselves? There are zero new desktop apps coming; those in use are F/OSS and have been thoroughly reviewed for like 20 years. What's the threat? At best, it disturbs user file-based workflows and puts additional work onto developers who are few and far between anyway. Distros have worked well for a long time - much better than Win or Mac sw updates. If you want to compile your own app, it's well supported. We don't have a rush of new unstable must-have libs to compile against all of a sudden.
The problem is not trusting the application, but that application having to manage untrusted data. Let’s say you have a trusted open source pdf reader. It can easily be infected by a pdf that exploits a memory bug in it.
>> If you just use Wayland as a drop-in replacement for X (as GNOME/Wayland and KDE/Wayland are essentially doing), you're still screwed six ways to Sunday.
No, you're only screwed 4 or 5 ways. Applications can't screen capture, and they can't monitor the keyboard input to other applications.
Your points on other security issues are valid, but just because there are 6 different ways a program can dig into your system is no reason not to plug some of those holes. Wayland does that.
IMHO we need to restrict a bunch of system calls so they can only be used by the GUI toolkit. Then only files selected by the user could be accessed by an application. Of course CLI programs and other cases need permission too, so there is some complexity to work out. But this would allow a random application to use the system installed GUI toolkit and access only what the user specifically says through interactions.
Better security doesn't have to be hard, but it does require that changes be made.
No, you're only screwed 4 or 5 ways. Applications can't screen capture, and they can't monitor the keyboard input to other applications.
Your points on other security issues are valid, but just because there are 6 different ways a program can dig into your system is no reason not to plug some of those holes. Wayland does that.
IMHO we need to restrict a bunch of system calls so they can only be used by the GUI toolkit. Then only files selected by the user could be accessed by an application. Of course CLI programs and other cases need permission too, so there is some complexity to work out. But this would allow a random application to use the system installed GUI toolkit and access only what the user specifically says through interactions.
Better security doesn't have to be hard, but it does require that changes be made.
> any application running under your user almost certainly has write access to your entire $HOME, including the ability to tamper with your shell configuration, edit your $PATH, and do all manner of nasty subversive shit.
Not that I'm a fan of it or that knowledgeable about the subject, but isn't this sort of where Flatpak comes in where applications have to be given permission to access some of these?
I know that Fedora is very clearly moving toward the Silverblue (OSTree) endgame where the underlying system is immutable and Flatpak is the default for user applications on top.
Not that I'm a fan of it or that knowledgeable about the subject, but isn't this sort of where Flatpak comes in where applications have to be given permission to access some of these?
I know that Fedora is very clearly moving toward the Silverblue (OSTree) endgame where the underlying system is immutable and Flatpak is the default for user applications on top.
Just because the existing situation on Linux is terrible from a security point of view, it doesn’t mean we shouldn’t start fixing it.
Not being able to install a keylog from an npm package is already a huge improvement.
Not being able to install a keylog from an npm package is already a huge improvement.
With multiple monitors, and multiple multi-monito configurations, window position becomes a complicated concept, full of pitfalls and corner cases. It is reasonable (although admittedly not the only possibility solution) to centralize the window position management in the wm.
Your conclusion doesn't follow from your premise.
What does follow is that apps should have a library available which allows them to express their positioning desires while accounting for the complications and corner cases.
Even if positioning were centralized, apps should still have been able to tell the WM "This is what I want to happen w.r.t. positioning, try to accommodate me".
What does follow is that apps should have a library available which allows them to express their positioning desires while accounting for the complications and corner cases.
Even if positioning were centralized, apps should still have been able to tell the WM "This is what I want to happen w.r.t. positioning, try to accommodate me".
I should have explained myself better. The old way of specifying a position (pixel coords in a plane) does not work well for complicated setups. Among the possible alternatives there is:
1. Assign responsibility to the wm (Wayland’s way)
2. Create a new way to specify position preference in a complicated world. That’s what you propose, IIUC. It’s possible but complicated, and Wayland had a lot of other problems to worry about, therefore I understand why they didn’t choose this way.
3.Leave the simple protocol in place, but let the wm override the application’s choice when necessary. I guess a lot of apps would not work properly in such a system.
1. Assign responsibility to the wm (Wayland’s way)
2. Create a new way to specify position preference in a complicated world. That’s what you propose, IIUC. It’s possible but complicated, and Wayland had a lot of other problems to worry about, therefore I understand why they didn’t choose this way.
3.Leave the simple protocol in place, but let the wm override the application’s choice when necessary. I guess a lot of apps would not work properly in such a system.
Given the choice between the window manager making all of the positioning/size decisions and allowing the app to do it, I'll gladly pick the WM. In the opposite world, sure, most apps will behave sensibly but then occasionally you're going to run into that application where the author says, "hey, my app is so great, you're definitely going to want it full-screen all the time!"
An exaggeration of course, but I have seen plenty of apps try to do "smart" things about window management on their own, and they always get it wrong. It's one of the reason's KDE WM allows you to to override and make permanent a surprising number of settings.
(I also believe that websites should not be able to just do whatever the hell they want on my computer, but that battle seems to have been lost.)
An exaggeration of course, but I have seen plenty of apps try to do "smart" things about window management on their own, and they always get it wrong. It's one of the reason's KDE WM allows you to to override and make permanent a surprising number of settings.
(I also believe that websites should not be able to just do whatever the hell they want on my computer, but that battle seems to have been lost.)
More simply, because I say where the application goes. It absolutely does not get a say in the matter. It's my computer.
I got used to type slash(/) which opens file input field when ever I'm pasting file.
With respect to the Wayland devs, as they've been fighting more than an uphill battle for a decade now, but that is so bone-headed.
If their design philosophy is like this in general, no wonder no one is adopting it. It's just a worse X.
If their design philosophy is like this in general, no wonder no one is adopting it. It's just a worse X.
It is the default used by every major distro now, so it is definitely adopted. Also, it has a very good design, solving real issues.
> I could go on, but I'm definitely leaving gnome/gtk apps behind. I've eyed KDE Plasma which could give me everything I ever wanted from a DE, but I was using Ubuntu/gnome because it was mainstream enough that everything just works OOTB
Kubuntu was my first distro and posts like these reconfirm my decision to stick with KDE.
Kubuntu was my first distro and posts like these reconfirm my decision to stick with KDE.
I wish it was mine too. I would have gone for Linux as my main OS lot earlier.
> - the (all too well-known) file picker issue where when you type something it interprets it as file name filter rather than, you know, the file name you want to save under
I deeply hate this one, it always gets me when I'm saving in a hurry.
And let's not forget about buttons on windows title bars. Someone please tell GTK developers that most of us aren't using tablets; computers with actual keyboards and mice are here to stay for a long time.
I deeply hate this one, it always gets me when I'm saving in a hurry.
And let's not forget about buttons on windows title bars. Someone please tell GTK developers that most of us aren't using tablets; computers with actual keyboards and mice are here to stay for a long time.
That one drives me absolutely fucking batty. Nobody uses GNOME on the touch screens that the UI was clearly designed for, and moving the default requestor buttons out of the bottom right where literally every single GUI of any note throughout history puts them is a particularly galling bit of NIH snowflakery.
Gnome is what you get when you combine the worst parts of Windows 8 with the worst parts of MacOS. Bad ideas + bad execution, but most major distros ship it by default for some inexplicable reason.
> I think I'm going back to Mac.
This is poor conclusion imo. KDE might better suite your needs. Plus, macOS comes with its own wtf's: https://medium.com/@parttimeben/mac-it-just-works-horribly-c...
This is poor conclusion imo. KDE might better suite your needs. Plus, macOS comes with its own wtf's: https://medium.com/@parttimeben/mac-it-just-works-horribly-c...
Yes I'm aware Mac OS isn't a panacea either (used MacBooks/PowerBooks and Mac mini on and off alongside Linux since 2003). But I had such a craptastic experience with PC hardware lately: on my 3rd Dell Latitude/Precision with battery and other hw defects ootb sent by customers for work within 8 months, and my 2019 Thinkpad has a stuck trackpad - miniscule as it is - due to completely unused mechanical parts (buttons, think point, and whatnot). Meanwhile, M1/2 MacBooks leave x86 notebooks in the dust performance-wise, and have left PC notebooks behind in terms of screen resolution for a long time now, also wrt trackpad and keyboard, and value retention, it's not funny
Mine is that they kind of abandoned Vala and then started using their own JavaScript engine for everything beyond bare bones Gtk+.
The slowness and leaks of not having a V8 class implementation, has made me embrace XFCE for the surviving device I still run GNU/Linux natively on.
And to think 22 years ago I was arguing for GNOME, advocating for Gtkmm versus Qt.
The slowness and leaks of not having a V8 class implementation, has made me embrace XFCE for the surviving device I still run GNU/Linux natively on.
And to think 22 years ago I was arguing for GNOME, advocating for Gtkmm versus Qt.
"Their own JavaScript engine" is Mozilla SpiderMonkey 91.
https://gitlab.gnome.org/GNOME/gjs/blob/master/doc/Home.md
It appears to be broadly competitive with V8.
https://www.anandtech.com/show/16078/the-2020-browser-battle...
https://gitlab.gnome.org/GNOME/gjs/blob/master/doc/Home.md
It appears to be broadly competitive with V8.
https://www.anandtech.com/show/16078/the-2020-browser-battle...
Maybe it is competitive now, it hasn't always been like that.
https://gitlab.gnome.org/GNOME/gjs/-/issues/231
https://gitlab.gnome.org/GNOME/gjs/-/issues/361
https://feaneron.com/2018/04/20/the-infamous-gnome-shell-mem...
Just to give you a taste of the issues.
When I complain about something, usually it is based on experience and knowledge.
And if I wanted to have a desktop where JavaScript gets used everywhere I would buy a Chromebook instead.
https://gitlab.gnome.org/GNOME/gjs/-/issues/231
https://gitlab.gnome.org/GNOME/gjs/-/issues/361
https://feaneron.com/2018/04/20/the-infamous-gnome-shell-mem...
Just to give you a taste of the issues.
When I complain about something, usually it is based on experience and knowledge.
And if I wanted to have a desktop where JavaScript gets used everywhere I would buy a Chromebook instead.
My reading is that performance problems are caused by interactions between reference-counted GObjects and tracing GC, nothing to do with "not having a V8 class implementation".
> https://gitlab.gnome.org/GNOME/gjs/-/issues/361
Now what can we learn here? Well, the most important lesson is that getting properties from GObjects seems to be very expensive and a major bottleneck [...] Also generally (and as expected), recursive processes like Clutters allocation machinery round tripping between C and JS land are a bad idea and should probably avoid JS land altogether
> https://feaneron.com/2018/04/20/the-infamous-gnome-shell-mem...
This fix is strictly specific to GObjects wrapped by GJS
> https://gitlab.gnome.org/GNOME/gjs/-/issues/361
Now what can we learn here? Well, the most important lesson is that getting properties from GObjects seems to be very expensive and a major bottleneck [...] Also generally (and as expected), recursive processes like Clutters allocation machinery round tripping between C and JS land are a bad idea and should probably avoid JS land altogether
> https://feaneron.com/2018/04/20/the-infamous-gnome-shell-mem...
This fix is strictly specific to GObjects wrapped by GJS
From my point of view, the whole experience end to end counts as having a V8 class implementation, and not the bare bones runtime.
ChromeOS isn't only V8 without anything else.
ChromeOS isn't only V8 without anything else.
> - general window positioning; like, if you open an app, rather than just opening a window as new top window, gnome opens it behind others and pushes a notification "FF is ready" wtf
I like this behavior. It only happens for apps that take too long to start. When an app takes too long to start, it is usual for me to continue doing other things while it starts, when it starts, I don't want it stealing my focus. I think this feature works exactly as intended.
I like this behavior. It only happens for apps that take too long to start. When an app takes too long to start, it is usual for me to continue doing other things while it starts, when it starts, I don't want it stealing my focus. I think this feature works exactly as intended.
You prefer a notification to steal your focus instead? :)
The notification does not steals my focus, it may call my attention, but it will not steal my focus. Focus stealing is when the app I'm using is switched to another without any action from me.
> general window positioning
This has worked as expected to me. It generally opens windows on top of the stack unless the app takes too long to start and you've interacted with the window on top. In that case I appreciate it doesn't change focus (I could be typing something for example).
This has worked as expected to me. It generally opens windows on top of the stack unless the app takes too long to start and you've interacted with the window on top. In that case I appreciate it doesn't change focus (I could be typing something for example).
I started with desktop linux with KDE2, and KDE3 was... seemingly perfect. I watched some colleagues move to KDE4 when it came out and it felt like a ... mess. I tried it myself for a few days and it was too foreign. Never cared for gnome as a main desktop, although I do recognize gnome foundation did provide a lot of useful software over the years, some of which I used.
Moved to mac for main desktop around 2008. I look back some times and KDE5/plasma/whatever might be worthwhile to check out again. Mac annoyances are piling up over the years, but I suspect it would be "the grass is greener" somewhere else, and I'd find a lot of the KDE annoyances which led to me leave may still be there.
Moved to mac for main desktop around 2008. I look back some times and KDE5/plasma/whatever might be worthwhile to check out again. Mac annoyances are piling up over the years, but I suspect it would be "the grass is greener" somewhere else, and I'd find a lot of the KDE annoyances which led to me leave may still be there.
If you're a KDE 3 fan, https://trinitydesktop.org/ is actively maintained.
Same here. GNOME 2 was just about perfect.* KDE 3 was even better. Rock solid and lots of excellent, well-integrated functionality. Everything after those two have been a showcase of failed UX experiments.
* (It's successor MATE has not aged gracefully, unfortunately.)
* (It's successor MATE has not aged gracefully, unfortunately.)
Modern KDE is pretty good. Most importantly, it still lets you configure things to your own liking, instead of one-size-fits-all approach that GNOME espouses.
> I've eyed KDE Plasma which could give me everything I ever wanted from a DE, but I was using Ubuntu/gnome because it was mainstream enough that everything just works OOTB
I'm curious, what do you expect won't work under KDE?
I'm curious, what do you expect won't work under KDE?
Nothing in particular; maybe third-party apps like MS Teams (ugh) I need for my customer projects (which also didn't work right on gnome for years, and had trouble when switching logins/customers), that kind of stuff. I considered kubuntu, but thought I was leaving Ubuntu mainstream for good anyway, so why not go to eg Slackware w/ KDE Plasma and say goodbye to systemd, snaps, and containerized browser behemoths that want to update themselves all the time anyway. Don't want that shit on my main machine period. I'll be keeping my old (Ubuntu 16.04 ESM and 20.04 LTS) notebooks around just in case, but customers keep sending me shite notebooks, and MacBooks are more than capable to run Docker crap anyway.
What do you so heavily dislike about systemd? It's pretty useful.
Getting rid of systemd is harder. But applications don't stop working because you switched a DE.
I ran into not being able to open Nautilus as an admin without having to install some packages through apt. Why is Linux the only OS that doesn't allow me to edit or view a system file out of the box?
Gnome people basically looked as how Apple managed to be firm about design and though they can be even tougher since they do it for free.
Such reasonable / obvious requests linger for decades and after a while the system has been rewritten and bugs are auto-closed.
I no longer report any bugs nor care.
Such reasonable / obvious requests linger for decades and after a while the system has been rewritten and bugs are auto-closed.
I no longer report any bugs nor care.
I loathe all auto-closing so much, it's such a cheap way out of issue triage. The ostrich method of project management. It's a good red flag though, I know not to waste my time on the project. Who knows what major issues have been auto-ignored.
It can be especially inane if the issues are also locked automatically, you're already ignoring the issue why the f can't you let people discuss workarounds or request reopen.
It can be especially inane if the issues are also locked automatically, you're already ignoring the issue why the f can't you let people discuss workarounds or request reopen.
Firefox Android did that and I stopped contributing. It's not even that I hold a grudge, but the ostrich method is extremely frustrating to the reporters
I keep hoping someone will be gutsy enough to build and deploy a bumpbot (or bots!) to combat stalebot.
I keep hoping it will simply gain a way to say 'I still care, this is still an issue, there's no new information to add, (nor asked for!) it's just not being prioritised so please leave it open'. Or infer that after a couple of stale removals.
Sure they close a lot of junk from drive-by question askers which helps maintainers, but they piss off a lot of good citizens providing information on actual bugs/feature requests that are just waiting for attention too.
Sure they close a lot of junk from drive-by question askers which helps maintainers, but they piss off a lot of good citizens providing information on actual bugs/feature requests that are just waiting for attention too.
Combine that with the CLA plague and you have a recipe for nothing but corporate-backed open source contributions. Individuals need not apply.
An undead open-source project.
Not a bad idea. Should make it so it runs under user tokens so people can run it under their own accounts with their own message template.
This is the thing - if you're going to be like Apple and dictate design, you have to get it right. macOS and Apple hardware is not to everyone's taste, and they make mistakes, but they prototype and dogfood and iterate like crazy and they have thumbnails in the damn file picker.
When you're picking a file, you can even tap space to get a blown-up preview of an image or PRF. I use this feature almost every time I need to pick an image.
When you're picking a file, you can even tap space to get a blown-up preview of an image or PRF. I use this feature almost every time I need to pick an image.
One thing I'll give Apple credit for is in the early days of OS X, they had (and perhaps still have, if it's the same thing) a document called Human Interface Guidelines. They actually did real experiments with real people and came up with a set of UI patterns that were proven by science to make software features and UI discoverable, usable, and clear, with the least amount of cognitive load.
Things like, the buttons on a dialog should should be a verb indicating the _action_ the user wants to take. Like "Run This" and "Go Back" instead of "Yes" and "No". (Or worse, the old Windows "OK" and "Cancel", which is rife with ambiguity in so many cases.)
And the tone of the document was that it was intended to be useful to _all_ user interface designers of all software and on all platforms, not just OS X. I just skimmed over the current edition and as far as I can tell, these days it's basically just about how to stay "on brand" with the Apple experience when writing your own UI.
Things like, the buttons on a dialog should should be a verb indicating the _action_ the user wants to take. Like "Run This" and "Go Back" instead of "Yes" and "No". (Or worse, the old Windows "OK" and "Cancel", which is rife with ambiguity in so many cases.)
And the tone of the document was that it was intended to be useful to _all_ user interface designers of all software and on all platforms, not just OS X. I just skimmed over the current edition and as far as I can tell, these days it's basically just about how to stay "on brand" with the Apple experience when writing your own UI.
For what it's worth Gnome also has an HIG: https://developer.gnome.org/hig/
And they have claimed in the past to have done UX testing with actual users.
And they have claimed in the past to have done UX testing with actual users.
> And they have claimed in the past to have done UX testing with actual users.
How many testers were there and how were they selected? Are they representative of gnome's current and future user bases?
I think I read once that their test group was basically the developers and their mediate friends. If so, then this is not how you do UX testing.
How many testers were there and how were they selected? Are they representative of gnome's current and future user bases?
I think I read once that their test group was basically the developers and their mediate friends. If so, then this is not how you do UX testing.
Here's my favorite Human Interface Guidelines version (2009-08-20): https://web.archive.org/web/20101113134550/http://developer....
Windows also had a similar document. E.g. here's one for Win7:
https://docs.microsoft.com/en-us/windows/win32/uxguide/guide...
The problem is getting the app developers to actually follow them.
https://docs.microsoft.com/en-us/windows/win32/uxguide/guide...
The problem is getting the app developers to actually follow them.
> When you're picking a file, you can even tap space to get a blown-up preview of an image or PRF. I use this feature almost every time I need to pick an image.
Wait, what? That would have been super useful, but how was I supposed to find out?
Wait, what? That would have been super useful, but how was I supposed to find out?
It's not indicated anywhere visually. I don't even remember how I found out about it.
This is a downside of macOS and iOS design - lot of hidden gestures. For example, you can right-click the text title of a Finder window to open a quick navigation to all the parent folders of the current directory.
This is a downside of macOS and iOS design - lot of hidden gestures. For example, you can right-click the text title of a Finder window to open a quick navigation to all the parent folders of the current directory.
Wait, what? I knew about the spacebar thing but this one is new to me.
This works in every Finder window; if there's a window with files you can use Quick Look. I'm not sure if it's documented anywhere anymore, but it's been around 15 years.
https://support.apple.com/en-us/HT201236 or https://support.apple.com/guide/mac-help/view-and-edit-files... I guess?
First one also mentions the ⌘-click on a window's title
First one also mentions the ⌘-click on a window's title
[deleted]
> I no longer report any bugs nor care.
Past that point years back, kept going.
I just don't use anything Gnome related, if I can help it. I have found some things that unfortunately use the toolkit and somehow manage to not be intentionally irritating, but I assume that's an oversight to be corrected once I'm dependent on it.
Like is too short to use irritating software.
Past that point years back, kept going.
I just don't use anything Gnome related, if I can help it. I have found some things that unfortunately use the toolkit and somehow manage to not be intentionally irritating, but I assume that's an oversight to be corrected once I'm dependent on it.
Like is too short to use irritating software.
This 1000x. Apparently it's called being "opinionated" nowadays.
Related:
GNOME has no thumbnails in the file picker and my toilets are blocked - https://news.ycombinator.com/item?id=25719796 - Jan 2021 (724 comments)
GNOME has no thumbnails in the file picker and my toilets are blocked - https://news.ycombinator.com/item?id=25719796 - Jan 2021 (724 comments)
This comment might come off a little off-topic but I think it's pretty related.
The Gnome Project has always struck me of having this Apple-Like attitude of "We know Best", and subsequently ignoring/shrugging off user concerns/issues/etc.
It's pretty obvious that Gnome is at the very least "inspired" by macOS. Heck Apple started version bumping by whole numbers at right about the same time Gnome switched from 3.x to 4x.
I use it on my Touchscreen Convertible Laptop (with Wayland), since it supports multi-touch gestures (on the touchpad too), and as long as I install extensions to bend Gnome to my will, it seems to work pretty darn well for me. (For example, adding window tiling with the https://github.com/Leleat/Tiling-Assistant extension).
Perhaps there is a better way that I should switch too, but currently I remain ignorant.
The Gnome Project has always struck me of having this Apple-Like attitude of "We know Best", and subsequently ignoring/shrugging off user concerns/issues/etc.
It's pretty obvious that Gnome is at the very least "inspired" by macOS. Heck Apple started version bumping by whole numbers at right about the same time Gnome switched from 3.x to 4x.
I use it on my Touchscreen Convertible Laptop (with Wayland), since it supports multi-touch gestures (on the touchpad too), and as long as I install extensions to bend Gnome to my will, it seems to work pretty darn well for me. (For example, adding window tiling with the https://github.com/Leleat/Tiling-Assistant extension).
Perhaps there is a better way that I should switch too, but currently I remain ignorant.
At this point, it has become evident that they don't "want" to support this feature. So you're limited to what KDE has to offer if you need this.
Personally, I've bailed on the whole DE thing. Take the tiling-wm-pill and move on. Now I have to deal with tumblerd random high-cpu usages and thunar's unexpected crashes.
Personally, I've bailed on the whole DE thing. Take the tiling-wm-pill and move on. Now I have to deal with tumblerd random high-cpu usages and thunar's unexpected crashes.
I've not seen anyone using a tiling window manage with 32" and larger 4k displays. It's just an awful experience.
I would use a tiling window manager (and have) on something like a chromebook or if I'm a youtuber that does everything in a VM at 1080p. I have a hybrid approach that I use with XFCE (aggressive window snapping with custom shortcuts), but it's hardly a typical tiling window manager experience.
Regarding Thunar, I don't have any issues, but if you are not using it in XFCE, you might want to try and see what plugins you are loading. Some expect XFCE and could be the root of your issues.
I would use a tiling window manager (and have) on something like a chromebook or if I'm a youtuber that does everything in a VM at 1080p. I have a hybrid approach that I use with XFCE (aggressive window snapping with custom shortcuts), but it's hardly a typical tiling window manager experience.
Regarding Thunar, I don't have any issues, but if you are not using it in XFCE, you might want to try and see what plugins you are loading. Some expect XFCE and could be the root of your issues.
> I've not seen anyone using a tiling window manage with 32" and larger 4k displays. It's just an awful experience.
I'm using i3 / sway on both, my Workstation's 40" 21:9 (5120x2160) and my private 32" 16:9 4K displays, and see no reason why a bigger display, or one with a higher DPI, would make using a tiling window manager working worse, on the contrary, for me, it's all the more important to have good management if I got more "screen estate" to handle.
IME using tiling WMs on bigger/HiDPI screens is a fantastic experience.
I'm using i3 / sway on both, my Workstation's 40" 21:9 (5120x2160) and my private 32" 16:9 4K displays, and see no reason why a bigger display, or one with a higher DPI, would make using a tiling window manager working worse, on the contrary, for me, it's all the more important to have good management if I got more "screen estate" to handle.
IME using tiling WMs on bigger/HiDPI screens is a fantastic experience.
i’m also enjoying sway specifically on large displays. 34” ultrawide (21:9) 3440x1440. i had gnome running on it for a while but i specifically switched to sway because it’s easier to make use of the ridiculous real-estate. i can have like 4 separate vertical splits before it gets cramped. no one wants to manually position 4 windows on a screen.
i also run sway on my 14” laptop simply because i share my OS config between the two machines. i like its workspaces and notifications and being able to tweak `waybar` exactly how i want it, but the actual tiling functionality is pretty useless. at _most_ i’ll do two panes per workspace — at which point you’re in territory any DWM would do well in.
i also run sway on my 14” laptop simply because i share my OS config between the two machines. i like its workspaces and notifications and being able to tweak `waybar` exactly how i want it, but the actual tiling functionality is pretty useless. at _most_ i’ll do two panes per workspace — at which point you’re in territory any DWM would do well in.
When you have a single window in a workspace, isn't it too big? I feel like it would be weird having all my text on the left side of a huge monitor when I only have a single terminal in the workspace
Well I most of the time either split the screen into two halves, which is really nice if one needs to work with more than one application, searching some info on the right, pasting/writing it on the left) or for shells often use tmux and vim split views so that I can look at multiple files/source code lines and still have a ready to use terminal at hand.
For example, I most of the time use the following layout at work:
(note I recently switched workstation and while at it I tried to switch from i3 to sway, so the top bar config is really plain due to me having yet to find some time to port over my old i3bar one to waybar or the like)
Further workspaces are then for ssh windows for more complex real tests on some servers.
I use a lot of short-lived windows for terminal, browser, pdf-reader, ... and there the tiling window manager really shines, as I can effortless open those in some tens of milliseconds (MOD+Enter for terminals, MOD+D for my general window launcher), check what I need, maybe copy some text to the primary buffer by simply selecting it and then close it again With CTRL+D (EOF) for terminals or MOD+SHIFT+Q for any window.
For example, I most of the time use the following layout at work:
Workspace #1: Split into two stacked sides:
- on the left there's firefox open (sometimes two windows to
group tabs)
- on the right there's my mailer (thunderbird but I dabbled
with neomutt/notmuch too)
- either side holds an occasional shell for some local or remote
maintenance, quick calculation or doing something else
(note I recently switched workstation and while at it I tried to switch from i3 to sway, so the top bar config is really plain due to me having yet to find some time to port over my old i3bar one to waybar or the like)
Workspace #2: A single big tabbed assembly of terminal windows.
Each connects to a development VM (different projects and or major
releases, using Proxmox VE makes managing those VMs quite easy)
via SSH, in there I'm running tmux with a small screen part for a
shell on the left side and the remaining part for vim with split
panes on the right side
Further workspaces are then for ssh windows for more complex real tests on some servers.
I use a lot of short-lived windows for terminal, browser, pdf-reader, ... and there the tiling window manager really shines, as I can effortless open those in some tens of milliseconds (MOD+Enter for terminals, MOD+D for my general window launcher), check what I need, maybe copy some text to the primary buffer by simply selecting it and then close it again With CTRL+D (EOF) for terminals or MOD+SHIFT+Q for any window.
For single terminal in a single workspace, I use gaps around the window to center the terminal window.
But usually one would need another terminal window by the side of it and that's when I get rid of the gaps.
But usually one would need another terminal window by the side of it and that's when I get rid of the gaps.
I’ve never been able to make tiling work for me regardless of screen size. Windows constantly end up being awkward sizes that cause scrolling that would be unnecessary in a floating WM, and I’m constantly tweaking window sizes to try to make it less awkward. It’s very micromanage-y, and it drives me nuts.
But I don’t live in a terminal and/or text editor — my most frequently used programs are IDEs, VCS UIs, and graphics editors… stuff with lots of panes and palettes and such. Simpler apps get use too, but it’s skewed enough that popping some apps into floating mode in a tiling WM isn’t enough. My ideal environment is floating-first with light optional tiling, like macOS with something like Moom installed.
But I don’t live in a terminal and/or text editor — my most frequently used programs are IDEs, VCS UIs, and graphics editors… stuff with lots of panes and palettes and such. Simpler apps get use too, but it’s skewed enough that popping some apps into floating mode in a tiling WM isn’t enough. My ideal environment is floating-first with light optional tiling, like macOS with something like Moom installed.
You could do floating for all windows or for specific app in sway, that I'm using now, with for_window directive.
Yep, most tiling WMs come with really solid floating window options. i3wm with floating windows by default is such a treat!
I could probably make it work, but I'm not fond of the ultra-minimal window chrome that's standard with tiling-first WMs. Much prefer more traditional mouse-centric window chrome with fancy styling like that of GNOME, XFCE, macOS, etc.
> I've not seen anyone using a tiling window manage with 32" and larger 4k displays. It's just an awful experience.
I do this. How is it a bad experience? If anything I get more mileage out of my tiling WM on my large screen than I do on my laptop, where I tend to just use a lot of full screen apps and change tag/workspace a lot.
I do this. How is it a bad experience? If anything I get more mileage out of my tiling WM on my large screen than I do on my laptop, where I tend to just use a lot of full screen apps and change tag/workspace a lot.
Something like i3 would work great on a monitor like that. Something like dwm maybe less so.
I don't (because I have 3 24" displays), but at least two of my coworkers have 32" and larger 4k displays and use i3
Meh, I'm so disilluded that I've resorted to using nautilus as my file picker and just drag 'n dropping files from it into the program I want to open the file with.
Maybe you’ve tried it, but Xfce as DE plus i3 is for me the dream team.
I've done this. First I did pure BSPWM, then pure i3. Frankly, it's just too light for me. I spent so much time having to handle all these one-off scenarios like, hot-plugging multiple monitors, bluetooth, audio volume (with switching output when I plug into my big monitor). I had cobbled together so many scripts and I was constantly fighting with something that had worked the prior day. Having an actual environment under the hood made it much nicer.
I've had some weird issues with thunar too. Currently using spacefm after trying several options.
> Take the tiling-wm-pill and move on.
But that doesn't really solve the issue with the file picker...
But that doesn't really solve the issue with the file picker...
Yes but in a tilling setting, a new window (say Thunar), right beside your main app is just a single key-combination away. And it places the window correctly too. So you can drag-drop the file and close the auxiliary window.
Also, since a twm is not tied to a DE, you can pick KDE set of apps for example in i3. Then you'd have a file picker with thumbnails.
That said, I do neither of those things and I suffer from this bug. So you are right in a sense.
Also, since a twm is not tied to a DE, you can pick KDE set of apps for example in i3. Then you'd have a file picker with thumbnails.
That said, I do neither of those things and I suffer from this bug. So you are right in a sense.
I'm beyond grateful the Qt is not engineered by KDE.
I am now running a hybrid setup with KDE + i3. It works really well because I get to have all my network settings, display settings, etc on the fly, I can use konqueror, and i still get i3 nicely.
I am now running a hybrid setup with KDE + i3. It works really well because I get to have all my network settings, display settings, etc on the fly, I can use konqueror, and i still get i3 nicely.
Except... It is. There are a lot of contributions by KDE volunteers to Qt.
Luckily for the Gnome team, Microsoft ripped out features from their desktop interface in Windows 11. So Gnome might look comparatively functional when Windows 10 is EOL.
I came to Linux from a Windows world, so KDE always made more sense to me. I think, with the exception of 4.0, KDE has been fundamentally less bad than gnome since at least 2002. A sweet spot for me was KDE3.5 and then again current day KDE plasma. I like the customisability.
I think the gnome foot is a better icon, though.
I think the gnome foot is a better icon, though.
I suggest searching for JWZ CADT for a 19 year old article describing the same class of problems with Gnome.
My pet peeve: "<ctrl>-s filename <enter>" does something horrible instead of writing to filename.extension.
My pet peeve: "<ctrl>-s filename <enter>" does something horrible instead of writing to filename.extension.
Why no just link it: https://www.jwz.org/doc/cadt.html
Anyone who still has their brwoser sent cross-site Referer headers in $current_year deserves what they get.
Anyone who still has their brwoser sent cross-site Referer headers in $current_year deserves what they get.
The file picker has always been one of the weakest parts of our GUI paradigm, and it has been since the Mac.
Navigating file system via GUIs is slow, painful, and for me takes a ton of cognitive effort after a short amount of time of accumulating files. Coming up with a system for organizing files is kind of hard in itself. Reorganizing as the number of files outgrows the system is also painful.
And choosing a place to save a file is often the best time to start a reorganization. But if I save a file in a new location, having to switch apps and now go back to that same spot in the hierarchy and reorganize is painful.
I don't have a good solution, just complaints, unfortunately. But after ~50 years of GUIs and hierarchical file systems I'm surprised somebody more clever than me hasn't come up with a better solution.
Navigating file system via GUIs is slow, painful, and for me takes a ton of cognitive effort after a short amount of time of accumulating files. Coming up with a system for organizing files is kind of hard in itself. Reorganizing as the number of files outgrows the system is also painful.
And choosing a place to save a file is often the best time to start a reorganization. But if I save a file in a new location, having to switch apps and now go back to that same spot in the hierarchy and reorganize is painful.
I don't have a good solution, just complaints, unfortunately. But after ~50 years of GUIs and hierarchical file systems I'm surprised somebody more clever than me hasn't come up with a better solution.
This comment reminds me when Apple revamped Finder to include "All My Files". To me it felt like they were giving up. "FINE! Can't find something? HERE'S EVERYTHING!"
These sort of pseudo-directories honestly bother me more than just plain old hierarchy. For example on Windows, "This PC/Documents" is really "%userprofile%/Documents", but to get to %userprofile% you have to go to C:\Users\<username>. But there's TONS of other stuff that lives in %userprofile%
These sort of pseudo-directories honestly bother me more than just plain old hierarchy. For example on Windows, "This PC/Documents" is really "%userprofile%/Documents", but to get to %userprofile% you have to go to C:\Users\<username>. But there's TONS of other stuff that lives in %userprofile%
That's an example of a badly thought-out hierarchy. The pseudo-directories should be something like "This PC/My Files/Documents".
But it's not a good reason why pseudo-directories are bad.
But it's not a good reason why pseudo-directories are bad.
There's few things I despise more than the "All My Files" view, because it is so useless to me. Perhaps it works for some, however!
And it hasn’t evolved with cloud/sandboxing/magic-paths/whatever. Like today on the Mac I used the popup directory path to try to navigate to the parent directory (since it showed it to me, and it was selectable) and it couldn’t; it just threw me to my home folder as if that was my request. I can only assume it was some weird cloud thing but when path navigation itself is a question mark we have problems.
I've used KDE all this time and never noticed. Try it, it's not heavier than LXDE nowadays, which is saying something!
KDE 5.25 is very exciting, it feels great being on a desktop that gets updates where features are added instead of removed. Definitely the place to be in 2022!
I love the fact that right there on KDE.org there's a screenshot of Kontact with that big obnoxious vertical "HTML Message" black bar in the middle of the screen. I remember reading a bug report some 10 or 15 years ago to allow it to be hide-able somehow at least with the author just flat-out refusing to do it or allow patches for it.
I'll never use Kontact for this reason but I do like most of the rest of KDE.
I'll never use Kontact for this reason but I do like most of the rest of KDE.
kde gang
> First of all, how do developers so casually ignore this issue?
GNOME has never struck me as a project interested in implementating polish work. Polish work is disproportionately hard (it sometimes upends your understanding of the problem, forcing you to rethink your core structures, which impacts other features. In short, polish work has a tendency to explode).
> Second of all, how do users so casually ignore this issue?
GNOME users are accustom to polish not being the priority of the developers. Those who couldn't take it stopped using GNOME.
GNOME has never struck me as a project interested in implementating polish work. Polish work is disproportionately hard (it sometimes upends your understanding of the problem, forcing you to rethink your core structures, which impacts other features. In short, polish work has a tendency to explode).
> Second of all, how do users so casually ignore this issue?
GNOME users are accustom to polish not being the priority of the developers. Those who couldn't take it stopped using GNOME.
> GNOME users are accustom to polish not being the priority of the developers.
Wasn't the whole spiel of Gnome 3 that it was all about "UIXP" and perfection on defaults, sacrificing power-user functionality if necessary? That's effectively all about interfaces that do very little, but do it very well - i.e. they are super-polished, if less featureful.
It is true, though, that a lot of people stopped using GNOME. In fact, despite Ubuntu and RedHat effectively pumping users into the ecosystem for years, most Linux folks I know use either KDE or boutique DEs.
Wasn't the whole spiel of Gnome 3 that it was all about "UIXP" and perfection on defaults, sacrificing power-user functionality if necessary? That's effectively all about interfaces that do very little, but do it very well - i.e. they are super-polished, if less featureful.
It is true, though, that a lot of people stopped using GNOME. In fact, despite Ubuntu and RedHat effectively pumping users into the ecosystem for years, most Linux folks I know use either KDE or boutique DEs.
I don't know enough about GNOME's history, but I wonder if the people making those promises fell into the trap of believing that a more polished desktop environment would be one with cleaner code, and when they said super-polished they meant clean abstractions.
A super-polished UI (in the sense of "well-rounded, meets expectations, minimizes user surprise, behaves predictably") has messy abstractions because humans are messy. I've never met one that looked good on the outside and didn't have ugly snaggy bits on the inside to get all that good-lookingness to actually work in the corner cases. Perhaps GNOME has fallen into the trap of sacrificing features for purity of form. If they're saying things like "We'll have thumbnails when someone can figure out how to do it cleanly" they've fallen into that trap.
A super-polished UI (in the sense of "well-rounded, meets expectations, minimizes user surprise, behaves predictably") has messy abstractions because humans are messy. I've never met one that looked good on the outside and didn't have ugly snaggy bits on the inside to get all that good-lookingness to actually work in the corner cases. Perhaps GNOME has fallen into the trap of sacrificing features for purity of form. If they're saying things like "We'll have thumbnails when someone can figure out how to do it cleanly" they've fallen into that trap.
> sacrificing power-user functionality if necessary?
Scratch "if necessary". Power users have privilege, so deliberately throwing them curveballs for the sake of equitable outcomes seems to be the GNOME way.
Scratch "if necessary". Power users have privilege, so deliberately throwing them curveballs for the sake of equitable outcomes seems to be the GNOME way.
I want to downvote this for being outrageously cynical and mean-spirited, but also I'm afraid it could actually be true
Thumbnails are not polish. They’re an essential feature of working with images.
The devil's advocate response is "How essential could they be? We went decades without 'em."
I don't think it's the right answer, but it's an answer that works (GNOME continues to be the dominant Linux desktop environment in spite of lacking that feature).
I don't think it's the right answer, but it's an answer that works (GNOME continues to be the dominant Linux desktop environment in spite of lacking that feature).
Completely realizing you aren't actually making the "devil's advocate response," but I think the response to that is "We went for a millennia without electricity, too."
Just because we went without something, doesn't mean we should accept life without it at this point.
Just because we went without something, doesn't mean we should accept life without it at this point.
[deleted]
GNOME has enjoyed the status of being basically usable, if not particularly good, throughout its history.
I still remember KDE going through what felt like years of being unusably broken during its clumsy transition from 3 to 4. That's a lot of the desktop Linux experience, really - everything constantly in flux, never quite usable. I don't blame anyone for this, it's hard to get stuff done without someone paying a team to do it, but it's really unfortunate.
I still remember KDE going through what felt like years of being unusably broken during its clumsy transition from 3 to 4. That's a lot of the desktop Linux experience, really - everything constantly in flux, never quite usable. I don't blame anyone for this, it's hard to get stuff done without someone paying a team to do it, but it's really unfortunate.
After flip flopping a bunch, I ditched both GNOME and KDE for Xfce and haven't felt like I've missed much. It might need some better defaults, but you only have to fix them once on a new install.
Nothing huge changes, and really, I'm not looking for much. A launcher. A way to switch windows. Volume and brightness buttons/applets are nice to have. A system tray.
I've heard somebody somewhere along the lines call it the "Debian of DEs" and I can't argue with that.
Nothing huge changes, and really, I'm not looking for much. A launcher. A way to switch windows. Volume and brightness buttons/applets are nice to have. A system tray.
I've heard somebody somewhere along the lines call it the "Debian of DEs" and I can't argue with that.
If Apple or Microsoft had something like this "misfeature" in their OS, they could and likely would lose sales.
GNOME has no customers and can't lose sales, therefore they don't have to care at all.
GNOME has no customers and can't lose sales, therefore they don't have to care at all.
> If Apple or Microsoft had something like this "misfeature" in their OS, they could and likely would lose sales.
I disagree. Microsoft and Apple[1] had both had immense blunders that users hated, yet those users still paid money for the blunders.
At least with Gnome, people switched.
[1] I've used almost all the Window Managers and Desktop environments since 1995, I've used Windows since 1995. The current apple GUI is more painful to figure out than I had expected when I started using it last year. It's easily one of the least intuitive environments that I've come across, and watching non-tech users struggle with it reinforces my point.
I disagree. Microsoft and Apple[1] had both had immense blunders that users hated, yet those users still paid money for the blunders.
At least with Gnome, people switched.
[1] I've used almost all the Window Managers and Desktop environments since 1995, I've used Windows since 1995. The current apple GUI is more painful to figure out than I had expected when I started using it last year. It's easily one of the least intuitive environments that I've come across, and watching non-tech users struggle with it reinforces my point.
Sure - not everyone will stop using it, but some will, and that's lost sales. Even if it can't be quantified, the concept can be "sold" to some executive and get the problem fixed.
I mean, GNOME is the default on several commercially supported distributions. Redhat is the largest contributor. Granted, a lot of those commercially supported distributions are for customers who don't care about GUI uses but Ubuntu and RHEL/Fedora have a decent number of workstation users. KDE/Plasma have much less commercial support (AFAIK) and are probably closer to what you're saying, but at least to my tastes manage to be much more sensible.
But does anyone buy those - the very term "commercially supported" implies it's being marketed toward companies (think: enterprise) and everyone knows enterprise software is the most user-friendly ever invented (oh wait, the users are the purchasers).
Yet GNOME is the most polished Linux Desktop Environment.
It's easy to polish something that doesn't have many visible parts.
Isn't this a problem with open source in general?
It's hard to coordinate and improve software effectively among people with different ideas of what something should look like.
This is why Windows and Mac will always remain dominant desktop operating systems, I think. It only takes a few issues like this for a user to give up and go back to the big two players.
I'm not sure what the proper term is but having thousands of MS developers working and being led by managers, defined organizational processes and sense of direction vs hundreds of thousands open source developers led by their own ideas, what good and should look like, and different motiviation, a lack of coordination and a organisational process as big as a paragraph inside an obscure README.md
Too many cooks in the kitchen sour the soup.
It's hard to coordinate and improve software effectively among people with different ideas of what something should look like.
This is why Windows and Mac will always remain dominant desktop operating systems, I think. It only takes a few issues like this for a user to give up and go back to the big two players.
I'm not sure what the proper term is but having thousands of MS developers working and being led by managers, defined organizational processes and sense of direction vs hundreds of thousands open source developers led by their own ideas, what good and should look like, and different motiviation, a lack of coordination and a organisational process as big as a paragraph inside an obscure README.md
Too many cooks in the kitchen sour the soup.
Except for the part where tons of people are up in arms because MS removes or changes their UI. Fisher price, new control panel (XP), vista, UAC, start menu search, ads, mandatory logins, new control panel (8/10/11), new inflexible taskbar and so on
Except for the part where all of those people are Linux users who complain about Windows as a hobby, and have no effect on the relative market shares of Linux/Windows because they would never switch back to Windows under any circumstances.
"Everyone complaining about Windows changes are Windows-hating Linuxers" is only the second most insane take here after the dude upthread claiming everyone who complains about no thumbnails in Gnome's file picker is a Nazi.
You're right, I should clarify. I don't think that everyone complaining about Windows changes are Windows-hating Linuxers. Rather, I think that the majority of people complaining about Windows changes are Windows-hating Linuxers. I'd love to be proven wrong, however, because believing this is somewhat soul-crushing.
> Too many cooks in the kitchen sour the soup.
That sounds like a translation from another language? The English idiom is remarkably similar: "Too many cooks spoil the broth"
That sounds like a translation from another language? The English idiom is remarkably similar: "Too many cooks spoil the broth"
Everybody wants to make it into the "Too Many Cooks" credits.
https://www.youtube.com/watch?v=QrGrOK8oZG8
(Is that RMS with the machete?)
https://www.youtube.com/watch?v=QrGrOK8oZG8
(Is that RMS with the machete?)
Since the comments here are rapidly turning into a "dump on GNOME" section, does anyone know if there is a master list of "What the GNOME documentation calls an application" <-> "What everybody else calls an application"
e.g.
- "Passwords and Keys" <-> "seahorse"
e.g.
- "Passwords and Keys" <-> "seahorse"
I want a master cheatsheet for gnome commands too. These are some of the commands I needed to memorize when working with gnome:
nautilus <-> File Manager
evince <-> Document Viewer
eog <-> Image viewer
baobab <-> Disk Usage Analyzer
nautilus <-> File Manager
evince <-> Document Viewer
eog <-> Image viewer
baobab <-> Disk Usage Analyzer
Tbh KDE is worse at this because at least when you are using Gnome it won't call Nautilus Nautilus. It will call it Files, unlike on Plasma where Dolphin will be called Dolphin instead of being called Files or File Manager, which means that people who don't know Dolphin is the file manager will just be really confused as to what Dolphin is, especially if they don't already know that this icon always means file manager no matter what 0S you're on. Linus actually had this issue when he couldn't figure out what Kate was because he saw Kate and he thought what's Kate. Whereas on Gnome it would just say Text Editor instead of gedit. If you are using the terminal, you are more likely to know the actual name of the program so that's less bad for me. And on KDE if you are opening graphical applications through the console, you still have to open them through their weird code names. For example, Dolphin which makes no sense whatsoever. Just the same as Nautilus makes no sense whatsoever so that arguement is somewhat disingenuous.
If you are using the application menu, this is now fixed; there is a description next to items, and typing in the search includes searching in the menu; when I search for "editor" it shows emacs, vim, and ecrire (along with a couple other non text editor programs like "palette editor". Searching for "text editor' shows just the text editors; I don't have kate installed, but I assume it would show up here if it were.
Similarly dolphin shows "File Manager" next to it, and when I to search for "file manager" it is right at the top of the list.
Similarly dolphin shows "File Manager" next to it, and when I to search for "file manager" it is right at the top of the list.
I wouldn't have said this is really fixed, I think this is more of a workaround because KDE doesn't want to lose the names of their software. I think that an approach similar to Gnome's should be taken, where it has Files or Text Editor as the main name but if I search for nautilus or gnome-text-editor (or gedit) it will show the correct result. I do agree that it is better than nothing however.
Hmm mac os does this too (and tbh explaining to noobs that files are in the "Finder" gets perplexed stares, same with "Preview" for viewing pdfs?!?) "Explorer" isn't much better ...
However I can at least remember "Finder", "Preview" whereas I can never remember "eog" and have to look in old shell scripts to find out. Worst name ever with no way to discover it.
However I can at least remember "Finder", "Preview" whereas I can never remember "eog" and have to look in old shell scripts to find out. Worst name ever with no way to discover it.
I can't remember what Eye of Gnome is called in the shell, but it's probably something like Photo Viewer. I agree which you that Mac OS and Windows do this as well, but Windows at least calls it File Explorer, instead of just Explorer, at least on the graphical side. I think that Gnome and maybe also Pantheon do this best, with descriptive names that help new users, with code names that are used in the terminal, I suppose to differentiate between maybe Dolphin and Nautilus if someone has both installed.
For me, I use evolution for email, which uses the GNOME keyring and I couldn't for the life of me figure out that I needed to install seahorse to manage it.
Of course I'm not even remotely in their targeted user base since I don't run GNOME, but it annoyed me nonetheless.
Of course I'm not even remotely in their targeted user base since I don't run GNOME, but it annoyed me nonetheless.
That I will agree makes no sense whatsoever but usually that would be installed by default through the dependency list in your package manager. Dunno why it wasn't.
Can anyone explain why this bug has gone so long without a fix? Is it technically challenging to fix, or does the Gnome team disagree that thumbnails are necessary?
I read over the ticket[0] and from what I could see it was mostly bickering about the format of the patch or something. I didn’t really see any “ba humbug, command line is all you need” kinds of posts from some graybeard.
So in short it looks more like an organizational problem than a technical or even political problem.
[0] https://gitlab.gnome.org/GNOME/gtk/-/issues/233
So in short it looks more like an organizational problem than a technical or even political problem.
[0] https://gitlab.gnome.org/GNOME/gtk/-/issues/233
More like a disorganizational problem.
https://en.wikipedia.org/wiki/Conway%27s_law
>Conway's law is an adage that states organizations design systems that mirror their own communication structure. It is named after the computer programmer Melvin Conway, who introduced the idea in 1967. His original wording was:
>Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.
>— Melvin E. Conway
In Gnome's case, the structure of its design is a copy of its disorganized communication structure.
https://en.wikipedia.org/wiki/Conway%27s_law
>Conway's law is an adage that states organizations design systems that mirror their own communication structure. It is named after the computer programmer Melvin Conway, who introduced the idea in 1967. His original wording was:
>Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.
>— Melvin E. Conway
In Gnome's case, the structure of its design is a copy of its disorganized communication structure.
This reminds me of the problem with scrolling on Chromium, and now because of Electron a whole bunch of other programs. A single click of the scroll wheel moves the page by 100 px on Windows, for some reason it’s only 53 px on Linux, which means scrolling is twice as slow. This is not just compared to Windows, but it’s also much slower compared to other native Linux programs.
If you search for this issue, there are countless discussions and half broken attempts to work around this problem, including Chromium bug reports including some that are now nearly 10 years old. It’s 2022 and scrolling in Chromium and Electron apps with a mouse on Linux is still unbearably slow with no way to adjust that. There used to be a hidden CLI option, which was added for ChromeOS which probably had the same issue, but that was later removed.
The best solution I found so far is running patched libinput that multiplies the scroll amount delta by whatever you want, and having a daemon running which watches the window that is currently being scrolled and alters that scroll multiplier accordingly. It’s absurd that this is what I have to do to get acceptable scrolling behavior with a mouse on Linux.
If you search for this issue, there are countless discussions and half broken attempts to work around this problem, including Chromium bug reports including some that are now nearly 10 years old. It’s 2022 and scrolling in Chromium and Electron apps with a mouse on Linux is still unbearably slow with no way to adjust that. There used to be a hidden CLI option, which was added for ChromeOS which probably had the same issue, but that was later removed.
The best solution I found so far is running patched libinput that multiplies the scroll amount delta by whatever you want, and having a daemon running which watches the window that is currently being scrolled and alters that scroll multiplier accordingly. It’s absurd that this is what I have to do to get acceptable scrolling behavior with a mouse on Linux.
The program "imwheel" helped me work around an issue like this.
Have you tried disabling smooth scrolling?
Wow, I just read a rant on a site that hosts static websites, damn I miss that! Sounds like this person needs to snake his sewer line.
I found this article funny, engaging, and touched on a point that I’ve had for years about Linux on the desktop. (I won’t spoil it)
> This file picker does not have a thumbnail view. It is broken software. Thumbnails are not a cute little extra, they are essential. This is as bad as a file picker that doesn’t list the name of the files, only their creation date, or inode serial number. It is broken software. No, individual file previews aren’t "thumbnails."
As is unfortunately typical of articles like this, it overstates its case to the point of making it difficult to engage with. No, it isn't as bad as a file picker that doesn't list the names of the files. No, for most things one uses a file picker for, it isn't essential.
For that matter, I was actually completely unaware that my file picker (I use KDE) supports showing a thumbnail view. I did not know this because I have not ever needed to use such a feature. I use the file picker in "details" mode exclusively. On the rare occasional where I need to disambiguate two files because I don't know the name of what I'm looking for, the image preview has been more than sufficient.
I'll certainly grant that this is a feature that it makes a lot of sense for a file picker to have, and for a handful of use cases (trying to find a single image in a large directory of badly named image files) it might even be essential. But this tendency to overstate one's case is at the very least irritating, and IMO it leads to unwarranted attacks on developers that makes people shut down and resist spending their time on solving your problem.
As is unfortunately typical of articles like this, it overstates its case to the point of making it difficult to engage with. No, it isn't as bad as a file picker that doesn't list the names of the files. No, for most things one uses a file picker for, it isn't essential.
For that matter, I was actually completely unaware that my file picker (I use KDE) supports showing a thumbnail view. I did not know this because I have not ever needed to use such a feature. I use the file picker in "details" mode exclusively. On the rare occasional where I need to disambiguate two files because I don't know the name of what I'm looking for, the image preview has been more than sufficient.
I'll certainly grant that this is a feature that it makes a lot of sense for a file picker to have, and for a handful of use cases (trying to find a single image in a large directory of badly named image files) it might even be essential. But this tendency to overstate one's case is at the very least irritating, and IMO it leads to unwarranted attacks on developers that makes people shut down and resist spending their time on solving your problem.
> it’s much easier to accept mediocrity than to pursue adequacy.
pretty much describes most of today's software
pretty much describes most of today's software
File picker horror? Use the built-in file picker of Javas own Swing-Toolkit.
Integrating a GUI into a programming language library is inherently wrong. And while Sun was on the wrong path they doubled down and spread it across multiple platforms because they assumed their GUI was a solution. It wasn't and luckily Java based applications disappeared - with the exception of Java based developer tools.
Integrating a GUI into a programming language library is inherently wrong. And while Sun was on the wrong path they doubled down and spread it across multiple platforms because they assumed their GUI was a solution. It wasn't and luckily Java based applications disappeared - with the exception of Java based developer tools.
[deleted]
This seems to be a Linux exclusive problem. In general Linux is great, but there's so many people that really don't care about usability.
The problem with open source is that programmers often set priorities(Which is why I'm a fan of Cathedral model software).
FOSS programmers love to program so much, that everything they write is usually a tool to help make other programs.
Without outside feedback, or some kind of strong mission to really focus on the mainstream, the whole entire ecosystem can turn into jusr one massive IDE made of loosely coupled utilities.
The problem with open source is that programmers often set priorities(Which is why I'm a fan of Cathedral model software).
FOSS programmers love to program so much, that everything they write is usually a tool to help make other programs.
Without outside feedback, or some kind of strong mission to really focus on the mainstream, the whole entire ecosystem can turn into jusr one massive IDE made of loosely coupled utilities.
Dude, please, please get your drains fixed. It's bothering me now.
I finished the article unclear whether or not the toilet story is a parable.
> This bug has received over one hundred comments over the course of nearly two decades.
This is best counter argument to the old saw that “Open source will always get better.”
This is best counter argument to the old saw that “Open source will always get better.”
Yo... You know what's more retarded on this GNOME screenshot https://jayfax.neocities.org/mediocrity/Filepickermeme.png than the absence of thumbnails? The button order. Don't use GTK. Ever! Do you get me? [No][Yes]
This is a weird hill to die on. I've never cared much about the file picker and the individual file preview is "good enough" to ensure you pick the correct file. Now if Nautilus didn't have image previews in "icon view", then that's cause for rioting in the streets.
That just tells me that you never upload images, or that your image folder is not particularly large. If trackpad drivers were broken, that would still be a pretty big issue, even though you personally always use a mouse.
I upload files all the time and for some reason I don't encounter this problem in gnome. Just give the files appropriate names?
Seems like a channer problem. It's not suprising that no one from /g/ has made a patch yet.
Edit: Actually, I just checked and apparently it's because the file picker actually does show thumbnail icons, just very small ones. For example, https://files.catbox.moe/h3s3c3.png
I guess I can usually make out what the image is from the small thumbnail icons!
Seems like a channer problem. It's not suprising that no one from /g/ has made a patch yet.
Edit: Actually, I just checked and apparently it's because the file picker actually does show thumbnail icons, just very small ones. For example, https://files.catbox.moe/h3s3c3.png
I guess I can usually make out what the image is from the small thumbnail icons!
Thumbnails in your file picker are table stakes at this point.
Everyone has a cell phone capable of holding thousands of images, most of which won't get an appropriate title.
For example, I'm tiling a bathroom now. It was very easy to just take dozens pictures of tiles send them off for approval, and get the top five back for a further price check. That entire workflow was enabled by thumbnails. If we had to check the filename of each image we were sending, it would have slowed things down immensely.
Everyone has a cell phone capable of holding thousands of images, most of which won't get an appropriate title.
For example, I'm tiling a bathroom now. It was very easy to just take dozens pictures of tiles send them off for approval, and get the top five back for a further price check. That entire workflow was enabled by thumbnails. If we had to check the filename of each image we were sending, it would have slowed things down immensely.
“Appropriate file names”?
grand-canyon-001.jpg grand-canyon-002.jpg grand-canyon-003.jpg grand-canyon-004.jpg … grand-canyon-991.jpg
Or maybe
grand-canyon-east.jpg grand-canyon-west.jpg grand-canyon-north.jpg grand-canyon-south.jpg … grand-canyon-northeast.jpg
Thumbnails solve real problems and other guis have had this as a completely solved problem since literally the mid-nineties.
grand-canyon-001.jpg grand-canyon-002.jpg grand-canyon-003.jpg grand-canyon-004.jpg … grand-canyon-991.jpg
Or maybe
grand-canyon-east.jpg grand-canyon-west.jpg grand-canyon-north.jpg grand-canyon-south.jpg … grand-canyon-northeast.jpg
Thumbnails solve real problems and other guis have had this as a completely solved problem since literally the mid-nineties.
I rename files as I download them (or copy them from my phone/camera) or I just remember the file name that I downloaded. I suppose it's a problem if you have to deal with many unnamed images, but if it really came down to that I would just open up nautilus.
> but if it really came down to that I would just open up nautilus.
So, the downstairs toilet.
So, the downstairs toilet.
Haha, nice but I bet that's going to puzzle some people who haven't read TFA
I use the downstairs toilet is for bulk shits, the upstairs toilet is for petite loads.
There can't be a more classical linux/developer response to a serious UI issue than "I just do this other repetitive manual task to solve the problem, don't see what the big deal is."
>It's not suprising that no one from /g/ has made a patch yet.
They did. Apparently the Gnome devs didn't want it. You can get it from the AUR.
https://gist.github.com/Dudemanguy/c172394e30e1e7d0f477ad15c...
https://aur.archlinux.org/packages/gtk3-patched-filechooser-...
They did. Apparently the Gnome devs didn't want it. You can get it from the AUR.
https://gist.github.com/Dudemanguy/c172394e30e1e7d0f477ad15c...
https://aur.archlinux.org/packages/gtk3-patched-filechooser-...
Seeing the picture you want to upload is a channer problem?
You guess you just use proper file names?
This attitude is EXACTLY what the author is describing, and why Linux on the desktops fails to take hold.
You guess you just use proper file names?
This attitude is EXACTLY what the author is describing, and why Linux on the desktops fails to take hold.
The problem is that channers complain, but do not do productive things like file PRs. So problems that matter to channers will remain unresolved.
If you want something done right, do it yourself. Commercial software is no exception to that.
>why Linux on the desktops fails to take hold.
Linux fails to take hold because it doesn't come preinstalled on laptops, and because it doesn't have the critical market share to take over. Basically nothing to do with file pickers.
The ideal use case is just using drag-and-drop behavior from the file manager, instead of implementing the file manager twice. The reality is that products like Windows have shaped people into thinking about the desktop in a certain way, and linux has limited leeway in reshaping those ideas (including their idiosyncrasies like file pickers).
If you want something done right, do it yourself. Commercial software is no exception to that.
>why Linux on the desktops fails to take hold.
Linux fails to take hold because it doesn't come preinstalled on laptops, and because it doesn't have the critical market share to take over. Basically nothing to do with file pickers.
The ideal use case is just using drag-and-drop behavior from the file manager, instead of implementing the file manager twice. The reality is that products like Windows have shaped people into thinking about the desktop in a certain way, and linux has limited leeway in reshaping those ideas (including their idiosyncrasies like file pickers).
It is obscenely ridiculous to say that people complaining about a missing usability feature that every other tool on the market has, marks somebody as a channer.
As clearly stated in the article, there had been an open issue for almost a decade, and PRs rejected.
When windows is beating you in usability, you have a serious problem.
As clearly stated in the article, there had been an open issue for almost a decade, and PRs rejected.
When windows is beating you in usability, you have a serious problem.
There have been PRs made to fix this issue which have been rejected, because Gnome hate their users.
People don't make PRs because they've seen how difficult it is to get anything done with the GNOME project. So often is there a fix pr or patch that satisfies the code style and standards, but gets rejected despite user demand because, well, the maintainers don't want that thing fixed or changed. Or they do, but they want to make some sort of point by rejecting a change at that time.
GNOME is one of the weirder and more difficult projects for a stranger to contribute to if your change does not fit into a very narrow and specific set of current priorities (unknown to the outside contributor, so good luck!). It is another world-of-wontfix poster child projects and I don't begrudge anyone who doesn't want to go through the hassle compared to most other open source projects they can spend their time on.
Eventually, you're left with just pointing out how ridiculous something is with GNOME and moving on. You're just not going to be able to get a fix merged regardless of merit, quality or tact. It isn't worth the pain.
GNOME is one of the weirder and more difficult projects for a stranger to contribute to if your change does not fit into a very narrow and specific set of current priorities (unknown to the outside contributor, so good luck!). It is another world-of-wontfix poster child projects and I don't begrudge anyone who doesn't want to go through the hassle compared to most other open source projects they can spend their time on.
Eventually, you're left with just pointing out how ridiculous something is with GNOME and moving on. You're just not going to be able to get a fix merged regardless of merit, quality or tact. It isn't worth the pain.
Consider reading the linked post, the author includes screenshots identical to yours and explains that that is not what they mean.
> Seems like a channer problem.
Whether you like 4chan or think anybody who goes there is the devil incarnate, using 4chan as your excuse for dismissing such basic functionality as thumbnails in a file picker is deranged. Why not abolish file pickers entirely, since 4chan uses it? In fact lets ban drinking water too, I hear nazis like to drink it. Ban air too, we wouldn't want anybody using it to say something hateful. Is there any insanity "but 4chan exists!" can't be used to justify?
Whether you like 4chan or think anybody who goes there is the devil incarnate, using 4chan as your excuse for dismissing such basic functionality as thumbnails in a file picker is deranged. Why not abolish file pickers entirely, since 4chan uses it? In fact lets ban drinking water too, I hear nazis like to drink it. Ban air too, we wouldn't want anybody using it to say something hateful. Is there any insanity "but 4chan exists!" can't be used to justify?
I don't really have anything against channers. I'm just saying it's a problem that one small group disproportionately complains about but does little to fix. I think that is pretty indicative of /g/ discourse which revolves around baiting other users into flamewars.
Every mainstream desktop has thumbnails in the file picker. People who want this aren't the odd ones, those who dismiss it are.
> I don't really have anything against channers.
I seriously doubt that, since you're the one who brought them up in an absurd attempt to deflect a common sense criticism of an obvious shortcoming.
> I don't really have anything against channers.
I seriously doubt that, since you're the one who brought them up in an absurd attempt to deflect a common sense criticism of an obvious shortcoming.
>People who want this aren't the odd ones, those who dismiss it are.
fair enough.
>I seriously doubt that, since you're the one who brought them up in an absurd attempt to deflect a common sense criticism of an obvious shortcoming.
See my defense of channers in these threads: https://news.ycombinator.com/item?id=31554117 https://news.ycombinator.com/item?id=31554152 https://news.ycombinator.com/item?id=31554112
fair enough.
>I seriously doubt that, since you're the one who brought them up in an absurd attempt to deflect a common sense criticism of an obvious shortcoming.
See my defense of channers in these threads: https://news.ycombinator.com/item?id=31554117 https://news.ycombinator.com/item?id=31554152 https://news.ycombinator.com/item?id=31554112
You'd expect the file picker and nautilus to share behaviour though, right? Also for me, if I open the file picker from Chrome/Edge/an Electron app it's forced full screen and there's no preview on the right either.
I love GNOME, use it on both desktop and laptop, but this is one of those things that's just bad.
I love GNOME, use it on both desktop and laptop, but this is one of those things that's just bad.
I definitely agree that it's strange that Nautilus can do this and the file picker can't. I also agree that consistency is important, but this issue has never caused me problems so I don't think anything of it. There are other things in Gnome that are keeping me from using it after being a vocal supporter for decades.
I think the difference is that GtkFilePicker is a part of the running GTK program, like firefox for example. If you wanted to get all of nautilus' features, you would have to embed all of nautilus into your program, including features that would be innapropriate fir a file picker
Maybe instead of just using GtkFilePicker on linux, it should first check if there's an available "xdg-file-picker" in the environment, which gnome sets to nautilus with some flags to run it in file-picker mode.
Maybe instead of just using GtkFilePicker on linux, it should first check if there's an available "xdg-file-picker" in the environment, which gnome sets to nautilus with some flags to run it in file-picker mode.
Embedding Nautilus doesn't mean enabling all its features.
That said, I don't know if that's a problem, either. Windows does exactly that for its file picker - it's basically embedded Explorer, complete with context menu integration etc. And it works.
That said, I don't know if that's a problem, either. Windows does exactly that for its file picker - it's basically embedded Explorer, complete with context menu integration etc. And it works.
I don't have image previews ;)
Huh... I just opened Pluma in MATE and used the file opener, and it had image previews in the list view. I never really paid much attention to this though, so no idea if the MATE team added it or what.
They are a bit smaller than I'd like though... let's see if there's a configuration option for that.
They are a bit smaller than I'd like though... let's see if there's a configuration option for that.
> Huh... I just opened Pluma in MATE and used the file opener, and it had image previews in the list view. I never really paid much attention to this though, so no idea if the MATE team added it or what.
But, MATE isn't Gnome. That's almost their slogan, how could you not know?
But, MATE isn't Gnome. That's almost their slogan, how could you not know?
Heh. Well, it's a fork of Gnome2 which was their main selling point. I just can't remember if these previews existed in Gnome2 before the fork or not.
Per TFA:
> No, individual file previews aren’t "thumbnails."
> No, individual file previews aren’t "thumbnails."
I mean that every line in the file picker has a small image beside it.
It's just that since it's a list view, they are a bit smaller than I'd like (set to line height). I guess increasing line height or font size would help. Nonetheless it's good enough for roughly figuring out what image is what.
I tested both in Pluma and Firefox - this seems normal for MATE file pickers, but I don't know if it was normal in Gnome2 as well and I never noticed.
I tested both in Pluma and Firefox - this seems normal for MATE file pickers, but I don't know if it was normal in Gnome2 as well and I never noticed.
The article mentions the availability of thumbnails in list view and considers that insufficient: "It’s still only in list view, this is somehow worse"
I read the entire mediocre post. I need to take a dump now. Luckily, my toilets both flush, so I can choose whichever is most convenient. Right now I wish I had a third one in the basement, but that would require a pump, which would likely fail.
The Gtk file picker has for years offered a notoriously horrendous user experience. A lot of critical functionality is missing in the name of the GNOME people's vaunted simplicity or what-not.
... although reading superkuh's comment, maybe the explanation is more mundane (and sad) than that.
... although reading superkuh's comment, maybe the explanation is more mundane (and sad) than that.
the sad situation of desktop Linux is kind of reminiscent of democracy and how people work in general.
[deleted]
In case anyone is interested: https://gitlab.gnome.org/GNOME/gtk/-/issues/233
This was reported before some HNers were even born.
Someone remind me: When was the "Year of the Linux Desktop"?
For me it was around 2008, when kompiz came on Ubuntu ... those were good years.
When I try to attach a file in Chrome on Linux, it shows a file picker that defaults to only showing files I recently uploaded, which is the exact opposite of what I want.
Switched to KDE because of stupid crap like that. Never ever looked back
My advice: download a live-system with a KDE desktop and give it a spin, maybe?
My advice: download a live-system with a KDE desktop and give it a spin, maybe?
Here is the ultimate problem with GNOME. It is essentially a lie.
What I mean: Imagine you bought a ticket for Matrix 4, and they showed John Wick.
That's what GNOME 3 did. They made a new and different product; whether you like it more or less than the last one isn't the point. They betrayed the reliance we had on the old thing by a "lie of omission." A more honest approach would have been to name Gnome 3 something different (and perhaps hand the Gnome name off to the MATE people?)
What I mean: Imagine you bought a ticket for Matrix 4, and they showed John Wick.
That's what GNOME 3 did. They made a new and different product; whether you like it more or less than the last one isn't the point. They betrayed the reliance we had on the old thing by a "lie of omission." A more honest approach would have been to name Gnome 3 something different (and perhaps hand the Gnome name off to the MATE people?)
so the technical question then is: how can i replace the file picker that the apps on my desktop use?
a startingpoint for answers may be here: https://superuser.com/questions/944119/replace-gtk-file-dial...
there is an xdg-desktop-portal feature that allows this, or pretend that a different desktop is used by setting XDG_CURRENT_DESKTOP for the application, as well as KGtk which is a library that can be loaded with LD_PRELOAD.
either of these have to be applied per application though.
there is an xdg-desktop-portal feature that allows this, or pretend that a different desktop is used by setting XDG_CURRENT_DESKTOP for the application, as well as KGtk which is a library that can be loaded with LD_PRELOAD.
either of these have to be applied per application though.
Fork those apps, remove GTK, add Qt.
stick a note onto the commode or the toilet door that reminds your family members of the fact.
This is a great example of "that's an explanation, not an excuse", albeit a weird one
O_o
O_o
Gnome design is sometimes weird.
With recent donation from Microsoft, GNOME will surely fix this critical issue, right?
Is that a blog of someone from Trolltech? Tell them their site doesn't support OS-managed dark theme switching.
— No, using custom CSS isn't "dark mode"
— No, using custom CSS isn't "dark mode"
> No, using custom CSS isn't "dark mode"
I mean, in this case, it literally is as easy as adding an alternate CSS style and then managing the proper dark-mode switching.
...not that this is really a concern in the first place. If you read through someone's blog and the best comment you have is on their website's OS integration, I think you've got your priorities misaligned.
I mean, in this case, it literally is as easy as adding an alternate CSS style and then managing the proper dark-mode switching.
...not that this is really a concern in the first place. If you read through someone's blog and the best comment you have is on their website's OS integration, I think you've got your priorities misaligned.
Easy is a comparative evaluation.
To someone it's easy to recompile Nautilus with one of the thumbnails support patches or implement thumbnails generation via an external script.
Literally.
To someone it's easy to recompile Nautilus with one of the thumbnails support patches or implement thumbnails generation via an external script.
Literally.
Yes it does. I'm looking at a thumbnail in my Gnome file picker right now. I'm on Fedora 36 (Gnome 42)
Edit: It looks like the specific complaint is that the Gnome file picker does not allow icon view. That is true, but I still see two thumbnails: one next to the actual file, and one in the thumbnail pane.
A better title might be "Gnome has no file picker icon view and I create flamebait titles."
Edit: It looks like the specific complaint is that the Gnome file picker does not allow icon view. That is true, but I still see two thumbnails: one next to the actual file, and one in the thumbnail pane.
A better title might be "Gnome has no file picker icon view and I create flamebait titles."
ls doesn't show a preview either.
When forced to use windows the first thing I do is turn this feature off. Something doesn't feel right when a tool to list files tries to process content of files (e.g. image processing did come with severe security holes in the past, and it probably still does today).
Both of my toilets are working perfectly though.
When forced to use windows the first thing I do is turn this feature off. Something doesn't feel right when a tool to list files tries to process content of files (e.g. image processing did come with severe security holes in the past, and it probably still does today).
Both of my toilets are working perfectly though.
Your toilets work because you keep a jug of water next to them to pour directly into the bowl to flush it, because you disconnected the toilet tank. You've decided that a tool that tries to remove waste shouldn't also intake water. After all, intakes have failed in the past and flooded houses.
Better to do that part by hand to be on the safe side.
This is the nature of desktop UI. Your argument for purity of function is sound, but users want their desktop UI to read images for thumbnails and previews anyway because an image file means more to them, semantically, than a pile of inscrutable bits inside a file pointer. Desktops, over time, become a junk drawer of the features "most users want" for "controlling their computer" in the space between dedicated programs.
Better to do that part by hand to be on the safe side.
This is the nature of desktop UI. Your argument for purity of function is sound, but users want their desktop UI to read images for thumbnails and previews anyway because an image file means more to them, semantically, than a pile of inscrutable bits inside a file pointer. Desktops, over time, become a junk drawer of the features "most users want" for "controlling their computer" in the space between dedicated programs.
file-picker is a GUI tool whose language is visual instead of text. If ls must do text processing and formatting to output that colorful list, so too must file-picker do image processing to complete its function.
The writer seems willingly disingenuous. Not having a feature isn't the same as having a bug. The software is behaving exactly as designed. Do you say that older versions of windows develop "bugs" as soon as a newer version adds a new feature? Of course not.
I agree with the conclusion though, these little missing conveniences add up to a worse experience for converts. I understand open source apps choosing not to do things exactly the same way as proprietary solutions, but we at least need something as good.
That said, it has always been the case that if a feature didn't exist in the pile of software that was freely and openly provided to you, you would either contribute the feature yourself or just go elsewhere. So the bounty would have sufficed, there is no point in being a shithead about it.
I agree with the conclusion though, these little missing conveniences add up to a worse experience for converts. I understand open source apps choosing not to do things exactly the same way as proprietary solutions, but we at least need something as good.
That said, it has always been the case that if a feature didn't exist in the pile of software that was freely and openly provided to you, you would either contribute the feature yourself or just go elsewhere. So the bounty would have sufficed, there is no point in being a shithead about it.
As of right now if you File->Open in any program using modern Gtk3 and try to paste a file path in you'll get an error instead of pasting your filepath in a text field to open, "The folder contents could not be displayed\nOperation not supported" http://erewhon.superkuh.com/gtkfilechooserwidget-paste-fail....
It's unfixable behavior because the GNOME devs stopped respecting their own gsettings, org.gtk.Settings.FileChooser location-mode, to FORCE the path-bar experience on everyone. Because no one needs to type file paths, apparently. So why bother respecting the settings for path-bar or filename-entry? Their demographic doesn't care. Unfortunately gtk3 is used by far more than GNOME's demographic.
They have fixed this bug in gtk4, for all the good that does.