January 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] splitters in table layout

by Tudor Girba

Yes, you missed a changeset Gary sent in the aligning morphs thread (he actually sent two, and you should pick the second one). Cheers, Doru On 18 Jan 2011, at 20:50, Andreas Wacknitz wrote: > Hi, > > Am 18.01.11 12:27, schrieb Gary Chambers: >> | m leftMorph scroll | >> m := PanelMorph new. >> m >> hResizing: #shrinkWrap; >> vResizing: #spaceFill; >> changeTableLayout; >> listDirection: #leftToRight. >> m addMorphBack: (leftMorph := Morph new >> color: Color red; >> minimumExtent: 150@10; >> extent: 150@10; >> hResizing: #rigid; "shown for clarity, is the default" >> vResizing: #spaceFill). >> m addMorphBack: (EdgeGripMorph new >> width: ProportionalSplitterMorph splitterWidth; >> hResizing: #rigid; "not the default this time, vResizing is also >> #spaceFill by default" >> target: leftMorph). >> m addMorphBack: (Morph new >> color: Color green; >> minWidth: 100; >> hResizing: #shrinkWrap; >> vResizing: #spaceFill). >> >> scroll := GeneralScrollPane new >> changeScrollerTableLayout; > In my Pharo-1.1 and 1.2 images > GeneralScrollPane>>changeScrollerTableLayout is not available. > Did I miss something? > > Regards, > Andreas > > -- www.tudorgirba.com "Every thing should have the right to be different."

Jan. 18, 2011

Re: [Pharo-project] Unsubscribing for Announcements

by Tudor Girba

Who defended what status quo? The WeakAnnouncement are already on the agenda for 1.3. Cheers, Doru On 18 Jan 2011, at 20:40, Schwab,Wilhelm K wrote: > Of course. But when the status quo has been robustly defended, it seems reasonable to lobby for change as a start. > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] > Sent: Tuesday, January 18, 2011 2:22 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Unsubscribing for Announcements > > Yes but having good weakstructure will not arrive by accident. > > > On Jan 17, 2011, at 4:34 PM, Schwab,Wilhelm K wrote: > >> Two comments: >> >> (1) there needs to be a way to unregister interest; >> (2) the registrations need to be weak so that (1) is largely optional. >> >> If Dolphin has a weakness, it is that failure of an MVP triad to open can leave the system in a confused state. Morphic appears to be a little more robust about that, though in fairness, I do not push Pharo's GUI nearly as hard as I have Dolphin's. If in doubt, some type of #ifCurtailed: or similar protection around the assembly of a complex morph might be a good idea. >> >> >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Sean P. DeNigris [sean(a)clipperadams.com] >> Sent: Monday, January 17, 2011 1:18 AM >> To: pharo-project(a)lists.gforge.inria.fr >> Subject: [Pharo-project] Unsubscribing for Announcements >> >> I really like Announcements! It's so much easier to update complex GUIs when >> you can pass state :) >> >> I hit one glitch when unsubscribing... The CollaborActive book suggests >> unsubscribing in #delete. For complex UIs, this doesn't seem to work >> because #delete is only called for the one morph that was deleted, not for >> its submorphs (which may need to unsubscribe). >> >> I tried this: >> MyMorph>>delete >> super delete. "Must come first. Deleting a submorph before self = >> emergency evaluator" >> aSubmorphThatNeedsToUnsubscribe delete. >> >> SubmorphMentionedAbove>>delete >> self inventory announcer unsubscribe: self. >> super delete. >> >> >> But it seems like a lot of work and coupling. Is there no hook that is >> guaranteed to be called when a morph is going away - i.e. it or a morph in >> the owner chain is being deleted? >> >> Thanks. >> Sean >> -- >> View this message in context: http://forum.world.st/Unsubscribing-for-Announcements-tp3220751p3220751.html >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> >> > > > -- www.tudorgirba.com "Every thing has its own flow."

Jan. 18, 2011

Re: [Pharo-project] Unsubscribing for Announcements

by Tudor Girba

