August 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] ifTrue ifFalse shortcuts

by Denis Kudriashov

2016-08-03 10:27 GMT+02:00 Guille Polito <guillermopolito(a)gmail.com>: > I'm also against. > > - They take a place in the shortcuts that prevents others to use it > - If lazy people really needs this, the code completion should be > enhanced. This is a code completion concern... > +1

Aug. 3, 2016

Re: [Pharo-dev] ifTrue ifFalse shortcuts

by Guille Polito

I'm also against. - They take a place in the shortcuts that prevents others to use it - If lazy people really needs this, the code completion should be enhanced. This is a code completion concern... In general, my rule of thumb is to answer the following questions: How many people use it? - if a lot, maybe it makes sense to integrate it - if not a lot, make it a loadable extension How often do people use it? - if at least 10 times per hour (e.g., reformat code, senders, implementors, search) the shortcut should be simple - otherwise we can put it in a more complex combination to leave place to the common ones. Guille -------- Original Message -------- > From a software design perspective it shouldn't be easy to insert > #ifTrue:ifFalse :) > > Norbert > >> Am 03.08.2016 um 10:15 schrieb Nicolai Hess <nicolaihess(a)gmail.com >> <mailto:nicolaihess@gmail.com>>: >> >> Any objections on using >> cmd+t / cmd+f for insert ifTrue/ifFalse >> (linux/windows this would be alt+t/alt+f, mac this would be cmd+t/cmd+f). >> >> 2015-08-12 18:52 GMT+02:00 stepharo <stepharo(a)free.fr >> <mailto:stepharo@free.fr>>: >> >> >> >> >> >> >> >> >> >> >> Le 11/8/15 10:25, Nicolai Hess a >> Ã©crit : >> >> >>> >>> >>> >>> >>> >>> I am nearly finished with converting old shortcut >>> mapping (Editor/TextEditor cmdActions/shiftCmdAction >>> map) >>> >>> >>> to our keymapping framework. >>> >>> >>> >>> >>> 15619 <https://pharo.fogbugz.com/default.asp?15619> >>> >>> >>> cleanup TextEditors shortcut >>> definition >>> >>> >>> >>> >>> >>> >> >> >> >> Thank a lot! >> >> >> >> Yesterday with guillermo and christophe we spent one full afternoon >> reading all the recursive dependencies introduced >> >> when we just want to have monticello in the bootstrap (to be able to >> load code). >> >> We filled up two black boards and I should say that I was a nice >> down to see the complexity but we will fix it :). >> >> >> >> Yesterday Esteban sat with igor and started to integrate the >> OSWindow integration work of igor (yes igor you should do pull >> requests :). >> >> So there are some problems with the mac vm and this will have to be >> fixed (probably next week). >> >> After I hope that we will get clean events from SDL >> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> I need some more time, one or two vm changes and some people >>> testing this on a mac. >>> >>> >>> >>> >> >> >> >> Tell us we will :) >> >> >> >>> >>> >>> >>> >>> >>> >>> I know, this is a bit late because we replace our text >>> components with rubric, but if this >>> >>> >>> is finished and working for "old" PluggableTextMorphs, I will do >>> the same for rubric. >>> >>> >> >> Thanks thanks thanks. >> >> I often frustrated when I see myself doing things more than twice >> but this is a pattern. I decided long time ago that >> >> if this is necessary to do intermediate actions to lower the stress >> on the future actions, I'm ready to throw awy what >> >> I did to get the ultimate goal reached. >> >> >> >> >> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> 2015-08-08 14:57 GMT+02:00 >>> Esteban Lorenzano <estebanlm(a)gmail.com >>> <mailto:estebanlm@gmail.com>>: >>> >>> >>> if reintroduce >>> them means reintroduce them hardcoded as >>> before, then Iâm complete against it and I >>> WILL NOT integrate such solution. >>> Iâm sorry for being so strong here, but >>> previous implementation was lame and we need >>> to get rid of them. >>> >>> >>> >>> >>> Now, I understand people are used to use >>> those bindings and also some others (no idea >>> which ones because I never used themâ¦ for me >>> ocompletion is good enoughâ¦ but those are >>> tastes). So I would be very happy to >>> integrate a generic way to define >>> keybindings and outputs (which is already >>> there, with keymapping, but I mean an editor >>> or something), and I would be very happy to >>> integrate a default configuration (which of >>> course, will include #ifTrue:/##ifFalse:) >>> >>> >>> >>> >>> >>> Esteban >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>>> >>>> On 08 Aug 2015, at 12:45, >>>> Peter UhnÃ¡k <i.uhnak(a)gmail.com <mailto:i.uhnak@gmail.com>> >>>> >>>> wrote: >>>> >>>> >>>> >>>> >>>> I would also >>>> appreciate if it was readded, >>>> as I've been using it >>>> regularly. >>>> >>>> >>>> >>>> Peter >>>> >>>> >>>> >>>> >>>> On >>>> Sat, Aug 8, 2015 at 12:21 >>>> PM, ThomasHeniart <heniart.thomas(a)gmail.com >>>> <mailto:heniart.thomas@gmail.com>> >>>> wrote: >>>> >>>> >>>> I think >>>> it could be nice to keep >>>> this shortcut :) >>>> >>>> >>>> >>>> >>>> >>>> On 08/08/2015 >>>> 12:12, Franck >>>> Warlouzet wrote: >>>> >>>> >>>>> >>>>> Hi, >>>>> >>>>> >>>>> >>>>> Yes it was not >>>>> on purpose. It >>>>> is not >>>>> implemented in >>>>> Rubric, but I >>>>> can do it if >>>>> there is a need >>>>> of it (which >>>>> seems to be the >>>>> case). >>>>> >>>>> >>>>> >>>>> Franck >>>>> >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------------ >>>>> Date: Sat, >>>>> 8 Aug 2015 >>>>> 12:09:22 +0200 >>>>> >>>>> From: i.uhnak(a)gmail.com <mailto:i.uhnak@gmail.com> >>>>> >>>>> To: pharo-dev(a)lists.pharo.org >>>>> <mailto:pharo-dev@lists.pharo.org> >>>>> >>>>> Subject: >>>>> [Pharo-dev] >>>>> ifTrue ifFalse >>>>> shortcuts >>>>> >>>>> >>>>> >>>>> Hi, >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> was >>>>> removal of >>>>> ifTrue/ifFalse >>>>> shortcuts on >>>>> purpose, or by >>>>> accident? >>>>> >>>>> https://pharo.fogbugz.com/f/cases/16125/Nautilus-doesn-t-recognize-the-cmd-… >>>>> >>>>> >>>>> (maybe >>>>> was caused by >>>>> switch to >>>>> Rubric?) >>>>> >>>>> >>>>> >>>>> >>>>> Peter >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >> >> >> >> >> >> >> > > > >

Aug. 3, 2016

Re: [Pharo-dev] ifTrue ifFalse shortcuts

by Nicolai Hess

2016-08-03 10:21 GMT+02:00 Norbert Hartl <norbert(a)hartl.name>: > From a software design perspective it shouldn't be easy to insert > #ifTrue:ifFalse :) > :-) > > Norbert > > Am 03.08.2016 um 10:15 schrieb Nicolai Hess <nicolaihess(a)gmail.com>: > > Any objections on using > cmd+t / cmd+f for insert ifTrue/ifFalse > (linux/windows this would be alt+t/alt+f, mac this would be cmd+t/cmd+f). > > 2015-08-12 18:52 GMT+02:00 stepharo <stepharo(a)free.fr>: > >> >> >> Le 11/8/15 10:25, Nicolai Hess a Ã©crit : >> >> I am nearly finished with converting old shortcut mapping >> (Editor/TextEditor cmdActions/shiftCmdAction map) >> to our keymapping framework. >> >> 15619 <https://pharo.fogbugz.com/default.asp?15619> >> cleanup TextEditors shortcut definition >> >> >> Thank a lot! >> >> Yesterday with guillermo and christophe we spent one full afternoon >> reading all the recursive dependencies introduced >> when we just want to have monticello in the bootstrap (to be able to load >> code). >> We filled up two black boards and I should say that I was a nice down to >> see the complexity but we will fix it :). >> >> Yesterday Esteban sat with igor and started to integrate the OSWindow >> integration work of igor (yes igor you should do pull requests :). >> So there are some problems with the mac vm and this will have to be fixed >> (probably next week). >> After I hope that we will get clean events from SDL >> >> >> I need some more time, one or two vm changes and some people testing this >> on a mac. >> >> >> Tell us we will :) >> >> >> I know, this is a bit late because we replace our text components with >> rubric, but if this >> is finished and working for "old" PluggableTextMorphs, I will do the same >> for rubric. >> >> Thanks thanks thanks. >> I often frustrated when I see myself doing things more than twice but >> this is a pattern. I decided long time ago that >> if this is necessary to do intermediate actions to lower the stress on >> the future actions, I'm ready to throw awy what >> I did to get the ultimate goal reached. >> >> >> >> >> >> 2015-08-08 14:57 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: >> >>> if reintroduce them means reintroduce them hardcoded as before, then Iâm >>> complete against it and I WILL NOT integrate such solution. >>> Iâm sorry for being so strong here, but previous implementation was lame >>> and we need to get rid of them. >>> >>> Now, I understand people are used to use those bindings and also some >>> others (no idea which ones because I never used themâ¦ for me ocompletion is >>> good enoughâ¦ but those are tastes). So I would be very happy to integrate a >>> generic way to define keybindings and outputs (which is already there, with >>> keymapping, but I mean an editor or something), and I would be very happy >>> to integrate a default configuration (which of course, will include >>> #ifTrue:/##ifFalse:) >>> >>> Esteban >>> >>> >>> >>> On 08 Aug 2015, at 12:45, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >>> >>> I would also appreciate if it was readded, as I've been using it >>> regularly. >>> >>> Peter >>> >>> On Sat, Aug 8, 2015 at 12:21 PM, ThomasHeniart <heniart.thomas(a)gmail.com >>> > wrote: >>> >>>> I think it could be nice to keep this shortcut :) >>>> >>>> >>>> On 08/08/2015 12:12, Franck Warlouzet wrote: >>>> >>>> Hi, >>>> >>>> Yes it was not on purpose. It is not implemented in Rubric, but I can >>>> do it if there is a need of it (which seems to be the case). >>>> >>>> Franck >>>> >>>> ------------------------------ >>>> Date: Sat, 8 Aug 2015 12:09:22 +0200 >>>> From: i.uhnak(a)gmail.com >>>> To: pharo-dev(a)lists.pharo.org >>>> Subject: [Pharo-dev] ifTrue ifFalse shortcuts >>>> >>>> Hi, >>>> >>>> was removal of ifTrue/ifFalse shortcuts on purpose, or by accident? >>>> >>>> https://pharo.fogbugz.com/f/cases/16125/Nautilus-doesn-t-recognize-the-cmd-… >>>> (maybe was caused by switch to Rubric?) >>>> >>>> Peter >>>> >>>> >>>> >>> >>> >> >> > >

Aug. 3, 2016

Re: [Pharo-dev] ifTrue ifFalse shortcuts

by Nicolai Hess

2016-08-03 10:19 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > Hi, > > Yes. Both of those commands are in use: > - Cmd+t = suggestions > - Cmd+f = search > Ah ok, (on mac only, as on windows/linux suggesstions uses meta+t which is mapped to ctrl+t). cmd+shift+t cmd+shift+f ? > > I think these types of inserts should not have simple bindings because we > are asking for trouble. > > cheers, > Doru > > > > On Aug 3, 2016, at 10:15 AM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > Any objections on using > > cmd+t / cmd+f for insert ifTrue/ifFalse > > (linux/windows this would be alt+t/alt+f, mac this would be cmd+t/cmd+f). > > > > 2015-08-12 18:52 GMT+02:00 stepharo <stepharo(a)free.fr>: > > > > > > Le 11/8/15 10:25, Nicolai Hess a Ã©crit : > >> I am nearly finished with converting old shortcut mapping > (Editor/TextEditor cmdActions/shiftCmdAction map) > >> to our keymapping framework. > >> > >> 15619 > >> cleanup TextEditors shortcut definition > > > > Thank a lot! > > > > Yesterday with guillermo and christophe we spent one full afternoon > reading all the recursive dependencies introduced > > when we just want to have monticello in the bootstrap (to be able to > load code). > > We filled up two black boards and I should say that I was a nice down to > see the complexity but we will fix it :). > > > > Yesterday Esteban sat with igor and started to integrate the OSWindow > integration work of igor (yes igor you should do pull requests :). > > So there are some problems with the mac vm and this will have to be > fixed (probably next week). > > After I hope that we will get clean events from SDL > >> > >> I need some more time, one or two vm changes and some people testing > this on a mac. > > > > Tell us we will :) > > > >> > >> I know, this is a bit late because we replace our text components with > rubric, but if this > >> is finished and working for "old" PluggableTextMorphs, I will do the > same for rubric. > > Thanks thanks thanks. > > I often frustrated when I see myself doing things more than twice but > this is a pattern. I decided long time ago that > > if this is necessary to do intermediate actions to lower the stress on > the future actions, I'm ready to throw awy what > > I did to get the ultimate goal reached. > > > > > >> > >> > >> > >> 2015-08-08 14:57 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > >> if reintroduce them means reintroduce them hardcoded as before, then > Iâm complete against it and I WILL NOT integrate such solution. > >> Iâm sorry for being so strong here, but previous implementation was > lame and we need to get rid of them. > >> > >> Now, I understand people are used to use those bindings and also some > others (no idea which ones because I never used themâ¦ for me ocompletion is > good enoughâ¦ but those are tastes). So I would be very happy to integrate a > generic way to define keybindings and outputs (which is already there, with > keymapping, but I mean an editor or something), and I would be very happy > to integrate a default configuration (which of course, will include > #ifTrue:/##ifFalse:) > >> > >> Esteban > >> > >> > >> > >>> On 08 Aug 2015, at 12:45, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > >>> > >>> I would also appreciate if it was readded, as I've been using it > regularly. > >>> > >>> Peter > >>> > >>> On Sat, Aug 8, 2015 at 12:21 PM, ThomasHeniart < > heniart.thomas(a)gmail.com> wrote: > >>> I think it could be nice to keep this shortcut :) > >>> > >>> > >>> On 08/08/2015 12:12, Franck Warlouzet wrote: > >>>> Hi, > >>>> > >>>> Yes it was not on purpose. It is not implemented in Rubric, but I can > do it if there is a need of it (which seems to be the case). > >>>> > >>>> Franck > >>>> > >>>> Date: Sat, 8 Aug 2015 12:09:22 +0200 > >>>> From: i.uhnak(a)gmail.com > >>>> To: pharo-dev(a)lists.pharo.org > >>>> Subject: [Pharo-dev] ifTrue ifFalse shortcuts > >>>> > >>>> Hi, > >>>> > >>>> was removal of ifTrue/ifFalse shortcuts on purpose, or by accident? > >>>> > https://pharo.fogbugz.com/f/cases/16125/Nautilus-doesn-t-recognize-the-cmd-… > >>>> (maybe was caused by switch to Rubric?) > >>>> > >>>> Peter > >>> > >>> > >> > >> > > > > > > -- > www.tudorgirba.com > www.feenk.com > > "Innovation comes in the least expected form. > That is, if it is expected, it already happened." > > >

Aug. 3, 2016

Re: [Pharo-dev] ifTrue ifFalse shortcuts

by Norbert Hartl

>From a software design perspective it shouldn't be easy to insert #ifTrue:ifFalse :) Norbert > Am 03.08.2016 um 10:15 schrieb Nicolai Hess <nicolaihess(a)gmail.com>: > > Any objections on using > cmd+t / cmd+f for insert ifTrue/ifFalse > (linux/windows this would be alt+t/alt+f, mac this would be cmd+t/cmd+f). > > 2015-08-12 18:52 GMT+02:00 stepharo <stepharo(a)free.fr <mailto:stepharo@free.fr>>: > > > Le 11/8/15 10:25, Nicolai Hess a Ã©crit : >> I am nearly finished with converting old shortcut mapping (Editor/TextEditor cmdActions/shiftCmdAction map) >> to our keymapping framework. >> >> 15619 <https://pharo.fogbugz.com/default.asp?15619> >> cleanup TextEditors shortcut definition > > Thank a lot! > > Yesterday with guillermo and christophe we spent one full afternoon reading all the recursive dependencies introduced > when we just want to have monticello in the bootstrap (to be able to load code). > We filled up two black boards and I should say that I was a nice down to see the complexity but we will fix it :). > > Yesterday Esteban sat with igor and started to integrate the OSWindow integration work of igor (yes igor you should do pull requests :). > So there are some problems with the mac vm and this will have to be fixed (probably next week). > After I hope that we will get clean events from SDL >> >> I need some more time, one or two vm changes and some people testing this on a mac. > > Tell us we will :) > >> >> I know, this is a bit late because we replace our text components with rubric, but if this >> is finished and working for "old" PluggableTextMorphs, I will do the same for rubric. > Thanks thanks thanks. > I often frustrated when I see myself doing things more than twice but this is a pattern. I decided long time ago that > if this is necessary to do intermediate actions to lower the stress on the future actions, I'm ready to throw awy what > I did to get the ultimate goal reached. > > >> >> >> >> 2015-08-08 14:57 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>>: >> if reintroduce them means reintroduce them hardcoded as before, then Iâm complete against it and I WILL NOT integrate such solution. >> Iâm sorry for being so strong here, but previous implementation was lame and we need to get rid of them. >> >> Now, I understand people are used to use those bindings and also some others (no idea which ones because I never used themâ¦ for me ocompletion is good enoughâ¦ but those are tastes). So I would be very happy to integrate a generic way to define keybindings and outputs (which is already there, with keymapping, but I mean an editor or something), and I would be very happy to integrate a default configuration (which of course, will include #ifTrue:/##ifFalse:) >> >> Esteban >> >> >> >>> On 08 Aug 2015, at 12:45, Peter UhnÃ¡k <i.uhnak(a)gmail.com <mailto:i.uhnak@gmail.com>> wrote: >>> >>> I would also appreciate if it was readded, as I've been using it regularly. >>> >>> Peter >>> >>> On Sat, Aug 8, 2015 at 12:21 PM, ThomasHeniart <heniart.thomas(a)gmail.com <mailto:heniart.thomas@gmail.com>> wrote: >>> I think it could be nice to keep this shortcut :) >>> >>> >>> On 08/08/2015 12:12, Franck Warlouzet wrote: >>>> Hi, >>>> >>>> Yes it was not on purpose. It is not implemented in Rubric, but I can do it if there is a need of it (which seems to be the case). >>>> >>>> Franck >>>> >>>> Date: Sat, 8 Aug 2015 12:09:22 +0200 >>>> From: i.uhnak(a)gmail.com <mailto:i.uhnak@gmail.com> >>>> To: pharo-dev(a)lists.pharo.org <mailto:pharo-dev@lists.pharo.org> >>>> Subject: [Pharo-dev] ifTrue ifFalse shortcuts >>>> >>>> Hi, >>>> >>>> was removal of ifTrue/ifFalse shortcuts on purpose, or by accident? >>>> https://pharo.fogbugz.com/f/cases/16125/Nautilus-doesn-t-recognize-the-cmd-… <https://pharo.fogbugz.com/f/cases/16125/Nautilus-doesn-t-recognize-the-cmd-…> >>>> (maybe was caused by switch to Rubric?) >>>> >>>> Peter >>> >>> >> >> > >

Aug. 3, 2016

Re: [Pharo-dev] ifTrue ifFalse shortcuts

by Tudor Girba

Hi, Yes. Both of those commands are in use: - Cmd+t = suggestions - Cmd+f = search I think these types of inserts should not have simple bindings because we are asking for trouble. cheers, Doru > On Aug 3, 2016, at 10:15 AM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > Any objections on using > cmd+t / cmd+f for insert ifTrue/ifFalse > (linux/windows this would be alt+t/alt+f, mac this would be cmd+t/cmd+f). > > 2015-08-12 18:52 GMT+02:00 stepharo <stepharo(a)free.fr>: > > > Le 11/8/15 10:25, Nicolai Hess a Ã©crit : >> I am nearly finished with converting old shortcut mapping (Editor/TextEditor cmdActions/shiftCmdAction map) >> to our keymapping framework. >> >> 15619 >> cleanup TextEditors shortcut definition > > Thank a lot! > > Yesterday with guillermo and christophe we spent one full afternoon reading all the recursive dependencies introduced > when we just want to have monticello in the bootstrap (to be able to load code). > We filled up two black boards and I should say that I was a nice down to see the complexity but we will fix it :). > > Yesterday Esteban sat with igor and started to integrate the OSWindow integration work of igor (yes igor you should do pull requests :). > So there are some problems with the mac vm and this will have to be fixed (probably next week). > After I hope that we will get clean events from SDL >> >> I need some more time, one or two vm changes and some people testing this on a mac. > > Tell us we will :) > >> >> I know, this is a bit late because we replace our text components with rubric, but if this >> is finished and working for "old" PluggableTextMorphs, I will do the same for rubric. > Thanks thanks thanks. > I often frustrated when I see myself doing things more than twice but this is a pattern. I decided long time ago that > if this is necessary to do intermediate actions to lower the stress on the future actions, I'm ready to throw awy what > I did to get the ultimate goal reached. > > >> >> >> >> 2015-08-08 14:57 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: >> if reintroduce them means reintroduce them hardcoded as before, then Iâm complete against it and I WILL NOT integrate such solution. >> Iâm sorry for being so strong here, but previous implementation was lame and we need to get rid of them. >> >> Now, I understand people are used to use those bindings and also some others (no idea which ones because I never used themâ¦ for me ocompletion is good enoughâ¦ but those are tastes). So I would be very happy to integrate a generic way to define keybindings and outputs (which is already there, with keymapping, but I mean an editor or something), and I would be very happy to integrate a default configuration (which of course, will include #ifTrue:/##ifFalse:) >> >> Esteban >> >> >> >>> On 08 Aug 2015, at 12:45, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >>> >>> I would also appreciate if it was readded, as I've been using it regularly. >>> >>> Peter >>> >>> On Sat, Aug 8, 2015 at 12:21 PM, ThomasHeniart <heniart.thomas(a)gmail.com> wrote: >>> I think it could be nice to keep this shortcut :) >>> >>> >>> On 08/08/2015 12:12, Franck Warlouzet wrote: >>>> Hi, >>>> >>>> Yes it was not on purpose. It is not implemented in Rubric, but I can do it if there is a need of it (which seems to be the case). >>>> >>>> Franck >>>> >>>> Date: Sat, 8 Aug 2015 12:09:22 +0200 >>>> From: i.uhnak(a)gmail.com >>>> To: pharo-dev(a)lists.pharo.org >>>> Subject: [Pharo-dev] ifTrue ifFalse shortcuts >>>> >>>> Hi, >>>> >>>> was removal of ifTrue/ifFalse shortcuts on purpose, or by accident? >>>> https://pharo.fogbugz.com/f/cases/16125/Nautilus-doesn-t-recognize-the-cmd-… >>>> (maybe was caused by switch to Rubric?) >>>> >>>> Peter >>> >>> >> >> > > -- www.tudorgirba.com www.feenk.com "Innovation comes in the least expected form. That is, if it is expected, it already happened."

Aug. 3, 2016

Re: [Pharo-dev] ifTrue ifFalse shortcuts

by Nicolai Hess

Any objections on using cmd+t / cmd+f for insert ifTrue/ifFalse (linux/windows this would be alt+t/alt+f, mac this would be cmd+t/cmd+f). 2015-08-12 18:52 GMT+02:00 stepharo <stepharo(a)free.fr>: > > > Le 11/8/15 10:25, Nicolai Hess a Ã©crit : > > I am nearly finished with converting old shortcut mapping > (Editor/TextEditor cmdActions/shiftCmdAction map) > to our keymapping framework. > > 15619 <https://pharo.fogbugz.com/default.asp?15619> > cleanup TextEditors shortcut definition > > > Thank a lot! > > Yesterday with guillermo and christophe we spent one full afternoon > reading all the recursive dependencies introduced > when we just want to have monticello in the bootstrap (to be able to load > code). > We filled up two black boards and I should say that I was a nice down to > see the complexity but we will fix it :). > > Yesterday Esteban sat with igor and started to integrate the OSWindow > integration work of igor (yes igor you should do pull requests :). > So there are some problems with the mac vm and this will have to be fixed > (probably next week). > After I hope that we will get clean events from SDL > > > I need some more time, one or two vm changes and some people testing this > on a mac. > > > Tell us we will :) > > > I know, this is a bit late because we replace our text components with > rubric, but if this > is finished and working for "old" PluggableTextMorphs, I will do the same > for rubric. > > Thanks thanks thanks. > I often frustrated when I see myself doing things more than twice but this > is a pattern. I decided long time ago that > if this is necessary to do intermediate actions to lower the stress on the > future actions, I'm ready to throw awy what > I did to get the ultimate goal reached. > > > > > > 2015-08-08 14:57 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > >> if reintroduce them means reintroduce them hardcoded as before, then Iâm >> complete against it and I WILL NOT integrate such solution. >> Iâm sorry for being so strong here, but previous implementation was lame >> and we need to get rid of them. >> >> Now, I understand people are used to use those bindings and also some >> others (no idea which ones because I never used themâ¦ for me ocompletion is >> good enoughâ¦ but those are tastes). So I would be very happy to integrate a >> generic way to define keybindings and outputs (which is already there, with >> keymapping, but I mean an editor or something), and I would be very happy >> to integrate a default configuration (which of course, will include >> #ifTrue:/##ifFalse:) >> >> Esteban >> >> >> >> On 08 Aug 2015, at 12:45, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >> >> I would also appreciate if it was readded, as I've been using it >> regularly. >> >> Peter >> >> On Sat, Aug 8, 2015 at 12:21 PM, ThomasHeniart <heniart.thomas(a)gmail.com> >> wrote: >> >>> I think it could be nice to keep this shortcut :) >>> >>> >>> On 08/08/2015 12:12, Franck Warlouzet wrote: >>> >>> Hi, >>> >>> Yes it was not on purpose. It is not implemented in Rubric, but I can do >>> it if there is a need of it (which seems to be the case). >>> >>> Franck >>> >>> ------------------------------ >>> Date: Sat, 8 Aug 2015 12:09:22 +0200 >>> From: i.uhnak(a)gmail.com >>> To: pharo-dev(a)lists.pharo.org >>> Subject: [Pharo-dev] ifTrue ifFalse shortcuts >>> >>> Hi, >>> >>> was removal of ifTrue/ifFalse shortcuts on purpose, or by accident? >>> >>> https://pharo.fogbugz.com/f/cases/16125/Nautilus-doesn-t-recognize-the-cmd-… >>> (maybe was caused by switch to Rubric?) >>> >>> Peter >>> >>> >>> >> >> > >

Aug. 3, 2016

Re: [Pharo-dev] GT-Spotter dive in shortcut

by Tudor Girba

Hi, > On Aug 3, 2016, at 9:16 AM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > 2016-06-18 23:34 GMT+02:00 Nicolai Hess <nicolaihess(a)gmail.com>: > > > 2016-06-18 20:55 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > Hi, > > Command is an actual key on Mac next to Option(which is Alt) and Control. So, Command is a concrete key and mapping it logically to another key on another platform is mixing semantics. > > I propose to have two distinct layers in the image: > 1. the raw layer is about having a distinct selector for each concrete key that is found on the keyboard. Right now, it seems to me that the VM does a bit of interpretation and mapping, and if it does, I think it should just provide a distinct code for each distinct key. > 2. the portable layer is about having a couple of selectors (e.g., #meta, #secondaryMeta) that provide consistent mappings to the raw keys. > > So, in this way, #command/#control/#alt would belong to layer 1. and #meta/#secondaryMeta (we could find a better name) would belong to layer 2. > > Does this make sense? > > > So, what does that mean for the text navigation mapping in Rubric. Which shortcut should I use? > > Any way to take a decision? > > I don't really want to wait until we implement a new layer. Thanks for the ping. I think that you cannot use now properly a uniform shortcut if we do not introduce these âlayersâ. I also think that we are talking about a couple of methods, so the effort is only in making the decision. I think that given that nobody disagreed, we can go ahead with it. For the specific question related to text navigation in Rubric, you could use #meta. What do you think? Doru > > Cheers, > Doru > > > > On Jun 18, 2016, at 8:42 PM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > > > > > 2016-06-17 18:25 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > > Hi Nicolai, > > > > > On Jun 17, 2016, at 2:59 PM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > > > > > > > > > 2016-06-17 14:35 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > > > Hi Nicolai, > > > > > > I am a bit removed from the code details at the moment, and I think I need to step back a bit :). > > > > > > If I understand correctly, you are saying that: > > > 1. defining bindings with #alt does not work on Windows. This means that we should fix this one. Using Cmd should not be a solution here. > > > > > > As far as I know, this is on purpose. A key pressed with windows (left) alt modified is mapped to "command" > > > > > > from vm source: > > > > > > * 3) The modifier keys are mapped as follows: > > > * > > > * Mac | Win32 > > > * -------------------- > > > * Shift -> Shift > > > * Ctrl -> Ctrl > > > * Command -> Left ALT > > > * Option -> Right ALT > > > > > > (but actually, the right ALT key does not generate any keystrokes (only key down/up) and it is treated as ctrl+alt (windows right Alt key is "Alt Grâ) > > > > Hmm. I think we have to rethink this one because we need two layers of keys: > > 1. first we should have the raw ones, and > > > > what are the "raw" ones? The events the OS generates or the events the VM send out to the image? > > > > 2. another layer that offers a more logical keys (like meta). > > > > Can you explain this a bit more. > > > > > > What do you think? > > > > > > > 2. defining the > > > bindings for Spotter can indeed be made to override the ones in the text editor if needed. But, I think we can start thinking about using #alt. > > > > > > using alt+right on windows/linux and > > > command + right on mac > > > for dive-in or for text navigation? > > > > > > Is there a default keycombination for word-moving in text components for mac ? > > > > On Mac, typically Alt+Right/Left moves between words. > > > > So, we would need a logical modifier that would mean: > > - Mac: Alt > > - Win: Ctrl > > - Linux: Ctrl > > > > I though this is what Guillermo already did, but with "command" > > > > - Mac: Command > > - Win/Linux: Ctrl > > > > Why did we choose Command and not Alt in the first place, why is Alt now better? > > > > > > > > What do you think? > > > > Cheers, > > Doru > > > > > > > > > > Does this make sense? > > > > > > Cheers, > > > Doru > > > > > > > > > > On Jun 17, 2016, at 12:12 AM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > > > > > > > > > > > > > 2016-06-16 22:45 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > > > > Hi, > > > > > > > > I think we are mixing the topics a bit. The #meta discussion is not specific to Spotter actions. > > > > > > > > On windows, it is. Because on windows #meta is mapped to #ctrl, and you can use ctrl+left/right for moving by "words". This works in a browser, an editor, pharos text components but *not* in spotter > > > > because spotter redefines this keystrokes for dive in /out. > > > > Currently, both ctrl+left/right and alt+left/right (and shift for selection) are working in rubric for moving by "word". But only because the (old) shortcut (cmd/shiftcmd) action dispatcher > > > > explicitly allows both. If we want to remove this and use the KMDispatcher framework only, we *need* to define only one mapping, otherwise you won't be able to use dive in/out in spotter. > > > > (Or you could modify spotter to register(overwrite) the mapping on the textfield instead of the spotter morph). > > > > > > > > > > > > The idea was to offer a uniform support of keybindings in Pharo, in general. > > > > > > > > exactly, and using ctrl+left/right uniformly in editor and external tools would be great. > > > > > > > > Then Guille etal added #meta to have a predictable mapping. > > > > > > > > Yes, and to make this work, we have to remove the old keymapping implementation (cmd/shiftcmd action map) and use the KMDispatcher registration. But I can only continue with this > > > > if we have a decision what to use, (windows/linux: either ctrl+arrow or alt+arrow, mac: whatever is used on a mac for text navigation) > > > > > > > > All #cmd places were changed to #meta, and since then we should not use explicitly #cmd anymore, except when we know we are on Mac. For a portable modifier, we should only use #meta. > > > > > > > > At this point, both Rubric and Spotter use #meta. #meta maps on: > > > > - Mac: Command > > > > - Win: Control > > > > - Linus: Control > > > > > > > > This means that #alt is now a portable modifier that will not conflict with #meta, so we can now think of using that one in combination with #meta. > > > > > > > > You can not use #alt modifier on windows. A shortcut definition like > > > > $g alt > > > > is never recognized. You have to define it > > > > $g command > > > > to make it work with as "alt+g"-keycombination (on windows). > > > > > > > > > > > > > > > > For text navigation, the situation is a bit complicated. On Win/Linux, Ctrl+Right/Left moves the cursor between words. On Mac, Cmd+Right/Left moves the cursor at the end/beginning of line. So, using #meta for text navigation between words is not entirely accurate. We should use #ctrl instead. > > > > > > > > This would anyway mean that it would be an option to use #alt for Spotter now. But, if we are at it, would anyone be interested in working on revisiting the overall keybindings in Pharo? > > > > > > > > Cheers, > > > > Doru > > > > > > > > > > > > > > > > > On Jun 16, 2016, at 10:22 AM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > > > > > > > > > > > > > > > > > 2016-06-07 16:12 GMT+02:00 Andrei Chis <chisvasileandrei(a)gmail.com>: > > > > > We can, but I remember there were some discussions and it was decided to use meta everywhere. > > > > > > > > > > Cheers, > > > > > Andrei > > > > > > > > > > > > > > > If we don't change this, I'll use cmd+left cmd+right in rubric, but this is bad, because all other navigate/select+navigate shortcuts would use meta as shortcut modifier. > > > > > > > > > > What are the arguments for using meta for dive-in/out shortcuts ? > > > > > > > > > > > > > > > > > > > > On Tue, Jun 7, 2016 at 3:49 PM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > > > > > > > > > > > > 2016-06-07 15:08 GMT+02:00 Andrei Chis <chisvasileandrei(a)gmail.com>: > > > > > During Pharo 5 most shortcuts from tools were changed to use "meta" instead of cmd. > > > > > > > > > > Cheers, > > > > > Andrei > > > > > > > > > > Can we change this for spotter ? cmd instead of meta > > > > > > > > > > ctrl left/right is often used for text components to move to next/previous word. > > > > > > > > > > > > > > > > > > > > On Tue, Jun 7, 2016 at 2:18 PM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > > > > > > > > > > > > 2016-06-07 13:57 GMT+02:00 Nicolai Hess <nicolaihess(a)gmail.com>: > > > > > > > > > > Am 07.06.2016 1:56 nachm. schrieb "Henrik Nergaard" <henrik.nergaard(a)uia.no>: > > > > > > > > > > > > IIRC the shortcut is not changed, it still is meta+right(+shift). Only the tooltip was changed to display the system specific key instead of âcmdâ so for Windows/Linux this would be âctrlâ. > > > > > > > > > > > > > > > No, it changed > > > > > > > > > > In #40624, for example, it was cmd (alt-key on windows ) right/shift right > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best regards, > > > > > > > > > > > > Henrik > > > > > > > > > > > > > > > > > > > > > > > > From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Nicolai Hess > > > > > > Sent: Tuesday, June 7, 2016 12:56 PM > > > > > > To: Pharo Development List <pharo-dev(a)lists.pharo.org> > > > > > > Subject: [Pharo-dev] GT-Spotter dive in shortcut > > > > > > > > > > > > > > > > > > > > > > > > Why did the shortcut for dive-in element/category changed from > > > > > > > > > > > > cmd+right > > > > > > > > > > > > cmd+shift+right > > > > > > > > > > > > to > > > > > > > > > > > > ctrl+right > > > > > > ctrl+shift+right > > > > > > > > > > > > I know there were some discussions about this and that the behavior changed some > > > > > > > > > > > > time ago, but I don't know the rational behind this. > > > > > > > > > > > > thanks > > > > > > > > > > > > nicolai > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > www.tudorgirba.com > > > > www.feenk.com > > > > > > > > "If you interrupt the barber while he is cutting your hair, > > > > you will end up with a messy haircut." > > > > > > > > > > > > > > > > > > -- > > > www.tudorgirba.com > > > www.feenk.com > > > > > > "Quality cannot be an afterthought." > > > > > > > > > > > > > -- > > www.tudorgirba.com > > www.feenk.com > > > > "Being happy is a matter of choice." > > -- > www.tudorgirba.com > www.feenk.com > > "Every thing has its own flow." > > > > > > > > -- www.tudorgirba.com www.feenk.com "Don't give to get. Just give."

Aug. 3, 2016

Re: [Pharo-dev] GT-Spotter dive in shortcut

by Nicolai Hess

2016-06-18 23:34 GMT+02:00 Nicolai Hess <nicolaihess(a)gmail.com>: > > > 2016-06-18 20:55 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > >> Hi, >> >> Command is an actual key on Mac next to Option(which is Alt) and Control. >> So, Command is a concrete key and mapping it logically to another key on >> another platform is mixing semantics. >> >> I propose to have two distinct layers in the image: >> 1. the raw layer is about having a distinct selector for each concrete >> key that is found on the keyboard. Right now, it seems to me that the VM >> does a bit of interpretation and mapping, and if it does, I think it should >> just provide a distinct code for each distinct key. >> 2. the portable layer is about having a couple of selectors (e.g., #meta, >> #secondaryMeta) that provide consistent mappings to the raw keys. >> >> So, in this way, #command/#control/#alt would belong to layer 1. and >> #meta/#secondaryMeta (we could find a better name) would belong to layer 2. >> >> Does this make sense? >> >> > So, what does that mean for the text navigation mapping in Rubric. Which > shortcut should I use? > Any way to take a decision? I don't really want to wait until we implement a new layer. > > >> Cheers, >> Doru >> >> >> > On Jun 18, 2016, at 8:42 PM, Nicolai Hess <nicolaihess(a)gmail.com> >> wrote: >> > >> > >> > >> > 2016-06-17 18:25 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: >> > Hi Nicolai, >> > >> > > On Jun 17, 2016, at 2:59 PM, Nicolai Hess <nicolaihess(a)gmail.com> >> wrote: >> > > >> > > >> > > >> > > 2016-06-17 14:35 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: >> > > Hi Nicolai, >> > > >> > > I am a bit removed from the code details at the moment, and I think I >> need to step back a bit :). >> > > >> > > If I understand correctly, you are saying that: >> > > 1. defining bindings with #alt does not work on Windows. This means >> that we should fix this one. Using Cmd should not be a solution here. >> > > >> > > As far as I know, this is on purpose. A key pressed with windows >> (left) alt modified is mapped to "command" >> > > >> > > from vm source: >> > > >> > > * 3) The modifier keys are mapped as follows: >> > > * >> > > * Mac | Win32 >> > > * -------------------- >> > > * Shift -> Shift >> > > * Ctrl -> Ctrl >> > > * Command -> Left ALT >> > > * Option -> Right ALT >> > > >> > > (but actually, the right ALT key does not generate any keystrokes >> (only key down/up) and it is treated as ctrl+alt (windows right Alt key is >> "Alt Grâ) >> > >> > Hmm. I think we have to rethink this one because we need two layers of >> keys: >> > 1. first we should have the raw ones, and >> > >> > what are the "raw" ones? The events the OS generates or the events the >> VM send out to the image? >> > >> > 2. another layer that offers a more logical keys (like meta). >> > >> > Can you explain this a bit more. >> > >> > >> > What do you think? >> > >> > >> > > 2. defining the >> > > bindings for Spotter can indeed be made to override the ones in the >> text editor if needed. But, I think we can start thinking about using #alt. >> > > >> > > using alt+right on windows/linux and >> > > command + right on mac >> > > for dive-in or for text navigation? >> > > >> > > Is there a default keycombination for word-moving in text components >> for mac ? >> > >> > On Mac, typically Alt+Right/Left moves between words. >> > >> > So, we would need a logical modifier that would mean: >> > - Mac: Alt >> > - Win: Ctrl >> > - Linux: Ctrl >> > >> > I though this is what Guillermo already did, but with "command" >> > >> > - Mac: Command >> > - Win/Linux: Ctrl >> > >> > Why did we choose Command and not Alt in the first place, why is Alt >> now better? >> > >> > >> > >> > What do you think? >> > >> > Cheers, >> > Doru >> > >> > >> > > >> > > Does this make sense? >> > > >> > > Cheers, >> > > Doru >> > > >> > > >> > > > On Jun 17, 2016, at 12:12 AM, Nicolai Hess <nicolaihess(a)gmail.com> >> wrote: >> > > > >> > > > >> > > > >> > > > 2016-06-16 22:45 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: >> > > > Hi, >> > > > >> > > > I think we are mixing the topics a bit. The #meta discussion is not >> specific to Spotter actions. >> > > > >> > > > On windows, it is. Because on windows #meta is mapped to #ctrl, and >> you can use ctrl+left/right for moving by "words". This works in a >> browser, an editor, pharos text components but *not* in spotter >> > > > because spotter redefines this keystrokes for dive in /out. >> > > > Currently, both ctrl+left/right and alt+left/right (and shift for >> selection) are working in rubric for moving by "word". But only because the >> (old) shortcut (cmd/shiftcmd) action dispatcher >> > > > explicitly allows both. If we want to remove this and use the >> KMDispatcher framework only, we *need* to define only one mapping, >> otherwise you won't be able to use dive in/out in spotter. >> > > > (Or you could modify spotter to register(overwrite) the mapping on >> the textfield instead of the spotter morph). >> > > > >> > > > >> > > > The idea was to offer a uniform support of keybindings in Pharo, in >> general. >> > > > >> > > > exactly, and using ctrl+left/right uniformly in editor and external >> tools would be great. >> > > > >> > > > Then Guille etal added #meta to have a predictable mapping. >> > > > >> > > > Yes, and to make this work, we have to remove the old keymapping >> implementation (cmd/shiftcmd action map) and use the KMDispatcher >> registration. But I can only continue with this >> > > > if we have a decision what to use, (windows/linux: either >> ctrl+arrow or alt+arrow, mac: whatever is used on a mac for text navigation) >> > > > >> > > > All #cmd places were changed to #meta, and since then we should not >> use explicitly #cmd anymore, except when we know we are on Mac. For a >> portable modifier, we should only use #meta. >> > > > >> > > > At this point, both Rubric and Spotter use #meta. #meta maps on: >> > > > - Mac: Command >> > > > - Win: Control >> > > > - Linus: Control >> > > > >> > > > This means that #alt is now a portable modifier that will not >> conflict with #meta, so we can now think of using that one in combination >> with #meta. >> > > > >> > > > You can not use #alt modifier on windows. A shortcut definition like >> > > > $g alt >> > > > is never recognized. You have to define it >> > > > $g command >> > > > to make it work with as "alt+g"-keycombination (on windows). >> > > > >> > > > >> > > > >> > > > For text navigation, the situation is a bit complicated. On >> Win/Linux, Ctrl+Right/Left moves the cursor between words. On Mac, >> Cmd+Right/Left moves the cursor at the end/beginning of line. So, using >> #meta for text navigation between words is not entirely accurate. We should >> use #ctrl instead. >> > > > >> > > > This would anyway mean that it would be an option to use #alt for >> Spotter now. But, if we are at it, would anyone be interested in working on >> revisiting the overall keybindings in Pharo? >> > > > >> > > > Cheers, >> > > > Doru >> > > > >> > > > >> > > > >> > > > > On Jun 16, 2016, at 10:22 AM, Nicolai Hess <nicolaihess(a)gmail.com> >> wrote: >> > > > > >> > > > > >> > > > > >> > > > > 2016-06-07 16:12 GMT+02:00 Andrei Chis < >> chisvasileandrei(a)gmail.com>: >> > > > > We can, but I remember there were some discussions and it was >> decided to use meta everywhere. >> > > > > >> > > > > Cheers, >> > > > > Andrei >> > > > > >> > > > > >> > > > > If we don't change this, I'll use cmd+left cmd+right in rubric, >> but this is bad, because all other navigate/select+navigate shortcuts would >> use meta as shortcut modifier. >> > > > > >> > > > > What are the arguments for using meta for dive-in/out shortcuts ? >> > > > > >> > > > > >> > > > > >> > > > > On Tue, Jun 7, 2016 at 3:49 PM, Nicolai Hess < >> nicolaihess(a)gmail.com> wrote: >> > > > > >> > > > > >> > > > > 2016-06-07 15:08 GMT+02:00 Andrei Chis < >> chisvasileandrei(a)gmail.com>: >> > > > > During Pharo 5 most shortcuts from tools were changed to use >> "meta" instead of cmd. >> > > > > >> > > > > Cheers, >> > > > > Andrei >> > > > > >> > > > > Can we change this for spotter ? cmd instead of meta >> > > > > >> > > > > ctrl left/right is often used for text components to move to >> next/previous word. >> > > > > >> > > > > >> > > > > >> > > > > On Tue, Jun 7, 2016 at 2:18 PM, Nicolai Hess < >> nicolaihess(a)gmail.com> wrote: >> > > > > >> > > > > >> > > > > 2016-06-07 13:57 GMT+02:00 Nicolai Hess <nicolaihess(a)gmail.com>: >> > > > > >> > > > > Am 07.06.2016 1:56 nachm. schrieb "Henrik Nergaard" < >> henrik.nergaard(a)uia.no>: >> > > > > > >> > > > > > IIRC the shortcut is not changed, it still is >> meta+right(+shift). Only the tooltip was changed to display the system >> specific key instead of âcmdâ so for Windows/Linux this would be âctrlâ. >> > > > > >> > > > > >> > > > > No, it changed >> > > > > >> > > > > In #40624, for example, it was cmd (alt-key on windows ) >> right/shift right >> > > > > >> > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > Best regards, >> > > > > > >> > > > > > Henrik >> > > > > > >> > > > > > >> > > > > > >> > > > > > From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On >> Behalf Of Nicolai Hess >> > > > > > Sent: Tuesday, June 7, 2016 12:56 PM >> > > > > > To: Pharo Development List <pharo-dev(a)lists.pharo.org> >> > > > > > Subject: [Pharo-dev] GT-Spotter dive in shortcut >> > > > > > >> > > > > > >> > > > > > >> > > > > > Why did the shortcut for dive-in element/category changed from >> > > > > > >> > > > > > cmd+right >> > > > > > >> > > > > > cmd+shift+right >> > > > > > >> > > > > > to >> > > > > > >> > > > > > ctrl+right >> > > > > > ctrl+shift+right >> > > > > > >> > > > > > I know there were some discussions about this and that the >> behavior changed some >> > > > > > >> > > > > > time ago, but I don't know the rational behind this. >> > > > > > >> > > > > > thanks >> > > > > > >> > > > > > nicolai >> > > > > > >> > > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > >> > > > -- >> > > > www.tudorgirba.com >> > > > www.feenk.com >> > > > >> > > > "If you interrupt the barber while he is cutting your hair, >> > > > you will end up with a messy haircut." >> > > > >> > > > >> > > > >> > > >> > > -- >> > > www.tudorgirba.com >> > > www.feenk.com >> > > >> > > "Quality cannot be an afterthought." >> > > >> > > >> > > >> > >> > -- >> > www.tudorgirba.com >> > www.feenk.com >> > >> > "Being happy is a matter of choice." >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "Every thing has its own flow." >> >> >> >> >> >> >> >

Aug. 3, 2016

Re: [Pharo-dev] let's talk about themes (and GLMBrickThemer)

by stepharo

Hi esteban Next time I have a look at Bloc2 I will check if there is such concept and see how we can package it. Stef Le 2/8/16 Ã 12:06, Esteban Lorenzano a Ã©crit : > >> On 02 Aug 2016, at 08:59, stepharo <stepharo(a)free.fr >> <mailto:stepharo@free.fr>> wrote: >> >> Hi esteban >> >> It looks cool. For the error could you use a different one because I >> cannot read it. >> >> Else when I tried to use the same way than Setting to manage skins it >> did not work >> > because theming is a lot of things: > > - a skin > - a color palette > - etc. > > for now, I would be happy with extract the color palette into a > âStyleSheetâ objectâ¦ this could be modified in settings (while a > complete skin not). > > Esteban > >> because a skin is not just color it can be behavior and you have to >> attach it somewhere. >> >> Now in bloc 2 :) >> >> you can the look (that can be expressed with CSS) >> >> and you have skins (the behavior: a date can be displayed as a >> calendar vs. a roller). >> >> In this model a theme (color) will just be similar to applying a new >> CSS. >> >> Stef >> >> >> Le 1/8/16 Ã 11:13, Esteban Lorenzano a Ã©crit : >>> Hi, >>> >>> For one of my side-projects, I made a new theme for Pharo (still no >>> name, I was planing to call it âDark Metalâ or something like that. >>> Is a variation on the Dark Theme but âourâ dark theme is more brown >>> and this one is more blue (see attached)â¦ I wanted to publish it to >>> push it but then I arrived to an unexpected problem: For Spotter and >>> GTTools in general, theming is not done following current theming >>> approach. Instead, they made a full hierarchy of objects. >>> >>> IMO this is plain bad. I understand the attempt to decouple, but now >>> that means if I want to create a new theme, I need to create my >>> theme object with colors I want and then also I need to create an >>> undetermined number of classes (at least one for each tool, but >>> there is also a hierarchy of things there)â¦ anyway, this DOES NOT >>> scale. Because each tool will have to have a âtheme classâ for each >>> existing themeâ¦ >>> How themes (skins, bah) work in all word is to have a color palette >>> and then tools takes them (they can âplayâ a bit with this palette, >>> but need to always respect the palette). >>> >>> Then, I will commit a SLICE modifying the âthemerâ classes to take >>> colors from the current theme (instead of have them hardcoded). >>> But of course, how theme work now is not good because they mix >>> âthemeâ (how they display) and âskinâ (color palette). I will also >>> extract the palette to where should have always been (some kind of a >>> style sheet object)â¦ who also should have been editable in settings >>> so people can tweak their configuration. >>> >>> I didnât wanted to touch this before, because this will supposedly >>> change with brick, but honestly this will not be ready for Pharo 6 >>> and this is annoying (also, I want to publish my theme and I do not >>> want to add overrides all around :P) >>> >>> cheers, >>> Esteban >>> >>> >>> <Mail Attachment.png> >> >

Aug. 2, 2016