March 2009 - Pharo-dev - lists.pharo.org

[Pharo-project] just for fun... extensibility of Morphic

by StÃ©phane Ducasse

awesome if you want to add a new handle .... guess what you have to edit this method :) Morph>>balloonHelpTextForHandle: aHandle "Answer a string providing balloon help for the given halo handle" | itsSelector | itsSelector := aHandle eventHandler firstMouseSelector. itsSelector == #doRecolor:with: ifTrue: [^ 'Change color']. itsSelector == #mouseDownInDimissHandle:with: ifTrue: [^ Preferences preserveTrash ifTrue: ['Move to trash'] ifFalse: ['Remove from screen']]. #(#(#addFullHandles 'More halo handles') #(#addSimpleHandles 'Fewer halo handles') #(#chooseEmphasisOrAlignment 'Emphasis & alignment') #(#chooseFont 'Change font') #(#chooseNewGraphicFromHalo 'Choose a new graphic') #(#chooseStyle 'Change style') #(#dismiss 'Remove') #(#doDebug:with: 'Debug') #(#doDirection:with: 'Choose forward direction') #(#doDup:with: 'Duplicate') #(#doMenu:with: 'Menu') #(#doGrab:with: 'Pick up') #(#editDrawing 'Repaint') #(#makeNewDrawingWithin 'Paint new object') #(#mouseDownInCollapseHandle:with: 'Collapse') #(#mouseDownOnHelpHandle: 'Help') #(#prepareToTrackCenterOfRotation:with: 'Move object or set center of rotation') #(#presentViewMenu 'Present the Viewing menu') #(#startDrag:with: 'Move') #(#startGrow:with: 'Change size') #(#startRot:with: 'Rotate') #(#startScale:with: 'Change scale')#(#trackCenterOfRotation:with: 'Set center of rotation') ) do: [:pair | itsSelector == pair first ifTrue: [^ pair last]]. ^ 'unknown halo handle'translated

March 19, 2009

[Pharo-project] Composing UI layout question

by astares＠gmx.de

>parent width & height (or any other parent coordinate) depends on >its submorph's fixed width/height. Ahh, should have read your mail more carefully. You are not only interested in a flexible alignment within the parent - but also to depend on own child bounds/parameters. The new JavaFX provides something like this by using the "bind" keyword. See http://weblogs.java.net/blog/aim/archive/2009/01/layout_primer_f.html in section "Using Binding to Layout Nodes" Bye T. -- Psssst! Schon vom neuen GMX MultiMessenger gehÃ¶rt? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01

March 19, 2009

Re: [Pharo-project] Composing UI layout question

by Schwab,Wilhelm K

Sig, I have used two systems that solve this problem: WindowBuilder and Dolphin's ViewComposer. Dolphin's approach is far the more familiar to me, and is based on a hierarchy of layout manager objects. IIRC, the layout manager idea was inspired by Java (just giving credit where it is due, and perhaps offering a clue to documentation??). Parent views each have a layout manager; the particular class one chooses sets the algorithm (proportional is quick and easy, FramingLayout is a little tricky but very flexible) used to position chlid views, and also imposes requirements on the aspects of the child views. The latter is an alert that aspects of the children must be altered (in general they need to be replaced with objects of suitable type to meet the needs of the manager) any time the parent layout manager type is changed, and suitable values must be created and assigned to a newly added child. The view composer uses a Published Aspects Inspector (PAI) to allow the user to see and change all of the above. The PAI is very similar to Pharo's explorer, embedded in the VC of course. Bill --- Wilhelm K. Schwab, Ph.D. bschwab AT anest DOT ufl DOT edu -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko Sent: Thursday, March 19, 2009 5:10 AM To: The general-purpose Squeak developers list; Pharo Development Subject: [Pharo-project] Composing UI layout question Hi folks, suppose you having a visual UI editing tool, where you can place morphs/controls and define their position(s). I have a model in mind, where coordinates can be defined by formal description, i.e. morph left: morph parent left + some offset morph width: morph parent width / 2 etc. but i wonder, in what way such relations can be represented by UI editor/design tool. I want that user could easily specify following: suppose i placing a button in form, and say that its corner (bottom/right) should be aligned to its parent corner, with some negative offset (-5 @ -5). And button width/height should be calculated by taking a button label text width & height. So, user by specifying two ordinates - corner and width & height, is fully describing a button visual layout. The problem is that button's label is submorph, and i not sure how to formally encode such relation i.e. parent width & height (or any other parent coordinate) depends on its submorph's fixed width/height. -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 19, 2009

Re: [Pharo-project] Fwd: [ANN] 10254

by Adrian Lienhard

Probably this was an override by Polymorph, and removing an overridden method in one package, as far as I know, reverts it to the method version provided by the other package. Overrides should be avoided, they just cause troubles. Adrian On Mar 19, 2009, at 13:46 , Henrik Johansen wrote: > I know, which is why I thought it was strange, the .cs contained: > !BorderedMorph removeSelector: #areasRemainingToFill:! > which when I file it in, results in no areasRemainingToFill: method > for > BorderedMorph in the image. > > I really have no idea how the update process makes it revert to an > older > version instead, nor how one would go about fixing it... :/ > > Cheers, > Henrik > > StÃ©phane Ducasse wrote: >> >> >> henrik I just integrated the file you gave me. >> If you have a new version that fixes the problem I will do a new >> version. >> >> Stef >> >> On Mar 19, 2009, at 12:20 PM, Henrik Johansen wrote: >> >>> It seems BorderedMorph's areasRemainingToFill: method got reverted >>> to >>> the version in use prior to the override by PolyMorph (which has now >>> been promoted to Morph), instead of removed completely. >>> (This is the state my image is in after updating a released 248, at >>> least) >>> >>> Cheers, >>> Henry >>> >>> StÃ©phane Ducasse wrote: >>>> Issue 655: Overlapping Graphics on World do not Properly Repaint >>>> Issue 658: Preferences resetHaloSpecifications >>>> Issue 664: unimplemented errorCantGoBack >>>> Closed 665 >>>> >>>> now we will focus on the closures. >>>> >>>> Stef >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>>> >>>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 19, 2009

