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

strange errors in jenkins jobs

by Tudor Girba

Hi, Since yesterday, all Moose-related jobs are failing. These are built on top of Pharo 5.0 stable, downloaded like this: wget --quiet -O - http://get.pharo.org/50+vm | bash We did not change anything in the projects that fail, and locally on Mac, I can load any of the code without problems. The jobs are running Linux. So, I am wondering if anything else has changed in Pharo 5.0. In particular, the error is quite strange. It looks like this: [31mError: MessageNotUnderstood: receiver of "finish" is nil [0mUndefinedObject(Object)>>error: [ :err :rcvr | | errCtx errMorph | errCtx := thisContext. [ errCtx := errCtx sender. "Search the sender chain to find the morph causing the problem" [ errCtx notNil and: [ errCtx receiver isMorph not ] ] whileTrue: [ errCtx := errCtx sender ]. "If we're at the root of the context chain then we have a fatal drawing problem" errCtx ifNil: [ ^ self handleFatalDrawingError: err ]. errMorph := errCtx receiver. ... See more at: https://ci.inria.fr/moose/job/fame/1266/console Any idea of what might be wrong? Cheers, Doru -- www.tudorgirba.com www.feenk.com "We cannot reach the flow of things unless we let go."

Aug. 7, 2016

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

by Tudor Girba

Hi, > On Aug 7, 2016, at 9:16 PM, stepharo <stepharo(a)free.fr> wrote: > >>> On Jun 17, 2016, at 6:04 PM, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: >>> >>> #alt_meta ? >>> - Maps to alt on OSX, ctrl on Win/Linux. >>> - Can only bind either #meta or #alt_meta + key, or both must bind to same action. >>> - Can only be applied to a very limited set of keys, (usually those employed in navigation). >>> (here are *alot* of different keyboard layouts on Mac using alt + key to generate crucial characters, allowing alt + key as shortcut in general is bound to end in disaster sooner or later) >> Thanks for the input! >> >> Indeed, using Alt for Mac for anything else than text is not so nice. However, on Mac we could use Ctrl. To this end, we could introduce a secondaryMeta that maps like this: >> - Mac: Ctrl >> - Win: Alt >> - Linux: Alt >> >> What do you think? > > Would be ok but why do we need secondary meta? Having only one platform-independent modifier would likely not be enough to handle all key combinations we would want. I think that if we would have a second platform-independent modifier would not hurt. Cheers, Doru > Stef > > -- www.tudorgirba.com www.feenk.com "Obvious things are difficult to teach."

Aug. 7, 2016

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

by stepharo

>> On Jun 17, 2016, at 6:04 PM, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: >> >> #alt_meta ? >> - Maps to alt on OSX, ctrl on Win/Linux. >> - Can only bind either #meta or #alt_meta + key, or both must bind to same action. >> - Can only be applied to a very limited set of keys, (usually those employed in navigation). >> (here are *alot* of different keyboard layouts on Mac using alt + key to generate crucial characters, allowing alt + key as shortcut in general is bound to end in disaster sooner or later) > Thanks for the input! > > Indeed, using Alt for Mac for anything else than text is not so nice. However, on Mac we could use Ctrl. To this end, we could introduce a secondaryMeta that maps like this: > - Mac: Ctrl > - Win: Alt > - Linux: Alt > > What do you think? Would be ok but why do we need secondary meta? Stef

Aug. 7, 2016

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

by Nicolai Hess

