201–210 of 756 posts
Earlier quoted context omitted.
It's not permanently disabled, it enables itself when you are editing text (for example, if you're renaming a file).
I think we're talking about copying-and-pasting files in this thread, rather than text in input boxes, as you're thinking.
GNOME is in general terrible for everything with image related work (last tested on Ubuntu 20.04). In the past I thought finder on macOS is terrible (it's still the worst piece of macOS and I don't like it) but GNOME files aka Nautilus tops it for sure (also because of space wasting issues). XFCE and KDE both do a better job than GNOME in this regard. And also Windows Explorer was and is much much better in this area…
Why do you don't like Finder? I couldn't think any issue with it.
Tested on El Capitan through to Mojave.
There's more serious reasons this file picker is broken. Here's a trivial to reproduce and obvious issue that's been there for several years now: 1. Open a directory that loads slowly (e.g. one with thousands of files on a smb3 mount) 2. While the list is loading, select a file (but do not open it) 3. Wait for the whole list to load Once the list finishes loading, the file on the very top of the list gets automatical…
Picking directories has been pretty broken forever as well. Say you start in ~/Downloads/foo and want to store the file in ~/Downloads, then navigating up will have "foo" selected, with usually no blank space to un-select (so you'd need to do ctrl+click or something to that tune); clicking "Save" (or whatever) will then descend into that directory instead of saving, so just using the mouse, or not using any shortcuts…
(I actually asked someone more knowledgable about this once and was told that it's my fault for using the file picker incorrectly and I simply need to stop doing that.)
Earlier quoted context omitted.
Tools and features have ergonomics and affordances that suggest a certain way of using them, and desktop filling just seems to encourage people to make a massive mess. Even when I was a Windows user, desktop icons were the first thing to go. Not having quick access to a dumping ground meant that I had to go out of my way to make a mess. As for a lack of system tray icons, the practical upshot is that my system bar is…
> As for a lack of system tray icons, the practical upshot is that my system bar isn't littered with multiple special snowflake applications, each with their own unique icon art style and mismatching proportions. Plasma Desktop's System Tray widget that lets you hide icons you don't want to see. You can disable the widget, or configure it to show no icons at all.
With default being off, it is applications that have to be careful. They can use it, when they detect it is present, but cannot assume it anymore.
Earlier quoted context omitted.
What’s a save panel? You mean a save dialog? Note that on windows there are at least 3 generations of save dialogs. Which one you see depends on which generation of the api is used. The most common one is the more modern which is basically just an explorer window. Dragging a file into an explorer window works that same regardless of whether it’s an open/save dialog or not. It’s a move/copy operation (depending on e.g…
The ability to set the destination folder to a folder you have open in a file manager window without copy-pasting the path is convenient. But at the same time, the file-management capabilities of the macOS file picker are basically non-existent (although there seem to be more right-click options in Big Sur?)
You can also choose to Show in Finder.
If you managed to mouse over that one single pixel in the corner you were allowed to resize the window...
Linux was always a Terminal-first OS. The UI efforts never came close to the depth that MacOS and Windows have. Take for example the scaling issue. It has been now almost half a decade with 4k Displays, and Linux still does not know how to deal with it other than 100% or 200%. Currently Linux is unusable for anyone with a modern display. I appreciate the work that all the contributors put -for free- in projects like…
Suffice to say, that this isn't a solved problem everywhere else.
Earlier quoted context omitted.
Picking directories has been pretty broken forever as well. Say you start in ~/Downloads/foo and want to store the file in ~/Downloads, then navigating up will have "foo" selected, with usually no blank space to un-select (so you'd need to do ctrl+click or something to that tune); clicking "Save" (or whatever) will then descend into that directory instead of saving, so just using the mouse, or not using any shortcuts…
Wow I never thought about Ctrl+Click to deselect in that situation. I've probably wasted at least an hour of my life by giving up and re-opening the window in a different way. Thanks! (I actually asked someone more knowledgable about this once and was told that it's my fault for using the file picker incorrectly and I simply need to stop doing that.)
Earlier quoted context omitted.
>I’m having trouble even imagining the insane event-processing architecture that results in keystrokes being processed out of order. It's relatively simple: the picker executes file-opening asynchronously, and only checks which file was selected at some indeterminate point after enter is pressed. In the meantime, the down arrow input in the main GUI changes the selection. The keypresses are always in order. Whether o…
> Whether or not that's the correct decision, it's not an inconceivable design. I'm having trouble with the part of the design where we recognize that a file is selected (such that pressing causes a file to open), see the keypress, and then fire an event saying "open any file, whichever one you feel like" as opposed to "open this file right here, the one we can see is selected". If, as you maintain, the keystrokes ar…
I don't find such a design that surprising. If you like simplicity, you would be tempted to go for it, because it doesn't involve duplicating data (namely, the selected filepath) between the main GUI state and the event handler for opening the selected file. If you're writing in a memory-managing language like C, it's even more tempting - by not copying data, you don't risk forgetting to free it later.
Pretty sure 99% of regular people would be happy if there was a desktop with GNOME 2 feature parity but with a good Wayland compositor and probably some modern features that would come from that (multimonitor, VRR, ...). I just can't understand how anyone could defend GNOME 3. Their own staff have to use extensions (that break every update), even Fedora (!!!) has to patch GNOME packages now. They kept fighting that t…
>> Pretty sure 99% of regular people would be happy if there was a desktop with GNOME 2 feature parity but with a good Wayland compositor You mean like the ability to put things on the desktop? There's even a desktop folder, but well.... I use gnome and I agree with you.
I remember thinking "what on earth were they thinking" the first time I realized that none of the usual way of putting things on the desktop worked on modern Gnome. Absolutely baffling. Breaking such a well established convention is pure hubris in my book.
I'd be perfectly fine if this was a niche DE that you'd have to go out of your way to install but this is bloody Gnome, the de-facto standard DE for Linux. Absolute insanity.