[Pharo-project] Composing UI layout question

by astares＠gmx.de

Hi Igor, I like the fraction/offset model from SmalltalkMT. I once ported it to Squeak. This gives you full control on absolute and relative positioning within the bounds of the parent and controls resizing behavior. Only 4 parameters for anything you need ... Example: self addMorph: startButton to: pane offset: #(0 0 101 20) fractions: #(0 0 0 0). means the button starts top left at x1=0, y1=0 with the bottom right corner at x2=101 and y2=20. There is no fraction given - so we have absolute positioning. If you give a fraction you tell the system that for instance a subpane should always start at 30% from the side of a parents box. -> relative positions with resizing. If you additionally give an offset you can define that there is an additional absolute margin after the 30%. With a negative offset you can absolute position the control/submorph on the other side of the 30% virtual line. With fractions: #(0 0 1 1 ) which means 100% the control will fill the parent and will fully resize with it. Smalltalk MT used 1000 for 100% of the parents area, but thats only a definition. Have a look at the project "Sandcastle" on Squeaksource, especially Sandcastle-tbn.9.mcz. SCApplicationWindow (a subclass of SystemWindow here) provides a few methods to support this dynamic layout and its subclass SCWelcomeWindow shows how you can use it. Hope this helps Bye T. -- Aufgepasst: Sind Ihre Daten beim Online-Banking auch optimal geschÃ¼tzt? Jetzt absichern: https://homebanking.gmx.net/?mc=mail@footer.hb

March 19, 2009

[Pharo-project] [update] #10255

by Marcus Denker

Issue 662: more general beep Issue 659: Convenience Methods on Pragma and Additional Tests Issue 666: Removes ScriptLoader>>buildPharoDev Issue 665: Adds missing Trait>>withAllSubclasses -- Marcus Denker -- denker(a)acm.org http://2denker.de

March 19, 2009

Re: [Pharo-project] Fwd: [ANN] 10254

by Henrik Johansen

I know, which is why I thought it was strange, the .cs contained: !BorderedMorph removeSelector: #areasRemainingToFill:! which when I file it in, results in no areasRemainingToFill: method for BorderedMorph in the image. I really have no idea how the update process makes it revert to an older version instead, nor how one would go about fixing it... :/ Cheers, Henrik StÃ©phane Ducasse wrote: > > > henrik I just integrated the file you gave me. > If you have a new version that fixes the problem I will do a new version. > > Stef > > On Mar 19, 2009, at 12:20 PM, Henrik Johansen wrote: > >> It seems BorderedMorph's areasRemainingToFill: method got reverted to >> the version in use prior to the override by PolyMorph (which has now >> been promoted to Morph), instead of removed completely. >> (This is the state my image is in after updating a released 248, at >> least) >> >> Cheers, >> Henry >> >> StÃ©phane Ducasse wrote: >>> Issue 655: Overlapping Graphics on World do not Properly Repaint >>> Issue 658: Preferences resetHaloSpecifications >>> Issue 664: unimplemented errorCantGoBack >>> Closed 665 >>> >>> now we will focus on the closures. >>> >>> Stef >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > ------------------------------------------------------------------------ > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 19, 2009

Re: [Pharo-project] Fwd: [ANN] 10254

by StÃ©phane Ducasse

henrik I just integrated the file you gave me. If you have a new version that fixes the problem I will do a new version. Stef On Mar 19, 2009, at 12:20 PM, Henrik Johansen wrote: > It seems BorderedMorph's areasRemainingToFill: method got reverted to > the version in use prior to the override by PolyMorph (which has now > been promoted to Morph), instead of removed completely. > (This is the state my image is in after updating a released 248, at > least) > > Cheers, > Henry > > StÃ©phane Ducasse wrote: >> Issue 655: Overlapping Graphics on World do not Properly Repaint >> Issue 658: Preferences resetHaloSpecifications >> Issue 664: unimplemented errorCantGoBack >> Closed 665 >> >> now we will focus on the closures. >> >> Stef >> >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 19, 2009

Re: [Pharo-project] Fwd: [ANN] 10254

by Henrik Johansen

It seems BorderedMorph's areasRemainingToFill: method got reverted to the version in use prior to the override by PolyMorph (which has now been promoted to Morph), instead of removed completely. (This is the state my image is in after updating a released 248, at least) Cheers, Henry StÃ©phane Ducasse wrote: > Issue 655: Overlapping Graphics on World do not Properly Repaint > Issue 658: Preferences resetHaloSpecifications > Issue 664: unimplemented errorCantGoBack > Closed 665 > > now we will focus on the closures. > > Stef > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > >

March 19, 2009

[Pharo-project] http://goran.krampe.se/blog/Squeak/Tirade.rdoc

by StÃ©phane Ducasse

http://goran.krampe.se/blog/Squeak/Tirade.rdoc In my revived work on Deltastreams in Squeak I ended up facing the choice of native file format for Deltas. Matthew has made an advanced format calledInterleavedChangeset which manages to squeeze a binary representation of a Delta into a Changeset file (which is in Smalltalk chunk format). An impressive feat, and it has the advantage of being backwards compatible in the sense that a Delta in this format can be filed in as a plain old Changeset into an old Squeak image. .....

March 19, 2009