Well, some days ago I downloaded the KeyBindings from monticello in a Pharo 1.1 dev image.� It downloaded well allowing the _ as assignment.� But it didn't work :/.� Maybe I just missed something.

Thinking about adding nice and configurable shortcuts to Morphic and after reading some mails in this thread, I had some thoughts (I'm just thinking aloud):

1) Maybe a class variable in Morph to share the global shortcuts and an instance class variable to have specific shortcuts could do it.

2) Buuut, maybe there is a shortcut that is shared in a context bigger than a morph and smaller than "all the morphs".� And maybe that context is the model of the morph.� In that case I think it would be right to delegate the resolution of the shortcut to the model.

3) I've never used emacs :).� Does it have "chords" of shortcuts?� I call a chord pressing ((ctrl+A) + (ctrl +e)) to make one and only one action.� This should make us mantain the state of the pressed keys...� I don�t think this will be a performance issue, but we must have it in mind.

4) How should compound Morphs resolve a shortcut?� Should the shortcut flow to the parent morph or not? If so, when should it stop flowing :D?� I'm thinking in the System Browser, when the focus is on a paragraph editor but you want to do something with the selected class. Mmm, this is related to 2) :).

5) We should have a well ordered plan to introduce this kind of change.� We have to analize and remove every replaceable #keyStroke:.� And there should be a simple way to deploy the shortcuts for non-core packages :)

What do you think?� What I am missing?

I want to introduce shortcuts at any cost, je (even if lose sleep hours :) ).

Cheers,
Guille

On Sat, May 15, 2010 at 4:50 AM, St�phane Ducasse <stephane.ducasse@inria.fr> wrote:


>
> I've got all three running in Squeak 4.1 trunk. �Loading in Pharo will be
> more complicated due to missing dependencies - maybe not worth it. �It might
> be better to catalogue how they work and come up with something simple and
> flexible from scratch?
>
> There is a solution brewing in my head that generalizes key bindings to a
> condition and action. �So, instead of being restricted to 'when shift and c
> are pressed' you could say 'when shift and c are pressed and a Workspace is
> the active morph'

If I remember (was 8 years ago) the mapping table is shared globally by all paragraphEditor
and what you want is that potentially each morph can have its own table.
So I would not attach context to a binding. But more the table been attached to a morph
would be active. But I do not have a definitive answer.

Now a trick used by the VW parser to have sharing and instance specific table is the following
The trick to get something cool is to have both a class var and an instance var that represent
a table: the method only access the table via inst var, at class initialize the classVar is initialized
then at instance creation the inst var points to the class var.

=> sharing of the class Var
but now on a specific instance you can copy the table and set up to a give object and
it will be used by the object. while others will share the global table.

Workspace class could simply have its own specific table for all instances
Roel Wuyts designed the magic shortcut in VW it worked quite well so I think that it would be worth to have a look
at them. They got integrated in the VW release.

Stef


>
> The only thing that seems like it will be complicated is vi bindings (don't
> know enough to say about emacs). �For instance, I can't see how normal mode
> could be implemented without changing some existing classes (for example,
> the cursor must change).
>
> Sean
> --
> View this message in context: http://forum.world.st/Keyboard-Shortcuts-in-Pharo-tp1298784p2217472.html
> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project