- Pharo-dev - lists.pharo.org

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

Re: [Pharo-dev] Odd Commits to Soup Repo

by stepharo

then this is good because esteban told me that it was not some time ago :). Stef Le 2/8/16 Ã 20:05, monty a Ã©crit : > It's worked for me in the past. For example, when I migrated projects from a shared repo to separate repos. But the files don't always disappear immediately. > >> Sent: Tuesday, August 02, 2016 at 3:03 AM >> From: stepharo <stepharo(a)free.fr> >> To: pharo-dev(a)lists.pharo.org >> Subject: Re: [Pharo-dev] Odd Commits to Soup Repo >> >> Hi Paul >> >> It never works with me. Did you check that the file is really not there >> after. >> >> Stef >> >> Le 28/7/16 Ã 22:26, Paul DeBruicker a Ã©crit : >>> Sure you can delete mcz from Smalltalkhub. Or at least the Web UI offers a >>> 'Delete .mcz' button, which appears to work. >>> >>> Sign in >>> Navigate to the project >>> Click on Commits >>> Find the MCZ you want to delete >>> Click the name of the MCZ >>> Click the "Delete .mcz" button >>> >>> >>> It should then be deleted. >>> >>> As a test I deleted >>> ConfigurationOfAutomaticMethodCategorizer-StephaneDucasse.4, >>> Pharo-Launcher-Core-DamienCassou.21, and >>> ConfigurationOfPharoLauncher-DamienCassou.9 from the PharoExtras/Soup repo >>> >>> Or did you mean something else? >>> >>> >>> >>> >>> Hope this helps >>> >>> >>> Paul >>> >>> >>> >>> >>> >>> stepharo wrote >>>> Yes but we cannot remove file in Smalltalkhub repo. >>>> >>>> >>>> Stef >>>> >>>> >>>> Le 28/7/16 Ã 18:47, Sean P. DeNigris a Ã©crit : >>>>> I found ConfigurationOfPharoLauncher-DamienCassou.9 & >>>>> Pharo-Launcher-Core-DamienCassou.21 there. I assume they were uploaded by >>>>> mistake... >>>>> >>>>> >>>>> >>>>> ----- >>>>> Cheers, >>>>> Sean >>>>> -- >>>>> View this message in context: >>>>> http://forum.world.st/Odd-Commits-to-Soup-Repo-tp4908492.html >>>>> Sent from the Pharo Smalltalk Developers mailing list archive at >>>>> Nabble.com. >>>>> >>>>> >>> >>> >>> >>> -- >>> View this message in context: http://forum.world.st/Odd-Commits-to-Soup-Repo-tp4908492p4908538.html >>> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >>> >>> >> >> >

Aug. 2, 2016

Re: [Pharo-dev] Bloc, Bloc 2 and Brick

by stepharo

Le 2/8/16 Ã 15:47, Ben Coman a Ã©crit : > On Tue, Aug 2, 2016 at 6:58 PM, Torsten Bergmann <astares(a)gmx.de> wrote: >> Hi Stef, >> >> from past discussions/threads I know "Bloc" as Pharo's possible future UI, watched the video [1] and have played with the premade >> image from the CI Server. Also the Brick layer (which is on top of Bloc) was announced as a preview once [2]. >> >> >> Now in some of the mails it was mentioned that there will be or already is a "Bloc 2" (see [3]). Can you or the person >> working on it summarize: >> >> - who works on it >> - what are the goals, what will be included (like the CSS styling) >> - where it is hosted >> - what the status is >> - if there is already a CI build or preview >> - how Brick will relate to "Bloc 2", will there be a "Brick 2" as well? >> - if it will work with Spec >> >> Even if not all could be answered (yet) more informations on "Bloc 2" would really be nice, ideally as a >> status summary to the community. >> >> Thanks >> T. >> >> [1] https://vimeo.com/115336678 >> [2] http://gtoolkit.org/brick/ >> [3] http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2016-August/1231… >> You see as I mention in my other mail: Glenn was not happy with the move inside Bloc1+ and he took all his experience and discussions on Bloc1+ and build a new one. > You read my thoughts Torsten. It would seem something has been learnt > from Bloc 1 to necessitate a change in direction. This would be > interesting to know, as well as the plan for the new architecture. The plans (as far as Alain, Glenn and Thales are concerned) is that we will have a roadmap soon :) > > I don't know what is the funding arrangements are to develop Bloc 2. There are none. Glenn is doing it instead of working on his PhD but he needs it also for his PhD. and I hope part of it will be able to be part of his PhD. My plan is to help Glenn for his PhD. > If its mostly someone's free time then maybe we can't put too much > demands on status report. However since Bloc will become a core part > of Pharo, perhaps it is worthwhile for the Pharo Association (or other > body) to fund such a status report for the community. A detailed > forward plan may have the side effect to encourage participation. Glenn and Alain were a bit secret because it was not clear how Bloc contributors would react. I was involved since I push Bloc since its early genesis. Since now this is going in the right direction, the project is now public, you can load it and it works. I do not know if the discussions are public on pharo slack channels now (they should be in Pharo and not in a private slack). Now what is important to understand is that Glenn is busy and Alain has some family problems. Now the plan is to have a presentation at ESUG between aliak and glenn. So we should get something. Stef > > cheers -ben > >

Aug. 2, 2016

Re: [Pharo-dev] Bloc, Bloc 2 and Brick

by stepharo

Hi Torsten Thanks for your interest. Yes Bloc is important to me (I'm waiting for it since Miro and Miro2 and all the work I asked igor to do around Athens and SDL) Glenn sent me a teaser (see attachement) last week Le 2/8/16 Ã 12:58, Torsten Bergmann a Ã©crit : > Hi Stef, > > from past discussions/threads I know "Bloc" as Pharo's possible future UI, watched the video [1] and have played with the premade > image from the CI Server. Also the Brick layer (which is on top of Bloc) was announced as a preview once [2]. > > > Now in some of the mails it was mentioned that there will be or already is a "Bloc 2" (see [3]). Can you or the person > working on it summarize: > > - who works on it Glenn Cavarle with Alain Plantec (and me from far and too little time) and Doru but I do not know much from that part. > - what are the goals, what will be included (like the CSS styling) Glenn implemented a new version of Bloc because he needed one for his job The flux in Bloc from October did not match with his requirements so without telling it to Alain and me he built one until he could show us something working and it works. I should say that I was also frustrated by the results of the discussions since October. Especially since before presenting Bloc to ESUG we got 4 versions and I tried to follow alain and help him documenting Bloc and while my stupid questions helped him it was difficult for me. So I really appreciate the effort of Glenn. In June we spent three days to understand if we should merge Bloc2 into Bloc and we decided the inverse because his implementation is based on SDL and a separate window) it does not suffer from the morphic plague. So for example the event bubbling is nice and clean. The idea is to be able to use one window (morphic) to develop all the widgets and displayed in the SDL window needed up to the point where we can remove morphic. So Bloc2 can benefit from the work of Aliak on Sparta and the mozzD backend. The idea is also to integrate the work on aliak on layouts. > - where it is hosted For the moment you can find it in GlennCavarle repo on smalltalkhub. Glenn is working for a company for ihs PhD and a week on two he is working on Bloc2. Bloc2 is key for Glenn and Alain since Thales wants to use it. MCHttpRepository location: 'http://smalltalkhub.com/mc/GlennCavarle/Bloc2/main' user: '' password: '' Now with the name removal we got some trouble to load it in Pharo 60. You can load it in Pharo 50. Say yes to all the warnings. Doru told me that he is talking with Glenn and that Bloc2 will be moved to the Bloc repo (by the end of this week). Esteban is following the discussions and will help for the SDL part and FFI. The SDL is fragile and the system freezes from time to time. But 64 bits first :) > - what the status is The core design looks stable to me. We can import SVG, create first buttons and style them (the skins in Bloc2 are so far not a theme) and the CSS is not for Skins but for style. Widgets can start to be built on top. The problem is that Brick took a glitch in Bloc1 and uses it against the expectation of Alain. So I do not think that we can port easily Brick to Bloc2. I started to read everything. And I will start to improve the class comments. Bloc2 - nice core - SDL based - nice bubbling of event - Bloc1+ Sparta and MozzD back end - Bloc1+ aliak layout - Bloc1 event handler - CSS styling Here is what glenn sent me last week (I translated it but thunderbird crashed!) Concernant Bloc, Ã§a devient assez stable mais il reste encore des sujets Ã valider/amÃ©liorer/stabiliser: - styles&themes -> 1Ã¨re Ã©bauche rÃ©alisÃ©e - Path (Shapes custom) -> voir ce que l'on peut reprendre de Athens-SVG - KeyBinding -> 1Ã¨re version trÃ¨s simple rÃ©alisÃ©e mais sans la gestion des sÃ©quences (ctrl A+B) - Animation -> premiÃ¨re version plutÃ´t concluante - ParentÃ© des fenÃªtres ou sous-fenÃªtres - AmÃ©lioration des performances de dessin par crÃ©ation de surfaces au niveau de BlElement -> premier rÃ©sultats concluant mais non-intÃ©grÃ©. - Gestion des Gestures (MultiTouch) -> migration des gestures d'OSWindow au niveau de Bloc sous forme d'EventListener (pas de gestures globales) - Gestion du Focus keyboard -> la base y est mais il reste encore pas mal de boulot - Mise en relation DnD et Clipboard -> l'instructure est lÃ mais il reste Ã faire le "cablage" - ... J'essaie de mettre ma roadmap au propre pour dÃ©but de semaine prochaine. Les prochains widgets sur ma liste sont: scrollbar & liste Now Doru told me that he should discuss with Glenn of certain design point. My wish is that such discussions do not kill Bloc2 because else I will leave this community :). Now I'm confident that something good will happen because Glenn needs it for his future. > - if there is already a CI build or preview There are examples. During holiday I tried to set up a jenkins but the network was too bad. This is on my todo but I'm busy since I'm back to work. > - how Brick will relate to "Bloc 2", will there be a "Brick 2" as well? I think that Brick should be rewritten on top of Bloc2 because the design of Brick was the thing that made Bloc get changed in October and after it changed too much. > - if it will work with Spec Spec is orthogonal. As soon as we will have widgets we will do a Spec binding for them. In the long term we will see if another framework wants to replace Spec to compose widgets (I know that alain has some ideas) but for now we want to be able to move our tool fast to new Brick and it should be possible and it should also simplify Spec because some of the design points of Spec are ugly because the old widget relay on change/update and what is needed is a notification (announcement). > Even if not all could be answered (yet) more informations on "Bloc 2" would really be nice, ideally as a > status summary to the community. > > Thanks > T. > > [1]https://vimeo.com/115336678 > [2]http://gtoolkit.org/brick/ > [3]http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2016-August/12… > >

Aug. 2, 2016