2016-08-07 19:58 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > > > On Aug 7, 2016, at 6:24 PM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > > > > > 2016-08-07 16:23 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > > Hi, > > > > > On Aug 7, 2016, at 4:13 PM, Nicolai Hess <nicolaihess(a)gmail.com> > wrote: > > > > > > > > > > > > 2016-08-07 15:23 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > > > Hi, > > > > > > > > > > On Aug 3, 2016, at 11:16 AM, Nicolai Hess <nicolaihess(a)gmail.com> > wrote: > > > > > > > > > > > > > > > > 2016-08-03 10:02 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > > > > 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. > > > > > > > > But how? > > > > If I add this to RubTextEditor class>>#buildShortcutsOn: aBuilder > > > > > > > > > > > > (aBuilder shortcut: #nextWord) > > > > category: RubTextEditor name > > > > default: Character arrowRight meta > > > > do: [ :target :morph :event | target editor cursorRight: > event] > > > > description: 'move to next word'. > > > > > > > > > > > > > > > > (aBuilder shortcut: #previousWord) > > > > category: RubTextEditor name > > > > default: Character arrowLeft meta > > > > do: [ :target :morph :event | target editor cursorLeft: > event] > > > > description: 'move to the previous word'. > > > > > > > > > > > > we can not dive in/out in spotter. > > > > > > > > This is why I asked: > > > > > > > > Why did the shortcut for dive-in element/category changed from > > > > cmd+right > > > > cmd+shift+right > > > > to > > > > ctrl+right > > > > ctrl+shift+right > > > > > > Oh, I see now! > > > > > > The change was made from cmd+right to meta+right in the move of Guille > to make all keybindings uniform. > > > > > > If a keybinding would be problematic in Spotter, we could also > override the keybinding directly in the Spotter editor, I think. What do > you think? > > > > > > what is Spotter editor? if it is the text input field, yes, but you > have to overwrite it on this morph > > > > That is what I meant, to define the keys for diving twice, once in the > spotter morph and once in the text input field. This should solve the > problem, right? > > > > twice ? > > On a second thought, this is probably not needed because the focus should > always be in the text input morph :). > > Still, we would only do that after we introduce the âlayeringâ. > > Would this be Ok with you? > > Cheers, > Doru > Oh well .... Please take a look at the current implementation of event handling, just 10 minutes or so. how we use different (shortcut) event registration shortcut handling event handling some are defined in code, some shortcuts handled by the editor , some by the morph some shortcuts are defined on the morph that gets the events, some are defined on other morphs. some event (shortcuts spotters dive in / dive out) only works *because* we have the two shortcut handlers (handleKeystroke: / dispatchKeystroke:) and tell me that it is a good idea to just start introducing something new I really think we should clean up what we have now or at least finish the move to the kmdispatcher event handling. > > > > > Cheers, > > Doru > > > > > right now spotter defines the shortcut on the spotter morph. This won' > t work > > > if rubtext components define the word-movement with the kmdispatcher. > ( I already explained why). > > > > > > > > > > > > > > > Cheers, > > > Doru > > > > > > > > > > > > > > > > > > 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." > > > > > > -- > > > www.tudorgirba.com > > > www.feenk.com > > > > > > "What is more important: To be happy, or to make happy?" > > > > -- > > www.tudorgirba.com > > www.feenk.com > > > > "We cannot reach the flow of things unless we let go." > > -- > www.tudorgirba.com > www.feenk.com > > "It's not how it is, it is how we see it." > > >

Aug. 7, 2016

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

by stepharo

i, >> 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. > +1000. We should avoid our abstract shortcut key modifiers overlaping > concrete keys. yes it seems like a good idea. > 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. > Sounds good. what is secondaryMeta?

Aug. 7, 2016

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

by stepharo

Le 16/6/16 Ã 22:45, Tudor Girba a Ã©crit : > Hi, > > I think we are mixing the topics a bit. The #meta discussion is not specific to Spotter actions. > > The idea was to offer a uniform support of keybindings in Pharo, in general. Then Guille etal added #meta to have a predictable mapping. 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. > > 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? > It would be good. I would really like to have an agreement on nautilus and non nautilus - implementors - senders - references Now this is not easy. In addition, having on implementors falling back on class browse and the inverse too is really nice to have like that we do not have to think "ok this piece of text represent a class so that I should browse)" or "this piece of text is a method so I have to ask implementor (browse should bring implementor) we could also get back on binding. We could do the same for senders/references (that are the same concept). I already fixed that and it was lost two times. Stef

Aug. 7, 2016

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

by stepharo

Le 7/6/16 Ã 16:33, Guille Polito a Ã©crit : > For coherence, the vast majority of shortcuts should follow the > standard in all applications. Most shortcuts use cmd in mac, and ctrl > in unix/win. > > Then there are exceptions of course. I'd like exceptions to be that, > exceptions, and well documented. I'm not against using #alt for > particular cases (for example, it is often used in windows/linux for > menu navigation). > > Also, I'd like shortcuts that are meant to be used with #alt to use > #alt and not #command. Because #command means the windows key in windows. > > That said, If the problem are shortcut conflicts, I think it would be > nice at some moment to make a step back, look at the big picture and > design shortcuts for the entire system instead of patching place over > place :). Yes and we should experiment with a hierarchy of command. and I would love to have cmd k cmd e end of line and others from emacs (of course in my own shortcut bindings preferences :) > > Guille > -------- Original Message -------- >> >> >> 2016-06-07 16:12 GMT+02:00 Andrei Chis <chisvasileandrei(a)gmail.com >> <mailto:chisvasileandrei@gmail.com>>: >> >> We can, but I remember there were some discussions and it was >> decided to use meta everywhere. >> >> >> >> but using meta everywhere does not help if there are conflicts with >> other shortcuts. >> >> >> Cheers, >> Andrei >> >> On Tue, Jun 7, 2016 at 3:49 PM, Nicolai Hess >> <nicolaihess(a)gmail.com <mailto:nicolaihess@gmail.com>> wrote: >> >> >> >> 2016-06-07 15:08 GMT+02:00 Andrei Chis >> <chisvasileandrei(a)gmail.com >> <mailto:chisvasileandrei@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 <mailto:nicolaihess@gmail.com>> >> wrote: >> >> >> >> 2016-06-07 13:57 GMT+02:00 Nicolai Hess >> <nicolaihess(a)gmail.com <mailto:nicolaihess@gmail.com>>: >> >> >> Am 07.06.2016 1:56 nachm. schrieb "Henrik >> Nergaard" <henrik.nergaard(a)uia.no >> <mailto:henrik.nergaard@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 >> <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 >> <mailto:pharo-dev@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 >> > >> > >> >> >> >> >> >> > > >

