Issue 6656 in pharo: Move all shortcuts handling to Keymapping

Comment #40 on issue 6656 by [hidden email]: Move all shortcuts  
handling to Keymapping
http://code.google.com/p/pharo/issues/detail?id=6656

I tend to prefer :

- local shortcuts handled first

- global afterwards

Otherwise, quite many Pharo shortcuts would not work because they would be  
preempted by my desktop :)


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Comment #41 on issue 6656 by [hidden email]: Move all shortcuts  
handling to Keymapping
http://code.google.com/p/pharo/issues/detail?id=6656

Strange. Spec is building Morphs in the reverse order...

If I have a spec like that : add: A; add: B;

Then, when exploring the result at the morph level, I'll see B before A in  
the list of submorphs ?


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Comment #42 on issue 6656 by [hidden email]: Move all shortcuts  
handling to Keymapping
http://code.google.com/p/pharo/issues/detail?id=6656

Exemple implementation for Global shortcuts : Spotlight example.

Spotlight class>>buildKeymapsOn:
buildKeymapsOn: aBuilder
        <keymap>
       
        (aBuilder shortcut: #openSpotlight)
                category: #GlobalShortcuts
                default: Character cr shift
                do: [ :morph |
                        Current
                                ifNotNil: [ Current close. Current := nil ]
                                ifNil: [ (Current := self new) open ]].

PasteUpMorph>>initializeShortcuts
initializeShortcuts: aKMDispatcher
        "Where we may attach keymaps or even on:do: local shortcuts if needed."

        aKMDispatcher attachCategory: #GlobalShortcuts

A single keymap category, #GlobalShortcuts, where all global shortcuts can  
be added by applications (and maybe things like top level window  
navigation). And PasteUpMorph uses it.


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Updates:
        Cc: -[hidden email]

Comment #43 on issue 6656 by [hidden email]: Move all shortcuts  
handling to Keymapping
http://code.google.com/p/pharo/issues/detail?id=6656

It's not Spec, it's Morphic.

When you add a morph, by default it's added first. It kind of makes sense


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Comment #44 on issue 6656 by [hidden email]: Move all shortcuts  
handling to Keymapping
http://code.google.com/p/pharo/issues/detail?id=6656

Ok. For morphic it kind of make sense.

The consequence for navigation is that you navigate in reverse order from  
the one you use in the Spec, and that the morph with focus when you open is  
the last added in the Spec.

Example : Authentifier. Last morph is the Password field. It's the first  
selected when you open the Authentifier dialog, and you navigate in reverse  
from that. User expectations are the "Username" text field to have the  
focus.

I reversed the order of adds in my Spec application to get the right one  
with the focus at start.


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Comment #45 on issue 6656 by [hidden email]: Move all shortcuts  
handling to Keymapping
http://code.google.com/p/pharo/issues/detail?id=6656

In Spec there is a mechanism to specify the focus order
And beside that, it should not depend on how you have added them


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Comment #46 on issue 6656 by [hidden email]: Move all shortcuts  
handling to Keymapping
http://code.google.com/p/pharo/issues/detail?id=6656

I removed this focus mecanism in Spec.

It's a duplication of navigateFocusForward / navigateFocusBackward, and it  
didn't use Keymapping (it also had a few bugs, in that, in some morphs, the  
tab key would never reach the Spec layer). It's also not very well used  
(for example, Authentifier doesn't specify the focus order on all focus  
aware morphs. It's an easy mistake to make to forget a morph or two when  
you design the GUI).

By removing it and making sure navigateFocusF/B works, I reduced the number  
of lines of Spec apps and made it conform to GUI standards.

I left the ability to set the focus to a specific widget, since that code  
was not using focusOrder anyway.


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Comment #47 on issue 6656 by [hidden email]: Move all shortcuts  
handling to Keymapping
http://code.google.com/p/pharo/issues/detail?id=6656

This is wrong that the order of sub widgets in term of navigation depend on  
the way you have added them.

It's absolutely not a duplication since in navigateFocusForward you just  
can't explicitly define the target, nor locally change it when you are  
composing


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Comment #48 on issue 6656 by [hidden email]: Move all shortcuts  
handling to Keymapping
http://code.google.com/p/pharo/issues/detail?id=6656

For navigation, any way to set the order is fine; you just need one which  
includes all the keyboard focus able morphs in you GUI. You can add an  
additional order (as focusOrder tries to do) or just use the creation one  
(or reverse).

You can change a focus target in Morphic : #takeKeyboardFocus.


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Comment #49 on issue 6656 by [hidden email]: Move all shortcuts  
handling to Keymapping
http://code.google.com/p/pharo/issues/detail?id=6656

focusOrder done right would :
- record GUI implementor choices.
- reorder the morphs of the built window to ensure the partial order  
defined by the implementor is respected.

(yes, focusOrder is a partial order of Morphs under focus. A GUI requires a  
full ordering : i.e. all "interactive" Morphs must be reachable by keyboard  
navigation. Interestingly, Nautilus doesn't have that property: some of  
Nautilus Morphs cannot be reached by keyboard.)


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Comment #50 on issue 6656 by [hidden email]: Move all shortcuts  
handling to Keymapping
http://code.google.com/p/pharo/issues/detail?id=6656

@Guillermo

Two changes which order morphs for navigation in the Authentifier dialog  
box, as well as my application, in the order of addition to the spec, in  
the attached .cs :

(nice side effect: the #leftToRight/#rightToLeft in OkCancelToolbar spec  
really does what it says :))


Attachments:
        Spec-ReOrder-Morphs.cs  804 bytes


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Comment #51 on issue 6656 by [hidden email]: Move all shortcuts  
handling to Keymapping
http://code.google.com/p/pharo/issues/detail?id=6656

If you have to subclass+override to get the order, it's no longer  
composition ...


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Comment #52 on issue 6656 by [hidden email]: Move all shortcuts  
handling to Keymapping
http://code.google.com/p/pharo/issues/detail?id=6656

Thierry, I'll take your keymapping changes in here and open a new issue.  
Then spec and morphic can be handled in a separate way.


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Comment #53 on issue 6656 by [hidden email]: Move all shortcuts  
handling to Keymapping
http://code.google.com/p/pharo/issues/detail?id=6656

Ok. The removal of static targets in Keymapping broke some tests (of  
course) but rewritting those tests to use local targets didn't work. I  
couldn't find out why ?

I keep the rest of the changes merged with the latest Pharo 2.0.


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Updates:
        Status: Invalid

Comment #54 on issue 6656 by [hidden email]: Move all shortcuts  
handling to Keymapping
http://code.google.com/p/pharo/issues/detail?id=6656

This issue was already splitted into other 2/3 issues.


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Comment #55 on issue 6656 by [hidden email]: Move all shortcuts  
handling to Keymapping
http://code.google.com/p/pharo/issues/detail?id=6656

This issue was already splitted into other 2/3 issues.


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker