- Pharo-dev - lists.pharo.org

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

Re: [Pharo-dev] [squeak-dev] Windows Time millisecondClockValue (system start vs. image start)

by Henrik Nergaard

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 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@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(a)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-selectio… thanks nicolai

Aug. 7, 2016

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

by Alexandre Bergel

Often the reason of annoyance is either time consuming or simply complicated to detail. Anyway, personally, I am not really perturbed by the button location. The print-it in the debugger is no more an annoyance when the Cmd-c bidding can simply copy the print-it. It is exactly what I wish to do most of the time. What seriously bother me, is the instability of Athens, which cannot be fixed. And the highly-suboptimal Git integration. These are what may make me move away from Pharo. Alexandre > On Aug 7, 2016, at 10:10 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi Dale, > > Thanks for your thoughts. And thanks for giving these new quirks time to settle :). > > Actually, I am looking for what is annoying and I specifically interested in the reasons why it is annoying. Please feel free to report the bits that annoy you. > > Cheers, > Doru > > > >> On Aug 7, 2016, at 3:57 PM, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> wrote: >> >> >> >> On 8/7/16 6:16 AM, Tudor Girba wrote: >>> Hi Stef, >>> >>> >>> 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. >>> >> I believe that this is a logical fallacy ... many developers are too busy actually trying to do work with these tools and don't have time or inclination to get involved in an argument :) >> >> There are a number of odd, awkward, hidden, "old way does not work anymore" things that I am running into as I have just been using Pharo5.0 for a couple of months ... I understand that when the GUI changes one must give it a little bit of time to "settle in" and see if my annoyance is due to the fact that things have changed or if the "old way was better" ... >> >> I don't like the funky popup prints either --- they often obscure the underlying text and when I do something to see the underlying text I lose the printout --- occasionally it is useful as a preview but that's not the only use case .. often the result is what I want ... >> >> But I am trying to do real work and I really don't have the time to get into an embroiled argument over things so far I feel less productive (the debugger buttons are a real annoyance) but perhaps with practice and patience I will eventually see the light of putting heavily used menu items off in a corner ... >> >> BTW, I've basically given up on using browser shortcuts altogether ... I am assuming that the shortcuts will be changing yet again in 6.0 so I'm not going to try to memorize shortcuts that will be changing every 6 months :) >> >> While I am complaining --- is there a way to be able to change the width of the inspector panes in a debugger? I'm almost never able to see what I want to see in the inspector panes because they aren't wide enough and unlike every other pane in the universe, I can't grab the pane and change its width ... I'm sure you have a good argument for why it can't be moved --- but that doesn't stop me from being annoyed ... >> >> Optimized code is often uglier than the cleanly crafted beautiful code that runs too damn slow ... >> >> I could go on and on, but I'm sure you've good reasons for all of the the things that you have changed and this isn't the only GUI in the world that is annoying to use :) >> >> Remember that I am still in the phase of "give it a little bit of time to "settle in" and see if my annoyance is due to the fact that things have changed or if the "old way was better" ... " >> >> Dale >> >> > > -- > www.tudorgirba.com > www.feenk.com > > "Being happy is a matter of choice." > > > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Aug. 7, 2016

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

by webwarrior

stepharo wrote > ... > > 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. > > ... Does that mean that Bloc will only work in separate window until Morphic is fully replaced and removed from the image? That would take many years I guess. And before that, all tools like debugger etc. will open themselves in host (Morphic) window? -- View this message in context: http://forum.world.st/Bloc-Bloc-2-and-Brick-tp4909112p4909861.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Aug. 7, 2016