[Pharo-dev] shortcut settings (was: Re: Playground and text evaluation printing result default.)

Nicolai Hess nicolaihess at gmail.com
Wed Jun 8 18:09:13 EDT 2016


2016-06-08 22:15 GMT+02:00 Tudor Girba <tudor at tudorgirba.com>:

> Hi,
>
>
> > On Jun 8, 2016, at 7:35 PM, Nicolai Hess <nicolaihess at gmail.com> wrote:
> >
> >
> >
> > 2016-06-08 19:11 GMT+02:00 Tudor Girba <tudor at tudorgirba.com>:
> > Yes, we already agreed on that both for the debugger and for Spotter. We
> just did not get the chance to do it yet.
> >
> > Hey Doru,
> >
> > about your report
> > https://pharo.fogbugz.com/f/cases/18455 Spotter shortcuts should be
> externalized as settings
> >
> > Please don't do this just for spotter. We really need a general solution
> for all tools shortcuts.
>
> Hehe, I was about to raise another thread with this issue :)
>
>
> > I am alread about to clean up the shortcut definitions. In the tools and
> the PharoShortcuts class.
>
> I was thinking of using PharoShortcuts and providing settings for them.
>
>
> > But we still need a way to really define this in a customizable way.
> >
> > I already wrote about this and asked (ML or fogbugz, I don't remember).
> > The current shortcut definitions (with pragmas for example). Can be
> browsed and in the Keymap browser (that is good), but they can not be
> changed of course, they are defined in the source.
> > And, the current keymap definitions (KMKEyCombination) need a way to be
> able to read and write as a setting, that currently does not work (as I
> wrote).
> >
> > My proposition was, to define some kind of "Named-Keyaction" or
> "Named-Action", for example
> >
> > CopySelectionAction (name = CopySelection,  shortcut Ctrl+C), it would
> act as a KMKeyCombination, but its own shortcut (Ctrl+C) would be
> configurable.
> >
> > Now, in PharoShortcuts instead of
> >
> > PharoShortcuts >>#copySelectionShortcut
> >
> >     ^ $c meta
> >
> > we define
> >
> > PharoShortcuts >>#copySelectionShortcut
> >
> >     ^ CopySelectionAction withShortcut: $c meta
>
> I was thinking to have directly the setting
>
> PharoShortcuts >>#copySelectionShortcut
>         ^ self shortcutFor: #copySelection default: [ $c meta ]
>
> and in PharoShortcuts we have a dictionary out of which we can create
> settings.
>
> Would this not be enough?
>

I don't know. What would shortcutFor return ? Just a plain shortcut. If so,
changing this shortcut in the settings would only take an effect if (the
user or the settings browser) triggers a
KMRepository reset.
And only for keybdings defined by a keymap pragma. If a tools had
registered a direct keybinding on a Morph of an already opened tool, would
this be updated as well?



>
> Doru
>
>
> > (maybe on unique Instance of CopySelectionAction, or one per category)
> >
> > And the keymap browser, or the settings browser could list these actions
> and provide a way to reset the
> > keycombination:
> >
> > CopySelectionAction  -   | type some keycombination here |
> >
> >
> > The current way with the PharoShortcuts class and how the keys are
> binded to the tools don't really work for customizable shortcut definitions
> (or keymaps) or
> >
> > I just don't see it.
> >
> >
> > nicolai
> >
> >
> >
> >
> > Doru
> >
> >
> > > On Jun 8, 2016, at 11:33 AM, Esteban Lorenzano <estebanlm at gmail.com>
> wrote:
> > >
> > >
> > >> On 08 Jun 2016, at 09:04, stepharo <stepharo at free.fr> wrote:
> > >>
> > >>  the fact that I cannot access Spotter without hurting my hand it is
> also probably why I do not try more.
> > >
> > > yeah, shortcut has to be configurable, for people with big hands :)
> > >
> > >
> >
> > --
> > www.tudorgirba.com
> > www.feenk.com
> >
> > "Every now and then stop and ask yourself if the war you're fighting is
> the right one."
> >
> >
> >
> >
> >
> >
>
> --
> www.tudorgirba.com
> www.feenk.com
>
> "In a world where everything is moving ever faster,
> one might have better chances to win by moving slower."
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20160609/9d09bdaa/attachment-0002.html>


More information about the Pharo-dev mailing list