11 ms·

Let's do another... Open any directory with 3+ items. As first item is highlighted, quickly hit <down arrow>, <enter>, <down arrow>. The 3rd item opens... Ther

by ht85 6y ago

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

buckminster 6y ago
This is bad but it's not unusual. There are similar issues in Firefox and Windows. Nobody gets UI asynchrony right. There are race conditions in everything. It's particularly noticeable with a slow computer.
- danaliv 6y ago
  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 ridiculous and never should’ve shipped.
  - ivanbakel 6y ago
    >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 or not that's the correct decision, it's not an inconceivable design. That example is probably one of the only times it would matter, since you would need async code that cares about some part of the file picker state.
    - ballenf 6y ago
      Why wouldn't the <enter> key interrupt or freeze the keypress queue? I don't think you need some advanced async logic to get this right. The only potential downside would be if people expected to be able to cancel the <enter> action. But that would be unusual, I think.
      - ivanbakel 6y ago
        As a rule of thumb: if you ever ask "why not", and the alternative you're proposing is more complicated - that is normally why not. Lots of UI/UX bugs can simply be attributed to the programmer taking the most simple possible design. In this case, the async logic is not advanced. In fact, I'm willing to bet that this is what happened: at first, the file-opening was synchronous in the GUI. People complained that opening certain files locked up the file picker, so a developer sticks the file-opening code in a background thread. This produces the above bug, without complicating the input design - in fact, preventing the bug requires making additional changes to the code in some way.
        ballenf 6y ago
        Thanks that makes total sense. And a good rule of thumb for me to remember.
      - toast0 6y ago
        You can't do work on the UI thread, it'll block the UI! With only half a /s
    - freeone3000 6y ago
      Why does the enter keypress save the relative index instead of the actual target of the action? Even Windows gets this one right.
    - userbinator 6y ago
      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.
  - buckminster 6y ago
    All old computers get it right. They are not doing UI asynchrony. It's a fairly recent problem.
    - danaliv 6y ago
      My new computers get this right too. This is a design flaw.
    - mkl 6y ago
      Keyboard maybe. That same old Mac probably processes mouse events out of order: when it was being slow you could click on something then move the mouse somewhere else, and it would click the new place instead.
  - viraptor 6y ago
    That Mac cannot multithread the UI interactions. It doesn't have to be a keystroke processing issue. It can be "hey window parent, I've got your result in my properties, pick it up" which doesn't get processed before the next event changes the related property. It's almost a classic TOCTOU issue.
    - deleted 6y ago
      [deleted]
    - edoceo 6y ago
      Time of check, Time of Use https://en.m.wikipedia.org/wiki/Time-of-check_to_time-of-use https://en.m.wikipedia.org/wiki/Time-of-check_to_time-of-use
  - masswerk 6y ago
    However, the Mac was about the only system getting this right by rigorously prioritizing UI events on the system level. (Which is also, why applications like Photoshop on Windows weren't a viable option for professional users for some time, until hardware became faster. How do you draw or paint, if the events representing your gestures are not synchronized, as they are subject to system load?)
- jfoster 6y ago
  It's akin to typing and having the characters appear out of order, isn't it? Are those particular keys more difficult to process?
  - efreak 6y ago
    Only if each key has its own function to process that keystroke, and some keystrokes had to do more processing and thus take more time about it. Selecting an item in a list view is a fast, simple process; what happens after that isn't up to the list view anymore.
- Ndymium 6y ago
  LibreOffice had (has?) a similar strange race condition when typing. When the computer was acting slow and LibreOffice Writer was lagging, the Finnish layout's characters äöå would jump to the front of the typing queue somehow. So if I typed "menkäämme", I might get "äämenkmme" when LibreOffice finally renders the typed text. I don't know if it still occurs but it was really annoying and I always wondered how on earth it could happen.
tomsmeding 6y ago
Incidentally, that lag is there independent of how fast your disk is, it seems. It's kind of annoying.
- formerly_proven 6y ago
  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.
  - ubercow13 6y ago
    KIO is pretty fast I think. Dolphin is insanely fast at least - if you list a large directory almost everything that can't be loaded instantly is loaded asynchronously and streamed in to the UI after the UI becomes responsive. I think the KDE file picker is using other code altogether, I'm not sure why it's so much slower. GIO is horribly slow and makes everything that uses it next to useless, eg [1] [1] https://github.com/lxqt/pcmanfm-qt/issues/462 https://github.com/lxqt/pcmanfm-qt/issues/462
    - InfiniteRand 6y ago
      Interesting explanation at the end of the bug report: The slowness is only caused by the GIO's G_FILE_ATTRIBUTE_STANDARD_CONTENT_TYPE and g_file_info_get_content_type. Wherever they are used, there will be a slowdown because the contents of files, that lack extensions, should be read for finding their mimetypes. Almost all the time is taken by that; the other operations are done pretty fast — particularly, the Qt GUI takes no time in comparison.
      - ubercow13 6y ago
        Yes, actually reading that it makes it sound like the file manager itself is just badly architechted - of course you shouldn't load mimetypes synchronously before listing a folder in the UI, that seems obvious. So maybe I'm not right about GIO as such. But Nautilus is also excruciatingly slow despite being more fully asynchronous.
j1elo 6y ago
Assuming an asynchronous UI programming model, I can only conceive this happening because they skipped having a proper Model and instead the View is accessed directly (in the Mode-View-Controller way of thinking). However the most disturbing thing is that events might get to be processed our of order. Even if you stored current state in a proper Model, there is nothing you can do if your event queue ends up being "<down>, <down>, <enter>". I guess that's why Qt prefers to do all UI event processing exclusively in a single thread. The event queue will always be serviced in order.

by ht85 6y ago

buckminster 6y ago

This is bad but it's not unusual. There are similar issues in Firefox and Windows. Nobody gets UI asynchrony right. There are race conditions in everything. It's particularly noticeable with a slow computer.

danaliv 6y ago
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 ridiculous and never should’ve shipped.
- ivanbakel 6y ago
  >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 or not that's the correct decision, it's not an inconceivable design. That example is probably one of the only times it would matter, since you would need async code that cares about some part of the file picker state.
  - ballenf 6y ago
    Why wouldn't the <enter> key interrupt or freeze the keypress queue? I don't think you need some advanced async logic to get this right. The only potential downside would be if people expected to be able to cancel the <enter> action. But that would be unusual, I think.
    - ivanbakel 6y ago
      As a rule of thumb: if you ever ask "why not", and the alternative you're proposing is more complicated - that is normally why not. Lots of UI/UX bugs can simply be attributed to the programmer taking the most simple possible design. In this case, the async logic is not advanced. In fact, I'm willing to bet that this is what happened: at first, the file-opening was synchronous in the GUI. People complained that opening certain files locked up the file picker, so a developer sticks the file-opening code in a background thread. This produces the above bug, without complicating the input design - in fact, preventing the bug requires making additional changes to the code in some way.
      - ballenf 6y ago
        Thanks that makes total sense. And a good rule of thumb for me to remember.
    - toast0 6y ago
      You can't do work on the UI thread, it'll block the UI! With only half a /s
  - freeone3000 6y ago
    Why does the enter keypress save the relative index instead of the actual target of the action? Even Windows gets this one right.
  - userbinator 6y ago
    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.
- buckminster 6y ago
  All old computers get it right. They are not doing UI asynchrony. It's a fairly recent problem.
  - danaliv 6y ago
    My new computers get this right too. This is a design flaw.
  - mkl 6y ago
    Keyboard maybe. That same old Mac probably processes mouse events out of order: when it was being slow you could click on something then move the mouse somewhere else, and it would click the new place instead.
- viraptor 6y ago
  That Mac cannot multithread the UI interactions. It doesn't have to be a keystroke processing issue. It can be "hey window parent, I've got your result in my properties, pick it up" which doesn't get processed before the next event changes the related property. It's almost a classic TOCTOU issue.
  - deleted 6y ago
    [deleted]
  - edoceo 6y ago
    Time of check, Time of Use https://en.m.wikipedia.org/wiki/Time-of-check_to_time-of-use https://en.m.wikipedia.org/wiki/Time-of-check_to_time-of-use
- masswerk 6y ago
  However, the Mac was about the only system getting this right by rigorously prioritizing UI events on the system level. (Which is also, why applications like Photoshop on Windows weren't a viable option for professional users for some time, until hardware became faster. How do you draw or paint, if the events representing your gestures are not synchronized, as they are subject to system load?)
jfoster 6y ago
It's akin to typing and having the characters appear out of order, isn't it? Are those particular keys more difficult to process?
- efreak 6y ago
  Only if each key has its own function to process that keystroke, and some keystrokes had to do more processing and thus take more time about it. Selecting an item in a list view is a fast, simple process; what happens after that isn't up to the list view anymore.
Ndymium 6y ago
LibreOffice had (has?) a similar strange race condition when typing. When the computer was acting slow and LibreOffice Writer was lagging, the Finnish layout's characters äöå would jump to the front of the typing queue somehow. So if I typed "menkäämme", I might get "äämenkmme" when LibreOffice finally renders the typed text. I don't know if it still occurs but it was really annoying and I always wondered how on earth it could happen.

tomsmeding 6y ago

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

formerly_proven 6y ago
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.
- ubercow13 6y ago
  KIO is pretty fast I think. Dolphin is insanely fast at least - if you list a large directory almost everything that can't be loaded instantly is loaded asynchronously and streamed in to the UI after the UI becomes responsive. I think the KDE file picker is using other code altogether, I'm not sure why it's so much slower. GIO is horribly slow and makes everything that uses it next to useless, eg [1] [1] https://github.com/lxqt/pcmanfm-qt/issues/462 https://github.com/lxqt/pcmanfm-qt/issues/462
  - InfiniteRand 6y ago
    Interesting explanation at the end of the bug report: The slowness is only caused by the GIO's G_FILE_ATTRIBUTE_STANDARD_CONTENT_TYPE and g_file_info_get_content_type. Wherever they are used, there will be a slowdown because the contents of files, that lack extensions, should be read for finding their mimetypes. Almost all the time is taken by that; the other operations are done pretty fast — particularly, the Qt GUI takes no time in comparison.
    - ubercow13 6y ago
      Yes, actually reading that it makes it sound like the file manager itself is just badly architechted - of course you shouldn't load mimetypes synchronously before listing a folder in the UI, that seems obvious. So maybe I'm not right about GIO as such. But Nautilus is also excruciatingly slow despite being more fully asynchronous.

j1elo 6y ago

Assuming an asynchronous UI programming model, I can only conceive this happening because they skipped having a proper Model and instead the View is accessed directly (in the Mode-View-Controller way of thinking). However the most disturbing thing is that events might get to be processed our of order. Even if you stored current state in a proper Model, there is nothing you can do if your event queue ends up being "<down>, <down>, <enter>". I guess that's why Qt prefers to do all UI event processing exclusively in a single thread. The event queue will always be serviced in order.