Live data from Hacker News

GNOME has no thumbnails in the file picker and my toilets are blocked

jayfax.neocities.org

191–200 of 756 posts

Re: GNOME has no thumbnails in the file picker and my toilets are blocked

#191

Earlier quoted context omitted.

I promise you people have gotten this right. I have a 198? Mac Plus on my desk that I can boot up and do this on and it will work properly. I’m having trouble even imagining the insane event-processing architecture that results in keystrokes being processed out of order. Edit: Alright, alright, forget the old computer. My new ones get it right too. All of which is a red herring, because the point is this behavior is…

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

To sound like Linus Torvalds, "that's braindead stupid!"

I have never looked at the code in question, but it almost sounds like the developers went out of their way to create these ridiculous bugs, because the simplest solution definitely would not have something like that happen: The handler for Enter gets the current selection (which will definitely be the correct one) and opens it.

The actual opening can be slow, so that can be done asynchronously. But to interpret "Enter opens the current selection" as anything other than the current selection at the time the Enter key event was received is definitely in the realm of rookie mistake if not worse.

If getting the current selection of a UI control somehow needs to be done asynchronously, then something is seriously wrong.

As a long-time Win32 programmer, the manifestations of these bugs are definitely hard to conceive.

Re: GNOME has no thumbnails in the file picker and my toilets are blocked

#192

Earlier quoted context omitted.

I promise you people have gotten this right. I have a 198? Mac Plus on my desk that I can boot up and do this on and it will work properly. I’m having trouble even imagining the insane event-processing architecture that results in keystrokes being processed out of order. Edit: Alright, alright, forget the old computer. My new ones get it right too. All of which is a red herring, because the point is this behavior is…

>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 are processed in order, then at the time is processed, we specifically take notice of which file is selected. (Because, as I said above, we only know that should open a file at all because we see that a file is selected.) We fire the file-opening event after that. This isn't a mistake we can make by accident; we'd have to be making it on purpose.

I can see where the assumption that the keystrokes are being reordered comes from; it's much less insane than what you're proposing.

Re: GNOME has no thumbnails in the file picker and my toilets are blocked

#193

On macOS, when you drag a file into an Open or Save panel, the panel’s current directory switches to the dragged file’s containing directory and highlights that dragged file. On Windows, when you drag a file into an Open or Save panel, the dragged file is moved from its original location to the panel’s current directory. It is a destructive action! That may be one little thing but it’s part of a whole number of reaso…

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…

Yes, a save panel is a save dialogue. It’s just Apple terminology.

> I don’t quite get the point of dragging a file to a save dialog at all though?

On macOS (since forever) and iOS (since 11), there is a heavy focus on drag. You should be able to drag anything from any app to any other app and something should happen.

This is facilitated both by system-level frameworks (so that all apps can gain correct drag-handling behaviour out of the box) and can be further enhanced by an app’s developer.

That begins with behaviour you might ordinarily expect from most apps: drag a image file from Finder into a Word, it should embed the picture; drag an audio file from iTunes into an open Audacity project, it should add the audio as a new track; or, drag highlighted text from a text field to the desktop and it will create a text snippet file containing that text.

On Windows, apps need to implement this behaviour manually. Figuring out how to deal with certain file types is not built into every app out of the box.

On macOS and iOS, it’s not just built into every app, it’s built into the operating system itself. It’s a fundamental feature of Cocoa, open which all native apps are built, so every app gets the correct behaviour for free. Dragging and dropping is super powered on Apple platforms.

For example, proxy icons: on any given document window (a window for an open document, like a Word document, Photoshop document, Final Cut project, etc), the name of the document is preceded by an icon that represents the document. You can actually drag that icon off the window’s title bar to any other on-screen element that supports receiving dragged objects — an open document, a Finder window, an email, a text field, etc.

I say all of this to cement one point: dragging and dropping is a key interface metaphor on macOS and iOS/iPadOS.

So, imagine I have a browser window open asking me to upload a file. If I have that file open, why should I navigate the directory hierarchy in the open panel? I can just drag the proxy icon for that document straight into the open panel. Bam, the open panel is pointing at the correct location.