Who defended what status quo? The WeakAnnouncement are already on the agenda for 1.3. Cheers, Doru On 18 Jan 2011, at 20:40, Schwab,Wilhelm K wrote: > Of course. But when the status quo has been robustly defended, it seems reasonable to lobby for change as a start. > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] > Sent: Tuesday, January 18, 2011 2:22 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Unsubscribing for Announcements > > Yes but having good weakstructure will not arrive by accident. > > > On Jan 17, 2011, at 4:34 PM, Schwab,Wilhelm K wrote: > >> Two comments: >> >> (1) there needs to be a way to unregister interest; >> (2) the registrations need to be weak so that (1) is largely optional. >> >> If Dolphin has a weakness, it is that failure of an MVP triad to open can leave the system in a confused state. Morphic appears to be a little more robust about that, though in fairness, I do not push Pharo's GUI nearly as hard as I have Dolphin's. If in doubt, some type of #ifCurtailed: or similar protection around the assembly of a complex morph might be a good idea. >> >> >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Sean P. DeNigris [sean(a)clipperadams.com] >> Sent: Monday, January 17, 2011 1:18 AM >> To: pharo-project(a)lists.gforge.inria.fr >> Subject: [Pharo-project] Unsubscribing for Announcements >> >> I really like Announcements! It's so much easier to update complex GUIs when >> you can pass state :) >> >> I hit one glitch when unsubscribing... The CollaborActive book suggests >> unsubscribing in #delete. For complex UIs, this doesn't seem to work >> because #delete is only called for the one morph that was deleted, not for >> its submorphs (which may need to unsubscribe). >> >> I tried this: >> MyMorph>>delete >> super delete. "Must come first. Deleting a submorph before self = >> emergency evaluator" >> aSubmorphThatNeedsToUnsubscribe delete. >> >> SubmorphMentionedAbove>>delete >> self inventory announcer unsubscribe: self. >> super delete. >> >> >> But it seems like a lot of work and coupling. Is there no hook that is >> guaranteed to be called when a morph is going away - i.e. it or a morph in >> the owner chain is being deleted? >> >> Thanks. >> Sean >> -- >> View this message in context: http://forum.world.st/Unsubscribing-for-Announcements-tp3220751p3220751.html >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> >> > > > -- www.tudorgirba.com "Every thing has its own flow."

Jan. 18, 2011

Re: [Pharo-project] splitters in table layout

by Andreas Wacknitz

Hi, Am 18.01.11 12:27, schrieb Gary Chambers: > | m leftMorph scroll | > m := PanelMorph new. > m > hResizing: #shrinkWrap; > vResizing: #spaceFill; > changeTableLayout; > listDirection: #leftToRight. > m addMorphBack: (leftMorph := Morph new > color: Color red; > minimumExtent: 150@10; > extent: 150@10; > hResizing: #rigid; "shown for clarity, is the default" > vResizing: #spaceFill). > m addMorphBack: (EdgeGripMorph new > width: ProportionalSplitterMorph splitterWidth; > hResizing: #rigid; "not the default this time, vResizing is also > #spaceFill by default" > target: leftMorph). > m addMorphBack: (Morph new > color: Color green; > minWidth: 100; > hResizing: #shrinkWrap; > vResizing: #spaceFill). > > scroll := GeneralScrollPane new > changeScrollerTableLayout; In my Pharo-1.1 and 1.2 images GeneralScrollPane>>changeScrollerTableLayout is not available. Did I miss something? Regards, Andreas

Jan. 18, 2011

Re: [Pharo-project] aligning morphs

by Tudor Girba

