9

Now if you clink on item in menu - it auto-closes immediately. I think its ridiculous.

Lets say you would like to show additional info like file size, data and user in dolphin.

You have to do 9 clicks:

1. View
2. Additional information
3. Size
4. View
5. Additional information
6. Date
7. View
8. Additional information
9. User

Instead of 5, not counting wasted time when moving mouse repeatedly.

1. View
2. Additional information
3. Size
4. Date
5. User

Last version

How to implement?

Menus should not auto close in these scenarios:

• User clicks on checkbox or icon left to menu entry text
• User clicks with ctrl + left click anywhere
• User clicks with mouse wheel anywhere
• ??? Delay before closing menu like in 1st version below ???

* bold best options for usability and "findability"




1st version

How to implement?

Lets say default time-out for hiding menus are 7 secs.
When user clinks on form-style item, set timeout to 1 sec, continue moving browsing menu, reset back to 7 secs.

If you done changing preferences, just move mouse out and it hides as usual
Want to change something more - just don move mouse away

Edit:
Let user to set timing manually. -1 would mean not to close menu unless user clicks anywhere outside menu.

Simple as 2x2

You could also just make it so the menu stays open unless you click outside the menu or move the mouse outside the menu for a certain period of time.

Do you mean I could do it now? Where?

No, I mean as an alternative to your time limit idea.

I think it would be better if the menu doesn't close if you hold down a key, e.g. ctrl. This is consistent with nte rest of KDE, where ctrl often is used to select multiple items.

The bad thing is that it's very hard to discover, and so I just had another idea: if the user clicks on the "checkbox" in the menu (yes, exactly on the box), the menu doesn't close. How does that sound? It also works with the ctrl feature described above (ctrl+click anywhere and the menu doesn't close[1]).

The benefit of this implementation is that it won't get in the users' way, and there is no "magical" autohiding. On the other hand, it probably isn't possible with Qt at the moment[2], which is a problem...

-
1. By the way, isn't there a similar feature request for KMenu (traditional application launcher) to launch many applications? It sounds familiar.
2. Just a guess, I don't know how it really works.

Hans wrote:I think it would be better if the menu doesn't close if you hold down a key, e.g. ctrl. This is consistent with nte rest of KDE, where ctrl often is used to select multiple items.

Why didn't I thought about this

Hans wrote:if the user clicks on the "checkbox" in the menu (yes, exactly on the box), the menu doesn't close.

I would like to change to

Code: Select all

if the user clicks on the "checkbox" OR icon in the menu (yes, exactly on the box or icon), the menu doesn't close.

Since not only checkboxes are just selectable, like view -> preview



To addition to

Hans wrote:This is consistent with nte rest of KDE, where ctrl often is used to select multiple items.

The middle button is unused when selection items. Might be we should use it as an alternative next to ctrl + left click?

---
Updating 1st post ....

qt allow you to add the most used options to a toolbar.

Unfortunately, no new toolbar creation is allowed, but you can have buttons for "size", "date", etc details in your toolbar. Those checkboxes & co in menu are not intended to be changed very often, in toolbars they do.

However, the ctrl-click thing couldn't do any harm. Just forget about the different behavior for text/icon, the timeout or the need to click elsewhere, please! Use menus for what they are for.