This CC, from the KDE-Frameworks ML, seems appropriate for discussion
here (I think). The issue which is brought up is not the framework
itself- but rather, widespread HIG "errors" and
and "inconsistencies" which are written into KDE Applications. We should
IMO, take one of these alternative steps:
(1) Stay "loose" with our own guidelines, and say that they are only
"generally appropriate recommendations" for KDE Applications and
Components; or
(2) start writing Bugs against instances of unnecessary deviation from
KDE's keyboard HIG.
How shall we go? Separately, Mark suggests a re-do of some existing HIG
(at the very bottom).
On 05/16/2012 11:06 AM, Mark wrote:
On Sun, May 13, 2012 at 10:58 PM, Mark <mark...@gmail.com
<mailto:mark...@gmail.com>> wrote:
On Sun, May 13, 2012 at 10:11 PM, Rick Stockton
<rickstock...@reno-computerhelp.com
<mailto:rickstock...@reno-computerhelp.com>> wrote:
On Saturday 12 May 2012 18:36:42 Mark wrote:
<< snip >>
Here's our online reference for KDE keyboard shortcut HIG:
/http://techbase.kde.org/Projects/Usability/HIG/Keyboard_Shortcuts
Ctrl-M toggles the visibility of the bar /(without selecting
it). Some KDE Applications implement this (e.g. Gwenview,
Dolphin), but others do not (e.g., KDevelop). None of these 3
applications provide "Focus to the Menu Bar" via F10, as
documented in our guidelines. Dolphin uses that key to create
a new item, and the other two seem to completely ignore the
key event.
I'll recheck the Qt "StandardKey" table and documentation
later tonight , maybe scribble some fixes. But it looks like
Wikipedia is wrong about "Alt + M" on KDE.
BTW, Here are some other references for keyboard shortcuts:
http://developer.apple.com/library/mac/#documentation/userexperience/conceptual/applehiguidelines/KeyboardShortcuts/KeyboardShortcuts.html#//apple_ref/doc/uid/TP40002725-SW2
<http://developer.apple.com/library/mac/#documentation/userexperience/conceptual/applehiguidelines/KeyboardShortcuts/KeyboardShortcuts.html%23//apple_ref/doc/uid/TP40002725-SW2>
http://msdn.microsoft.com/en-us/library/windows/desktop/bb545461.aspx
http://developer.gnome.org/hig-book/3.0/input-keyboard.html.en#standard-shortcuts
/>/ While looking at that wiki list i'm quickly realizing that
we're never
/>/ going to get a standard keyboard + mouse mapping for
generic keys across
/>/ all major desktop environments.
That's because no such conventions exist- yet. We'll be the
first to create them. It's possible that the GNOME people will
cooporate with us, and share certain values, if we let them
know what we came up with. (That would be helpful, of course.)
Helpful == Helpful for both Developers AND end-users. (That's the end of
my reply; the following is all from Mark.)
For Ctrl + M, there was a technical reason why it wasn't just ctrl
- like in windows - but i forgot the reason. If someone could
explain the reasoning behind that?
While looking at the shortcut for switching tabs i notice that kde'
own SC apps are not even following it.
According to the docs:
Next tab: Ctrl+PageUp
Previous tab: Ctrl+PageDown
Doesn't work in:
Dolphin (uses Ctrl+tab for forward and Ctrl+shift+tab for backward)
Konsole (uses Shift+left and Shift+right)
Rekonq (uses Ctrl+tab for forward and Ctrl+shift+tab for backward)
Konqueror (uses Ctrl+tab for forward and Ctrl+shift+tab for backward)
then i stopped testing...
I would like to propose to follow the browsers here and make their
de-facto standard the HIG guideline. As an alternative i would add the
current konsole ones. That would mean:
Next tab:
- Primary: Ctrl + tab
- Alternate: Shift + Right
Previous tab:
- Primary: Ctrl + shift + tab
- Alternate: Shift + Left
I'm guessing that all current KDE SC apps that use tabs are to be
adjusted to either follow the current HIG or to follow my proposal.
What's your opinion on using the browser tab shortcuts as the shortcuts?
Cheers,
Mark
_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