Or perhaps I’ve just downloaded an image from the web that I want to share with my friend. Again, I can open up my favourite messaging program, click on the Add Attachment button, and drag the image in from my Dock’s Downloads stack.

(Although, that’s a slightly odd example; I wouldn’t bother with the Add Attachment button, I’d actually just drag the file directly from the Downloads stack on to the app and expect it to figure out what I want to do)

For save panels, I might already have a folder open in Finder where I want my document to be saved. When I save the document for the first time and the save panel appears, I can either drag that folder or its proxy icon from Finder straight into the save panel — bam, the save panel is pointing to the correct place.

Or perhaps I want to save a file into the same place as an open document. Again, I would just drag the proxy icon of an already-open document into the save panel, bam, we’re looking at the right folder.

Notice: these actions are non-destructive. Non-destructive actions follow the principle of least surprise. All I’m doing is telling an open/save panel where I want to be.

> That to me as a Windows user seems alien. I expect it to work as an Explorer window!

Ask yourself what the basic function of an open/save panel is: to select a location for a file (and in the case of a save panel, give it a name). Of the four CRUD operations, only C and R are directly relevant.

Something shouldn’t act as something else, especially if it’s destructive. That, in my opinion, violates the principle of least surprise — an interface to C or R should not U or D.

The only thing I expect to act as an Explorer window is … an Explorer window.

Re: GNOME has no thumbnails in the file picker and my toilets are blocked

#195

Windows' file picker is actually an almost fully-featured Explorer instance, and is easily accessible from any application with a single function call. The "loose components" model that a lot of OSS seems to follow means that things like this require more effort, despite the fact that GNOME is supposed to be an integrated environment. What’s the point of doing a whole upgrade of the GTK toolkit while ignoring this pr…

Or maybe no one who's in the position to implement a feature like that or get it integrated wants it enough to prioritize it over new features. Some aspects of perfection are subjective.

Addendum: I'm not arguing icon view is not a great feature though.

Re: GNOME has no thumbnails in the file picker and my toilets are blocked

#196

On macOS, when you drag a file into an Open or Save panel, the panel’s current directory switches to the dragged file’s containing directory and highlights that dragged file. On Windows, when you drag a file into an Open or Save panel, the dragged file is moved from its original location to the panel’s current directory. It is a destructive action! That may be one little thing but it’s part of a whole number of reaso…

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?)

Re: GNOME has no thumbnails in the file picker and my toilets are blocked

#197

Earlier quoted context omitted.

>the existing convention It is the existing convention, the Mac Finder convention. And yes, it's effectively the same as cut and paste.

Do you not think that it's terrible UX, to have cmd+x followed by cmd+v for cut and paste in some places and cmd+c followed by option+cmd+v for cut and paste in others?

[deleted]

Re: GNOME has no thumbnails in the file picker and my toilets are blocked

#198

You will find lots of such examples of a feature which you personally find very important and wonder why such a simple thing is not supported yet. I guess everyone has such examples. And you will also find such examples for MacOSX or Windows. For me personally, I wonder why mouse wheel/scroll acceleration is still not implemented. I implemented it a while ago for Xorg, which is outdated now, and also the maintainer w…

On macOS, I install https://github.com/emreyolcu/discrete-scroll to disable scroll acceleration, because I find it annoying, and macOS has no config option to disable it.

Re: GNOME has no thumbnails in the file picker and my toilets are blocked

#200
post #65

Earlier quoted context omitted.

Let's do another... Open any directory with 3+ items. As first item is highlighted, quickly hit , , . The 3rd item opens... There is a lag when hitting and the last is processed out of order :/

Incidentally, that lag is there independent of how fast your disk is, it seems. It's kind of annoying.

That's likely the fault of the GVFS and other virtual-fs-on-top-of-kernel-VFS layers. Gtk seems to be slower than others (such as KIO/KDE), but all of them are pretty slow. E.g. the KDE file picker takes about a second or so to finish listing the contents of my home directory (though it is usable while it is doing so, unlike the Gtk dialog), where the Gtk takes quite a bit longer (perhaps on the order of 3-5 seconds). Meanwhile ls is essentially instant, as you'd expect for just a few thousand files or so.
Post reply on HN