Whisker Menu already puts results that are recently used higher in the results.
Recently (in the last couple of days), I notice that this desired behavior is inconsistent.
Specific example: I often access "Screenshot" from whisker menu, while it's been months/almost a year since I accessed "Screensaver" from the menu.
My recollection from the past is that the whisker menu would occasionally bump Screensaver up to the top (when searching e.g. "scre"), but, after I used Screenshot once or twice, for the rest of that session it would tend to favor Screenshot. I'm okay with this.
However, lately, whisker menu stubbornly insists that I really meant Screensaver, even if I just used Screenshot 5 minutes ago. I eventually got fed up with this and used "Hide application" on Screensaver -- it was that bad.
(One alternate approach would be to supplement "recently used" with data about frequency of use.)
C is spawned from B, so my expectation is that it will inherit its sort order from B. so I would like to see them sorted by name.
Thunar's logic instead seems to be: "Well, the last time you requested a sort order (in A), it was by date -- so the new tab should be sorted by date."
I realize there isn't any objective criterion to determine which of these is "correct." But I can report, as a user for, oh, 4-5 years now, every time I go through this sequence (which is often), it always -- always -- confuses me. I suppose it's a difference of opinion, but I find it unintuitive.
Why would one go through this sequence? Well, this just happened. I have a folder for one of my courses -- so I navigated to this folder (name sorting). Then I opened a new tab for the downloads folder, and chose Date sorting to bubble recently-downloaded homework files to the top. Then I realized I also needed another tab for a different course folder. So I went back to the course folder, created a new tab, and -- hello -- date order -- but at the moment of creating the new tab, the ordering I had been looking at was by name.
Here is a typical thing that happens multiple times a day for me.
Actual behavior: An item is currently selected which a/ I did not request, b/ may not even match the characters I typed, and c/ may not even have any direct relationship with the mouse pointer.
Expected behavior: The menu should ignore the mouse position until I actually touch and move the mouse. (It should respond to mouse motion. It should not respond to the presence of a stationary mouse pointer within the menu's bounds.)
In this screenshot, note that I'm searching for "ema" and, if I press return at this point, it will helpfully(?) open LibreOffice Math (????!!! why???!!!!???!!!???) and not Emacs as I would expect.
Also note the tool tip for "E-Book Editor." This tells me that the menu initially put LibreOffice Math a couple of rows higher, and picked up the item based on the mouse position -- and then late-arriving search results pushed LO Math lower. (Again, my expected behavior is at least that nothing would be selected at this point, or that the best match = "Emacs (GUI)" would be selected.)
User impact: As this happens multiple times every day, this is -- the next word is carefully chosen -- infuriating. It is pitch-the-computer-out-the-flipping-window maddening. It is ridiculous. I am very happy with XFCE in almost all respects, but this is very nearly a dealbreaker. There is no justification for this behavior. Please fix it.
I can't recreate this with 2.4.3, maybe it is a difference in versions of GTK? What version of GTK 3 do you have?
Synaptic reports libgtk 3.24.20.
Selection follows the mouse in menus. It does in the fancier menus of Windows, KDE, Cinnamon, etc. It does even with regular menus: open a file menu in a program by typing Alt+F, and when you move the mouse the selection will snap to where the mouse is if it is already over the menu.
I should clarify one detail: The menu selection does not jump to the mouse position upon opening the menu (by hotkey) -- this is the same for an application menu.
It does jump to the mouse position when typing characters to search.
(Hm, perhaps I should doublecheck -- when you are trying to reproduce the issue, are you typing any characters?)
It is a graphical menu in a graphical environment--most users are going to use the mouse.
There is one ergonomic problem with the mouse that has never been solved: You have to remove your hand from the keyboard. I recall that the first Macintosh machines released to market didn't have any arrow keys -- "why would you need arrow keys? It's a graphical environment and you have a mouse." Later Macintosh versions added arrow keys. Why? Because when you're typing, it's disruptive to have to reach for the mouse. You don't need keys to position the pointer, but users found that they didn't like it when the mouse was the only way, and Apple eventually had to accede.
If I'm coding (keyboard heavy activity) and I want to open a web browser to search for something, it's much more user-friendly if I can do it with a few keystrokes rather than the interface enforcing mouse usage. (OK, for a web browser I can hit Super-W, fine. It could be a more exotic application with some resource that I need.)
If you are using the hotkey only to search Whisker Menu, you could set the hotkey to call xfce4-popup-whiskermenu -p and have the menu popup at the mouse cursor position instead of from the panel.
That's an acceptable workaround, thanks. I disagree with you about the mouse, but I'll close the issue with this.
Yousuf:
Can you let me know what version of whisker menu you are running, as i'm not able reproduce it on version 2.5.3.
Ah, Ubuntu Studio 20.04 ships with menu version 2.4.3 (assuming that xfce4-popup-whiskermenu --version
is the right way to ask).
Graeme:
For the list and tree views I just enable the GTK option to have it select what is under the mouse cursor.
I see -- in that case, my issue report is that this decision, at least in some environments, has unintended side effects.
Perhaps the solution would be to make it configurable, then. I can imagine some users might be happy with it as it is, but it's driving me spare. (The workflow to open an app should be 1/ hotkey, 2/ type a few characters, 3/ enter. The workflow for me currently is 1/ worry about the mouse position, 2/ hotkey, 3/ type a few characters, 4/ look very carefully to be sure the mouse has not interfered, 5/ either move the mouse or hit enter if there was no problem.)
Here is a typical thing that happens multiple times a day for me.
Actual behavior: An item is currently selected which a/ I did not request, b/ may not even match the characters I typed, and c/ may not even have any direct relationship with the mouse pointer.
Expected behavior: The menu should ignore the mouse position until I actually touch and move the mouse. (It should respond to mouse motion. It should not respond to the presence of a stationary mouse pointer within the menu's bounds.)
In this screenshot, note that I'm searching for "ema" and, if I press return at this point, it will helpfully(?) open LibreOffice Math (????!!! why???!!!!???!!!???) and not Emacs as I would expect.
Also note the tool tip for "E-Book Editor." This tells me that the menu initially put LibreOffice Math a couple of rows higher, and picked up the item based on the mouse position -- and then late-arriving search results pushed LO Math lower. (Again, my expected behavior is at least that nothing would be selected at this point, or that the best match = "Emacs (GUI)" would be selected.)
User impact: As this happens multiple times every day, this is -- the next word is carefully chosen -- infuriating. It is pitch-the-computer-out-the-flipping-window maddening. It is ridiculous. I am very happy with XFCE in almost all respects, but this is very nearly a dealbreaker. There is no justification for this behavior. Please fix it.