Hi Gary, Did you publish the changes to GeneralScrollPane somewhere? Cheers, Doru On 17 Jan 2011, at 12:07, Gary Chambers wrote: > It seems you are asking for the scroll value before the layout has been calculated. > (since the window hasn't received a fullbounds yet). > > > | m scroll | > m := PanelMorph new. > m > hResizing: #shrinkWrap; > vResizing: #spaceFill; > changeTableLayout; > listDirection: #leftToRight. > m addMorphBack: (Morph new > minWidth: 100; > hResizing: #shrinkWrap; > vResizing: #spaceFill). > scroll := GeneralScrollPane new > changeScrollerTableLayout; > scrollTarget: m. > scroll openInWindow. > scroll hScrollbar setValue: 1.0. > m addMorphBack: (Morph new > minWidth: 100; > hResizing: #shrinkWrap; > vResizing: #spaceFill). > "Recalculate bounds now for this example... not generally needed for normal code!" > scroll fullBounds. > "****" > scroll hScrollbar value > > Is not normally an issue, as you can see from inspecting the scroller after being opened. > > Regards, Gary > > ----- Original Message ----- From: "Tudor Girba" <tudor.girba(a)gmail.com> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Sunday, January 16, 2011 10:56 AM > Subject: Re: [Pharo-project] aligning morphs > > > Hi Gary, > > I would like to implement a Finder-like behavior the GeneralScrollPane. For this, I would need a way to control the scrolling so that every time I add a new morph, the scroller scrolls (similar to ScrollBar>>animateValue:duration: from OB). > > The problem seems to be that the scrollbar value is not updated when I add a new morph. Take a look at the code below. The result of the horizontal scrollbar value at the end is 1.0, while it should be lower. Am I doing something wrong, or is this a problem? > > | m scroll | > m := PanelMorph new. > m > hResizing: #shrinkWrap; > vResizing: #spaceFill; > changeTableLayout; > listDirection: #leftToRight; > m addMorphBack: (Morph new > minWidth: 100; > hResizing: #shrinkWrap; > vResizing: #spaceFill). > scroll := GeneralScrollPane new > changeScrollerTableLayout; > scrollTarget: m. > scroll openInWindow. > scroll hScrollbar setValue: 1.0. > m addMorphBack: (Morph new > minWidth: 100; > hResizing: #shrinkWrap; > vResizing: #spaceFill). > scroll hScrollbar value > > ==> 1.0 > > Cheers, > Doru > > > > On 11 Jan 2011, at 15:17, Gary Chambers wrote: > >> A slight revision as this has highlighted an edge case in the original class >> as to when scrollbars are needed... >> >> Regards, Gary >> >> ----- Original Message ----- From: "Tudor Girba" <tudor.girba(a)gmail.com> >> To: <Pharo-project(a)lists.gforge.inria.fr> >> Sent: Tuesday, January 11, 2011 1:53 PM >> Subject: Re: [Pharo-project] aligning morphs >> >> >> Excellent! >> >> I tried the example and it works well. I will work with it in the following days. >> >> Cheers, >> Doru >> >> >> On 11 Jan 2011, at 14:39, Gary Chambers wrote: >> >>> Try the attached change set with the following example... >>> Let me know if any use and we'll get it integrated. >>> >>> |m| >>> m := PanelMorph new. >>> m >>> fillStyle: Color green; >>> hResizing: #spaceFill; >>> vResizing: #spaceFill; >>> changeTableLayout; >>> layoutInset: 8. >>> m addMorph: (Morph new >>> height: 160; >>> minWidth: 100; >>> hResizing: #spaceFill; >>> vResizing: #shrinkWrap). >>> GeneralScrollPane new >>> changeScrollerTableLayout; >>> scrollTarget: m; >>> openInWindow >>> >>> >>> Regards, Gary >>> >>> ----- Original Message ----- From: "Tudor Girba" <tudor.girba(a)gmail.com> >>> To: <Pharo-project(a)lists.gforge.inria.fr> >>> Sent: Monday, January 10, 2011 8:23 PM >>> Subject: Re: [Pharo-project] aligning morphs >>> >>> >>> Wow, that would be great! I cannot wait to test it. >>> >>> Cheers, >>> Doru >>> >>> >>> On 10 Jan 2011, at 16:50, Gary Chambers wrote: >>> >>>> I may get time later in the week to have a go with GeneralScrollPane to support the feature you desire... ;-) >>>> >>>> Regards, Gary >>>> >>>> ----- Original Message ----- From: "Tudor Girba" <tudor.girba(a)gmail.com> >>>> To: <Pharo-project(a)lists.gforge.inria.fr> >>>> Cc: <Pharo-project(a)lists.gforge.inria.fr> >>>> Sent: Monday, January 10, 2011 2:23 PM >>>> Subject: Re: [Pharo-project] aligning morphs >>>> >>>> >>>> Hi Gary, >>>> >>>> Thanks for the reply. >>>> >>>> So, what would be required for scrollbars to work with spaceFill? I would really need this feature, but I do not know how to go about it. >>>> >>>> Could you or anyone else provide some hints? Of course code would be even better. But at this moment hi ts would be helpful, too :) >>>> >>>> Cheers, >>>> Doru >>>> >>>> >>>> >>>> On Jan 10, 2011, at 13:04, "Gary Chambers" <gazzaguru2(a)btinternet.com> wrote: >>>> >>>>> Hi Doru, >>>>> >>>>> #spaceFill constraints are typically only used by table layouts. >>>>> ScrollPane is designed for fixed size contents, at present. >>>>> Might be nice to extend it to honour any #spaceFill of its single target morph. >>>>> This would simplify usage of scrollers quite a bit! >>>>> >>>>> Regards, Gary >>>>> >>>>> ----- Original Message ----- From: "Tudor Girba" <tudor.girba(a)gmail.com> >>>>> To: "Pharo-project(a)lists.gforge.inria.fr Development" <pharo-project(a)lists.gforge.inria.fr> >>>>> Sent: Saturday, January 08, 2011 1:22 AM >>>>> Subject: [Pharo-project] aligning morphs >>>>> >>>>> >>>>> >>>>> Hi, >>>>> >>>>> I would need help with understanding the magic behind alignment in Morphic. >>>>> >>>>> Take the example from below. Could anyone help me with what I should do to have the morph stretch all the way horizontally? >>>>> >>>>> | scroll window morph | >>>>> scroll := ScrollPane new. >>>>> scroll >>>>> fillStyle: (SolidFillStyle color: Color blue); >>>>> vResizing: #spaceFill; >>>>> hResizing: #spaceFill. >>>>> morph := PanelMorph new. >>>>> morph >>>>> fillStyle: (SolidFillStyle color: Color yellow); >>>>> changeTableLayout; >>>>> listDirection: #topToBottom; >>>>> vResizing: #shrinkWrap; >>>>> hResizing: #spaceFill; >>>>> layoutInset: 10. >>>>> morph addMorphBack: (SimpleButtonMorph new width: 200; height: 200). >>>>> scroll scroller addMorph: morph. >>>>> window := SystemWindow new. >>>>> window addMorph: scroll fullFrame: (LayoutFrame fractions: (0 @ 0 corner: 1 @ 1)). >>>>> window openInWorld >>>>> >>>>> >>>>> Cheers, >>>>> Doru >>>>> >>>>> >>>>> -- >>>>> www.tudorgirba.com >>>>> >>>>> "Every thing should have the right to be different." >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "Problem solving efficiency grows with the abstractness level of problem understanding." >>> >>> >>> >>> <GeneralScrollPaneLayout.1.cs> >> >> -- >> www.tudorgirba.com >> >> "Some battles are better lost than fought." >> >> >> >> <GeneralScrollPaneLayout.2.cs> > > -- > www.tudorgirba.com > > "In a world where everything is moving ever faster, > one might have better chances to win by moving slower." > > > > > -- www.tudorgirba.com "To lead is not to demand things, it is to make them happen."

Jan. 18, 2011

Re: [Pharo-project] Unsubscribing for Announcements

by Schwab,Wilhelm K

Of course. But when the status quo has been robustly defended, it seems reasonable to lobby for change as a start. ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] Sent: Tuesday, January 18, 2011 2:22 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Unsubscribing for Announcements Yes but having good weakstructure will not arrive by accident. On Jan 17, 2011, at 4:34 PM, Schwab,Wilhelm K wrote: > Two comments: > > (1) there needs to be a way to unregister interest; > (2) the registrations need to be weak so that (1) is largely optional. > > If Dolphin has a weakness, it is that failure of an MVP triad to open can leave the system in a confused state. Morphic appears to be a little more robust about that, though in fairness, I do not push Pharo's GUI nearly as hard as I have Dolphin's. If in doubt, some type of #ifCurtailed: or similar protection around the assembly of a complex morph might be a good idea. > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Sean P. DeNigris [sean(a)clipperadams.com] > Sent: Monday, January 17, 2011 1:18 AM > To: pharo-project(a)lists.gforge.inria.fr > Subject: [Pharo-project] Unsubscribing for Announcements > > I really like Announcements! It's so much easier to update complex GUIs when > you can pass state :) > > I hit one glitch when unsubscribing... The CollaborActive book suggests > unsubscribing in #delete. For complex UIs, this doesn't seem to work > because #delete is only called for the one morph that was deleted, not for > its submorphs (which may need to unsubscribe). > > I tried this: > MyMorph>>delete > super delete. "Must come first. Deleting a submorph before self = > emergency evaluator" > aSubmorphThatNeedsToUnsubscribe delete. > > SubmorphMentionedAbove>>delete > self inventory announcer unsubscribe: self. > super delete. > > > But it seems like a lot of work and coupling. Is there no hook that is > guaranteed to be called when a morph is going away - i.e. it or a morph in > the owner chain is being deleted? > > Thanks. > Sean > -- > View this message in context: http://forum.world.st/Unsubscribing-for-Announcements-tp3220751p3220751.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > >

Jan. 18, 2011

Re: [Pharo-project] list on he fly selection :)

by Tudor Girba

I am not sure where it should work, but I tried in Pharo 1.2 and it does not work. First, there is a "self self". Second, even if I fix this one, I still get a DNU for OnTheFlySelectionPluggableListMorph>>lastKeystrokes. Cheers, Doru On 18 Jan 2011, at 20:21, StÃ©phane Ducasse wrote: > close your eyes and imagine that you can just type as to get all the methods starting with as* > without extra shortcut whatever.... > same for classes, packages... of course. > > Stef > > On Jan 18, 2011, at 4:16 PM, Alexandre Bergel wrote: > >> Just tried. I could not immediately figure out what is the difference with the "Find Class" panel (pressing Cmd-f in OB)? >> >> Cheers, >> Alexandre >> >> >> On 18 Jan 2011, at 12:00, StÃ©phane Ducasse wrote: >> >>> Hi guys >>> >>> I'm sure that some of you will really like to type on that list and see it auto selectioning its elements.... >>> >>> Gofer it >>> squeaksource: 'DirtyExperiments'; >>> package: 'DirtyExperiments'; >>> load >>> >>> | test | >>> test := DummyTest on: (Smalltalk allClasses). >>> test openInWorld >>> >>> Of course I would love to have that for a lot of lists..... :) >>> >>> Thanks Benjamin for this first version :) >>> Stef >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> > > -- www.tudorgirba.com "Sometimes the best solution is not the best solution."

