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 <[email protected] > 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 > > [email protected] > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >
_______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
