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

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

by Tudor Girba

> 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 > > 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] Spec TreeModel get selected items in order

by Nicolai Hess

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] GT-Spotter dive in shortcut

by Nicolai Hess

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 ? > > 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." > > > > > >

Aug. 7, 2016

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

by Nicolai Hess

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. > > > 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] [squeak-dev] Windows Time millisecondClockValue (system start vs. image start)

by Nicolai Hess

2016-08-07 17:18 GMT+02:00 Henrik Nergaard <henrik.nergaard(a)uia.no>: > Hmm. > > ActiveHand lastEvent â"[(798@340) mouseOver SHIFT nil nil]" > > ActiveHand instVarNamed: #lastEventBuffer "#(1 148008281 659 126 0 0 1 1)" > âTimestamp is there, second elementâ > > > > I cannot see that the stamp is ever 0 from a raw event polled, and I guess > that will (should) never happen? > > Ie; in HandMorph >> generateMouseEvent: line 15 âstamp = 0 ifTrue: [ stamp > := Time milisecondClockValue ]â is dead/wrong code? > > > > So I guess that somewhere along the event dispatching/processing (after he > event has been moved from the raw buffer into a MorphicEvent subclass > object) things are copied/translated without keeping the original timestamp > intact. > > I found at least two places that causes the timestamp to be lost: > > MouseEvent >> asMoueMove (sets a new timestamp using Time) > > MouseEvent >> asMouseOver > Yes, that is what I meant by generating mousemove/mouseover events. For example, if you put Transcript show:{ evt type. evt timeStamp . firstClickTime} ;cr. at top of method handleEvent:from: and click (just click no movement) on the title pane of a system window, you'll see a alot of #(#mouseMove 9128631 12518171) Transcript entries The entries look like they are new events, but I think they are just generated from the last real event , but with a new time stamp. > > > I think there are two bugs here > > 1) VM clock can differ from Image clock > > 2) Translating one event from another do not keep the original > timestamp > > > > Best regards, > > Henrik > > > > > > *From:* squeak-dev-bounces(a)lists.squeakfoundation.org [mailto: > squeak-dev-bounces(a)lists.squeakfoundation.org] *On Behalf Of *Nicolai Hess > *Sent:* Sunday, August 7, 2016 3:57 PM > *To:* Pharo Development List <pharo-dev(a)lists.pharo.org>; The > general-purpose Squeak developers list <squeak-dev@lists. > squeakfoundation.org> > *Subject:* [squeak-dev] Windows Time millisecondClockValue (system start > vs. image start) > > > > Hi, > > a call to > > Time millisecondClockValue > > gives the current milliseconds since the image started. Did this change ? > > I have a windows squeak 4.4 VM where it gave the uptime of the system (on > windows). > > Background: > > HandMorph generates some MouseOver and/or MouseMove events, and if the > > timeStamp value is not set, it sets it to Time millisecondClockValue, but > the "real" events have > > a time stamp of "milliseconds since system was booted". > > > So, now it can happen that you have a real event (mouse click) at > timeStamp (msecs since boot up) > 3000000 > > and afterwards a generated mouseOver event with a time stamp since image > startup > > 2000000 (if the image started ~15 min after system boot). > > That is, a later event as a lower time stamp. This will disturb the event > handling in > > HandMorph>>#handleEvent: from: > > Somehow, (after having the image running for a long time ? I don't know). > The time stamp > > for the generated events is allways much bigger than for the system > events, and this > > will make it impossible to detect double-click events. > > see issue > https://pharo.fogbugz.com/f/cases/18859 > > and > http://stackoverflow.com/questions/38700587/double- > click-highlight-selection-in-pharo-5-0 > > > > thanks > > nicolai > > > >

Aug. 7, 2016

Re: [Pharo-dev] when Cmd-P can just display a string in the debugger

by Tudor Girba