Jan. 18, 2011

Re: [Pharo-project] Surprising binary messages!

by StÃ©phane Ducasse

Yes man. Stef > You're right. It looks like I need to sleep more :-D > > Noury

Jan. 18, 2011

Re: [Pharo-project] Unsubscribing for Announcements

by StÃ©phane Ducasse

Yes but having good weakstructure will not arrive by accident. On Jan 17, 2011, at 4:34 PM, Schwab,Wilhelm K wrote: > Two comments: > > (1) there needs to be a way to unregister interest; > (2) the registrations need to be weak so that (1) is largely optional. > > If Dolphin has a weakness, it is that failure of an MVP triad to open can leave the system in a confused state. Morphic appears to be a little more robust about that, though in fairness, I do not push Pharo's GUI nearly as hard as I have Dolphin's. If in doubt, some type of #ifCurtailed: or similar protection around the assembly of a complex morph might be a good idea. > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Sean P. DeNigris [sean(a)clipperadams.com] > Sent: Monday, January 17, 2011 1:18 AM > To: pharo-project(a)lists.gforge.inria.fr > Subject: [Pharo-project] Unsubscribing for Announcements > > I really like Announcements! It's so much easier to update complex GUIs when > you can pass state :) > > I hit one glitch when unsubscribing... The CollaborActive book suggests > unsubscribing in #delete. For complex UIs, this doesn't seem to work > because #delete is only called for the one morph that was deleted, not for > its submorphs (which may need to unsubscribe). > > I tried this: > MyMorph>>delete > super delete. "Must come first. Deleting a submorph before self = > emergency evaluator" > aSubmorphThatNeedsToUnsubscribe delete. > > SubmorphMentionedAbove>>delete > self inventory announcer unsubscribe: self. > super delete. > > > But it seems like a lot of work and coupling. Is there no hook that is > guaranteed to be called when a morph is going away - i.e. it or a morph in > the owner chain is being deleted? > > Thanks. > Sean > -- > View this message in context: http://forum.world.st/Unsubscribing-for-Announcements-tp3220751p3220751.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > >

Jan. 18, 2011

Re: [Pharo-project] Xtreams-Xtras: hashing and HMAC

by Sven Van Caekenberghe

On 18 Jan 2011, at 19:57, mkobetic(a)gmail.com wrote: > "Sven Van Caekenberghe"<sven(a)beta9.be> wrote: >>> The code is in Xtreams-Xtras and Xtreams-XtrasTests (note that you'll have to load FFI!). I tested it on Pharo 1.2 beta with both cog vm and standard vm. There are few test failures with file terminals that don't seem to like to be closed twice. Should be an easy fix. >> >> Could it be that you forgot to check in #hashing: for read streams ? Or did I load the code while you were updating ? > > Ah, my bad, I misspelled the category on XTReadStream and so it was omitted. No problem. > I didn't find a way to browse a "package" in Pharo 1.2 so I'm struggling a bit to keep the categories in line. Hmm, click the 'Browse' button in either the Monticello Browser or the Repository Browser with the correct package selected ? But I guess you know that as well... > Thanks for the note, a new version of Xtras is on squeaksource. Works much better, down to 7 failures out of 785! The problem is the one I reported earlier: XTFileReadingWritingTest expecting a read stream to be aware of data written to a file after it was opened. This does not seem to work on Mac OS X. Sven

Jan. 18, 2011