Bug 147585

Are you actually suggesting kpdf to change how menus work in KDE?

Oh, it appears so :-) I thought Kpdf uses its own kind of popup menu (it is the only app I saw with static "labels" in the popup menu).

"static labels"? We just use a standard popup menu with one or two titles in it. (And we're not the only application that uses them.)

Ok, I don't know every KDE app, I saw it for the first time in KPdf and _I_ don't know any other app.

Could you please reassign this to kdelibs (?) -- in my case I would gain most in Kpdf, but in any other app this is true, one keypress saved.

I don't agree - that would introduce a different behaviour with any other KDE application.

Closing then.

What do you mean by that? I just asked you to reassign this report (I don't have enough priviliges) to kdelibs so _EVERY_ app would preselect by default the first enabled item in the popup menu.

So, there would be no "other KDE" app, because all of them would behave in uniform way.

Maciej,

I agree with Pino here. This would introduce a behaviour totally different to what we know and are used to (also from competing platforms). Your suggestion might make sense to you in this special situation, and I am sure you'd easily adapt to it and use it in other applications. However the benefit (saving one keystroke) doesn't outweigh the possible pitfalls for other users:

It is not guaranteed that the first entry is always the same entry. Under certain circumstances this could lead to a destructive situation where the user just hit ENTER thinking it would mean "copy" (since it always was the first preselected entry) whereas copy had been somehow disabled and the first entry moved to "delete". Here the extra keystroke serves as an additional "buffer".

Also your suggestion could appear as awkward/strange when the menu is invoked with a mouse click and doesn't pop up to the bottom but the top of the mouse pointer. Preselecting the topmost entry would seem out of place there.

> Also your suggestion could appear as awkward/strange when the menu is
> invoked with a mouse click 

You cannot preselect anything then. Because selecting items depends only on mouse cursor position. This is not the case I discuss.

> This would introduce a behaviour totally different to what we know and are
> used to (also from competing platforms). 

So, do I understand you correctly:
a) do not make KDE any more productive, because users are not used to that
b) narrow KDE productivity to the most unproductive platform available, this way no one is confused since we have the common "lowest divisor"

?

> Your suggestion might make sense to you in this special situation, 

Answer honestly -- what is your mouse/keyboard usage ratio? Because I sense there you are talking from position "one keystroke less, one keystroke more, what the difference, use mouse" (no offence, just guessing).

> However the benefit (saving one keystroke) doesn't outweigh the possible
> pitfalls for other users: 

One keystroke * a day (thousand ? here) * a year --> 300,000 keystrokes.
http://en.wikipedia.org/wiki/Repetitive_strain_injury

It is all fun when you don't have any problems with your hands.

> It is not guaranteed that the first entry is always the same entry. 

Florian, I know there are various apps, there are various menus even! in the same app. Besides you cannot select disabled item. 

I put this in other perspective -- you press menu key, you saw that the first (enabled of course) item in the menu is selected. What you do? Panic? Would you be really confused? What real harm (please, common sense here) is done by selecting this first (available) item?

I really appreciate KDE for reducing my RSI, in windows, keyboard navigating virtually does not exist, quite contrary in KDE -- it is very keyboard productive, I would like to see it even better. When health is on the stake, I choose it -- try some task requiring thousand of _the same_ keystrokes, you will pray you could save some of them, I guarantee that.

PS. In the first paragraph I meant RMB of cours (I assumed you meant the same too). Not from auto popup menu, which happend after mouse action (like in KPdf).

However this gives me idea -- when popup menu was invoked by RMB -- select the closest item if it is enabled. This would benefit, when you use your mouse with one hand and keyboard with the second -- click, and hit enter. It could be very fast.

Maciej,

if you're suffering from RSI and depend on limiting keystrokes to a minimum I suggest getting familiar with keyboard accelerators. They are even faster than the concept you suggested and already widely used in KDE applications. I am not speaking of (modifier key) + (key) to invoke an action here but of the one-key-shortcuts that are available (or at least should be) to any menu entry. Unfortunately I have to admit that for the select tool pop up the accelerator action doesn't seem to be available (at least with my configuration).

Does this solve your problem?

Florian, thanks for the reply, but it is the simply math.

Current implementation: two keystrokes (small key + big one).
Your "saving": two keystrokes (on my keyboard one big key + small one, but on regular keyboard: two small keys). Not mentioning, every app has to support this.

I don't see any benefit here, especially when comparing to one keystroke only (on almost all keyboards I know: one big key).

Again: what harm is done by preselecting item? Or in other words: if this helps people work more efficiently why not do it?

Maciej,

_every_ menu entry (not just the first one), whether it is from the file menu or from a pop up menu, is quickyl reachable via accelerator keys with just two (RMB-key on keyboard + key) to three (ALT + key + key for entries in the menu bar) keystrokes. This is already working with any KDE application. It is superior for the afore mentioned reasons. Your suggestion may be useful for your special case but in general just isn't worth introducing a new default behaviour.

Florian,

> _every_ menu entry (...) is quickyl reachable via accelerator 

Nope.

Every menu entry having accelerator is reachable via accelerator.

So... what about entries that do NOT have accelerators?

> So... what about entries that do NOT have accelerators? 

This is actually a bug :-) I have a patch almost ready for it, so no need to report it.