HIG standards (
Mark
markg85 at gmail.com
Wed May 16 18:06:30 UTC 2012
On Sun, May 13, 2012 at 10:58 PM, Mark <markg85 at gmail.com> wrote:
> On Sun, May 13, 2012 at 10:11 PM, Rick Stockton <
> rickstockton at reno-computerhelp.com> wrote:
>
>> On Saturday 12 May 2012 18:36:42 Mark wrote:
>>
>> > / As for making a "HIG" keyboard standard list. A very good starting
>> > point is:
>> />/ http://en.wikipedia.org/wiki/Table_of_keyboard_shortcuts />/
>> />/ Every single line where the same key combination is used in both:
>> Windows,
>> />/ Mac, KDE en GNOME can be considered as de-facto standard key imho.
>> Though
>> />/ the list has to be viewed with care since the very first item
>> "Activate
>> />/ current application's Menu bar" is already wrong for KDE. It's not
>> just
>> />/ ALT. It's ALT + M iirc.
>>
>> 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://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.)
>>
>>
>> _______________________________________________
>> Kde-frameworks-devel mailing list
>> Kde-frameworks-devel at kde.org
>> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
>>
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20120516/e0a3636c/attachment.html>
More information about the Kde-frameworks-devel
mailing list