Aug. 7, 2016

Re: [Pharo-dev] Spec TreeModel get selected items in order

by Nicolai Hess

2016-08-07 20:06 GMT+02:00 Henrik Nergaard <henrik.nergaard(a)uia.no>: > The test #testPickedChangesAfterSelect selects an item which is not in the > browser, so I would consider that a bug. > > > > Adding the item to the browser before selecting it should be correct and > make the test work. > > > > ChangesBrowserTest >> testPickedChangesAfterSelect > > | item | > > Item := RBAddClassChange. > > Item definition: âtestâ controller: nil. > > Browser changes: {item}. > > Self assert: â¦.. > > â¦. > > > > Best regards, > > Henrik > did you try it ? This is how I changed #pickedChanges pickedChanges | selectedChanges | selectedChanges := changesTree selectedItems collect: [ :item | item content ]. ^ selectedChanges ifNotEmpty: [ changes select: [ :change | selectedChanges includes: change ] ] The test does not work, even if I add the item to the changes browser. > > > *From:* Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] *On Behalf > Of *Nicolai Hess > *Sent:* Sunday, August 7, 2016 7:46 PM > *To:* Pharo Development List <pharo-dev(a)lists.pharo.org> > *Subject:* Re: [Pharo-dev] Spec TreeModel get selected items in order > > > > > > > > 2016-08-07 18:23 GMT+02:00 Nicolai Hess <nicolaihess(a)gmail.com>: > > > > > > 2016-08-07 17:53 GMT+02:00 Henrik Nergaard <henrik.nergaard(a)uia.no>: > > ListModel has that: #selectedItemsSorted, but looking at the tree model > structure I guess the simplest way is to just traverse the whole structure > until the selected nodes are found. > > Something like this should do the trick: > > > > -------------------------------------------------- > > TreeModel >> selectionSorted > > | ordered lookingFor search | > > > > ordered := OrderedCollection new. > > > > lookingFor := self selectedItems asIdentitySet. > > LookingFor ifEmpty: [ ^ #() ] > > search := [ :nodes | > > nodes do: [ :node | > > (lookingFor includes: node) > ifTrue: [ > > ordered add: > node. > > lookingFor > remove: node. > > lookingFor > isEmpty ifTrue: [ ^ ordered asArray ] > > ]. > > search value: node children > value > > ] > > ]. > > > > search value: self roots. > > > > self error: 'should not happen' > > > > -------------------------------------- > > > > Thanks Peter, Henrik, > > yes I was afraid there is no other way. > > > > > > I tried to fix this, but there is a test case for the ChangesBrowser that > tests the selection. > > The problem is, that the test case selects an item by calling > #selectedItem: and the behavior is different for when this is called by the > view. > > The test case just selects the "change", whereas when this is called by > the view, the selected item is TreeNodeModel (with #contents). > > And I can not fix #pickedChanges without breaking this test. > > Any Idea ? > > > > > > > > > > Best regards, > > Henrik > > > > *From:* Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] *On Behalf > Of *Nicolai Hess > *Sent:* Sunday, August 7, 2016 4:55 PM > *To:* Pharo Development List <pharo-dev(a)lists.pharo.org> > *Subject:* [Pharo-dev] Spec TreeModel get selected items in order > > > > Hi, > > Is there a way to retrive the selected nodes of a TreeModel in the same > order they are > > shown in the widget ? > > For example, open this tree model, and select item 5/4/3/1 > |t| > Transcript clear. > t := TreeModel new. > t beCheckList ; > autoMultiSelection: true. > t roots:((1 to:10) collect:[:c | TreeNodeModel new > content:c;hasContentToShow:true]). > t openWithSpec. > t inspect . > > Now, if I try to collect the selected items with > > t selectedItems collect:#contents > > they appear in the order I selected them, but I would like to get the > order > 1/2/3/4/5 > > thanks > > Nicolai > > > > >

Aug. 7, 2016

Re: [Pharo-dev] Status of SmallPOS

by stepharo