Hi, > On Aug 7, 2016, at 5:48 PM, Ben Coman <btc(a)openinworld.com> wrote: > > On Sun, Aug 7, 2016 at 9:16 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> Hi Stef, >> >> We had a thread on that two months ago, and it is still waiting for your answer. I made concrete proposals on which bindings can work. It would be more constructive to focus on those details (see more below). >> >> First, one thing should get clarified. The case in which someone wants to print and persist inline the result is an edge case. For example, it happens when you want to write tests to document how the code is working currently. The typical case for using print-it is to get a sneak peak of what the object is and in this case, the requirement is specifically to not change the current code (especially when you are debugging you do not want to get the code dirty). >> >> That is why we made the default printing not affect the text editor, and this feature is around since almost 2 years and, except of you, there was no other complain. >> >> But, to come back to the concrete solution, as I mentioned before, I do agree that what you mention should be a supported use case. The only question is how to do it. So, letâs focus on that please. >> >> One solution would be to have a different first level keybinding directly in the text editor, but that would not be a good idea because that space is already overloaded with too many key bindings, and this becomes a problem especially when you place an editor inside a larger tool (like a debugger) and you run out of available key bindings for other actions. >> >> So, the proposals I had was like this: >> >> Cmd+p ==> the print-it popup >> - Enter ==> add as a comment >> - Shift+Enter ==> add as plain text >> - Cmd+v ==> add as plain text (this would not affect the text that was copied to clipboard) >> >> Another option would be to change the meaning of the current Enter: >> >> Cmd+p ==> the print-it popup >> - Enter ==> add as a plain text >> - Shift+Enter ==> add as comment > > Doing a CMD key then SHIFT key is a bit of a contortion. > What about... > Cmd+p ==> the print-it popup, then... > - Cmd+p ==> add as a plain text (fingers don't have to move, most > efficient for old behaviour) > - Enter ==> add as comment (existing behaviour) I am fine with that. And I think we can still anyway add Cmd+v to âpasteâ in place the plain text. Does anyone see a problem with this solution? Cheers, Doru > cheers -ben > >> >> >> What do you think? >> >> Cheers, >> Doru >> >> >>> On Aug 7, 2016, at 9:39 AM, stepharo <stepharo(a)free.fr> wrote: >>> >>> Hi >>> >>> Seriously I do not get why printing in the debugger cannot just print the text without putting these ^%&*^*&()**(&%^*( double quote around. >>> >>> Why do we change such basic functionality and in particular we do not propose ANY alternative. >>> >>> If you need a pop up and do not care of manipulating text this is ok but WHY the default behavior has to be changed. >>> >>> I hate so much that the GTTool ALWAYS want to IMPOSE a flow. Your &^%*^(& flow is not mine. >>> >>> Should I go and hack to get back the default behavior. WHY do I have to do that? >>> >>> Seriously. >>> >>> Especially since the solution was super simple: introduce a new binding living nicely close to PrintIt >>> >>> but no "we have to change the default one with something that may fuck your flow but who cares because >>> >>> my flow is better." >>> >>> Why do we get systematically this message? Why such changes are damaging TDD practices without any notices? >>> >>> May be I should use another Smalltalk at the end. >>> >>> Stef >>> >>> >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "Presenting is storytelling." -- www.tudorgirba.com www.feenk.com "Obvious things are difficult to teach."

Aug. 7, 2016

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

by Henrik Nergaard

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' -------------------------------------- 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] when Cmd-P can just display a string in the debugger

by Ben Coman

On Sun, Aug 7, 2016 at 9:16 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi Stef, > > We had a thread on that two months ago, and it is still waiting for your answer. I made concrete proposals on which bindings can work. It would be more constructive to focus on those details (see more below). > > First, one thing should get clarified. The case in which someone wants to print and persist inline the result is an edge case. For example, it happens when you want to write tests to document how the code is working currently. The typical case for using print-it is to get a sneak peak of what the object is and in this case, the requirement is specifically to not change the current code (especially when you are debugging you do not want to get the code dirty). > > That is why we made the default printing not affect the text editor, and this feature is around since almost 2 years and, except of you, there was no other complain. > > But, to come back to the concrete solution, as I mentioned before, I do agree that what you mention should be a supported use case. The only question is how to do it. So, letâs focus on that please. > > One solution would be to have a different first level keybinding directly in the text editor, but that would not be a good idea because that space is already overloaded with too many key bindings, and this becomes a problem especially when you place an editor inside a larger tool (like a debugger) and you run out of available key bindings for other actions. > > So, the proposals I had was like this: > > Cmd+p ==> the print-it popup > - Enter ==> add as a comment > - Shift+Enter ==> add as plain text > - Cmd+v ==> add as plain text (this would not affect the text that was copied to clipboard) > > Another option would be to change the meaning of the current Enter: > > Cmd+p ==> the print-it popup > - Enter ==> add as a plain text > - Shift+Enter ==> add as comment Doing a CMD key then SHIFT key is a bit of a contortion. What about... Cmd+p ==> the print-it popup, then... - Cmd+p ==> add as a plain text (fingers don't have to move, most efficient for old behaviour) - Enter ==> add as comment (existing behaviour) cheers -ben > > > What do you think? > > Cheers, > Doru > > >> On Aug 7, 2016, at 9:39 AM, stepharo <stepharo(a)free.fr> wrote: >> >> Hi >> >> Seriously I do not get why printing in the debugger cannot just print the text without putting these ^%&*^*&()**(&%^*( double quote around. >> >> Why do we change such basic functionality and in particular we do not propose ANY alternative. >> >> If you need a pop up and do not care of manipulating text this is ok but WHY the default behavior has to be changed. >> >> I hate so much that the GTTool ALWAYS want to IMPOSE a flow. Your &^%*^(& flow is not mine. >> >> Should I go and hack to get back the default behavior. WHY do I have to do that? >> >> Seriously. >> >> Especially since the solution was super simple: introduce a new binding living nicely close to PrintIt >> >> but no "we have to change the default one with something that may fuck your flow but who cares because >> >> my flow is better." >> >> Why do we get systematically this message? Why such changes are damaging TDD practices without any notices? >> >> May be I should use another Smalltalk at the end. >> >> Stef >> >> > > -- > www.tudorgirba.com > www.feenk.com > > "Presenting is storytelling." > >

Aug. 7, 2016

Re: [Pharo-dev] Looking for preferences to move the debugger buttons

by Peter Uhnak

On Sun, Aug 07, 2016 at 09:42:07AM +0200, stepharo wrote: > Hi > > I'm FEDUP to have to go up to click on buttons in the debugger. > > I know that some of you have a preferences to fix this problem (yes doru > nicely explain that we do not understand anything > > and this is part of design but I do not care of design I care about my > efficiency - as if Apple wuld not break their design rules in any version of > iTunes). > > And I would like to use such preferences. I am not sure if this is what you are looking for, but I have a startup script that changes the shortcuts to be (on Linux) always ctrl+shift+<first letter of the command> (And it underlines the letter too.) https://github.com/peteruhnak/pharo-scripts/blob/master/config/5.0/uniformD… (original thread: http://forum.world.st/GTDebugger-shortcuts-usability-td4890316.html ) Peter

Aug. 7, 2016

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

by Peter Uhnak

On Sun, Aug 07, 2016 at 04:55:05PM +0200, Nicolai Hess wrote: > 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 I vaguely remember that I had this problem long time ago and what I ended up doing was to filter against the original collection. E.g. something like this t := TreeModel new. t beCheckList; autoMultiSelection: true. d := 1 to: 10. t roots: d. t openWithSpec. sel := (t selectedItems collect: #content). d select: [ :each | sel includes: each ] Also looking at the code it seems that TreeModel is really heavily tied to Morphic... so maybe not so simple to fix without rewrite. Peter

Aug. 7, 2016