> Well, general procedure is loading magritte, then loading seaside 2.8, > then loading SmallPOS...I made some packaging efforts, see > https://code.google.com/archive/p/smalltalkpos/wikis/FullyAutomatedGoferScr… ok I do not have the time now to write configuration (working on boring report). > > But, well, at the moment simplest possibility is sending you > pre-configured image. I may make one for you, if you want. > > Another trouble is: SmallPOS is not the management software, it's a > framework for making management software. I.e., if only smallpos > loaded, then you can't look at how it *works*. > > If you want, I may tinker a small SmallPOS-based example, it's easy > and usefull anyway, so do not hesitate to ask :) Something like "Firms > and persons", or "books, authors and bookholders" or "teachers, > students and courses" - feel free to propose one. It would be nice. I want to see if I can say to lionel to have a look :) > > There ARE some real-life examples at the same repo, but trouble is > they are tinkered for russian market, so all the labels in russian :) > > Greetings, > Yuriy Mironenko > > 2016-08-07 14:36 GMT+03:00 stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>>: > > There is no configuration and I tried to load the latest version > and it looks like it depends on magritte. > > How do you load it? > > > Stef > > > Le 30/7/16 Ã 19:16, Yuriy Mironenko a Ã©crit : > > Sorry for answering the "deadly long forgotten" post, but, > anyway: it happens > > at the moment of migration to ss3, I believe. I don't really > remember actual > "relicensing" process, I think it was just...welll...selecting > from the > drop-down list, and this time I selected another option. > > If you or somebody else will ever need SmallPOS under any > other open > license, I will be glad to deliver it under this license. > > > > -- > View this message in context: > http://forum.world.st/Status-of-SmallPOS-tp4649796p4908797.html > <http://forum.world.st/Status-of-SmallPOS-tp4649796p4908797.html> > Sent from the Pharo Smalltalk Developers mailing list archive > at Nabble.com. > > > > >

Aug. 7, 2016

Re: [Pharo-dev] Spec TreeModel get selected items in order

by Henrik Nergaard

The test #testPickedChangesAfterSelect selects an item which is not in the browser, so I would consider that a bug. Adding the item to the browser before selecting it should be correct and make the test work. ChangesBrowserTest >> testPickedChangesAfterSelect | item | Item := RBAddClassChange. Item definition: âtestâ controller: nil. Browser changes: {item}. Self assert: â¦.. â¦. Best regards, Henrik From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Nicolai Hess Sent: Sunday, August 7, 2016 7:46 PM To: Pharo Development List <pharo-dev(a)lists.pharo.org> Subject: Re: [Pharo-dev] Spec TreeModel get selected items in order 2016-08-07 18:23 GMT+02:00 Nicolai Hess <nicolaihess(a)gmail.com<mailto:nicolaihess@gmail.com>>: 2016-08-07 17:53 GMT+02:00 Henrik Nergaard <henrik.nergaard(a)uia.no<mailto:henrik.nergaard@uia.no>>: ListModel has that: #selectedItemsSorted, but looking at the tree model structure I guess the simplest way is to just traverse the whole structure until the selected nodes are found. Something like this should do the trick: -------------------------------------------------- TreeModel >> selectionSorted | ordered lookingFor search | ordered := OrderedCollection new. lookingFor := self selectedItems asIdentitySet. LookingFor ifEmpty: [ ^ #() ] search := [ :nodes | nodes do: [ :node | (lookingFor includes: node) ifTrue: [ ordered add: node. lookingFor remove: node. lookingFor isEmpty ifTrue: [ ^ ordered asArray ] ]. search value: node children value ] ]. search value: self roots. self error: 'should not happen' -------------------------------------- Thanks Peter, Henrik, yes I was afraid there is no other way. I tried to fix this, but there is a test case for the ChangesBrowser that tests the selection. The problem is, that the test case selects an item by calling #selectedItem: and the behavior is different for when this is called by the view. The test case just selects the "change", whereas when this is called by the view, the selected item is TreeNodeModel (with #contents). And I can not fix #pickedChanges without breaking this test. Any Idea ? Best regards, Henrik From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org<mailto:pharo-dev-bounces@lists.pharo.org>] On Behalf Of Nicolai Hess Sent: Sunday, August 7, 2016 4:55 PM To: Pharo Development List <pharo-dev(a)lists.pharo.org<mailto:pharo-dev@lists.pharo.org>> Subject: [Pharo-dev] Spec TreeModel get selected items in order Hi, Is there a way to retrive the selected nodes of a TreeModel in the same order they are shown in the widget ? For example, open this tree model, and select item 5/4/3/1 |t| Transcript clear. t := TreeModel new. t beCheckList ; autoMultiSelection: true. t roots:((1 to:10) collect:[:c | TreeNodeModel new content:c;hasContentToShow:true]). t openWithSpec. t inspect . Now, if I try to collect the selected items with t selectedItems collect:#contents they appear in the order I selected them, but I would like to get the order 1/2/3/4/5 thanks Nicolai

Aug. 7, 2016