- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Serialization of font object

by StÃ©phane Ducasse

may be using the storeOn: aStream and readFrom: mechanism? On Apr 23, 2010, at 4:28 PM, Henrik Johansen wrote: > On Apr 23, 2010, at 4:01 48PM, nullPointer wrote: > >> >> >> Regards >> >> I see in Pharo a few ways for create a font, StrikeFont, LogicalFont... I >> need generate dinamically code in Smalltalk for build UIs, and my problem >> now is when I have serialize the font of a widget. Which could be the best >> way for do that? In other objects like arrays, points, associations is >> possible get that calling #printString method. Exists some equivalence for >> that in fonts, or is needed implement that mechanism of zero? >> >> Thanks for answers > > I would store the the name/boldness/size etc., then use (LogicalFont familyName: pointSize: stretchValue:weightValue: slantValue: ) realFont > to discover the closest font available when loading the morph into an image again. > > Cheers, > Henry > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 23, 2010

Re: [Pharo-project] Fwd: [squeak-dev] Fix to OCompletion for Pharo 1.1

by StÃ©phane Ducasse

Pay attention FillInTheBlank does not exist anymore in 1.1 Stef On Apr 23, 2010, at 1:40 PM, Mariano Martinez Peck wrote: > > > ---------- Forwarded message ---------- > From: DeNigris Sean <sean(a)clipperadams.com> > Date: Fri, Apr 23, 2010 at 6:01 AM > Subject: [squeak-dev] Fix to OCompletion for Pharo 1.1 > To: squeak-dev(a)lists.squeakfoundation.org > > > My email to Romain Robbes (with the address on squeaksource) was returned. Can someone pass this along... > > OCompletionTable class >> initializeWithPackages > Changed FillInTheBlank to FillInTheBlankMorph. > (The former has no request: initialAnswer:). > > Thanks. > Sean > > > > > > > <OCompletionTable class-initializeWithPackages.st>_______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 23, 2010

Re: [Pharo-project] [squeak-dev] Re: ToolBuilder / Squeak 4.1 changes

by Chris Muller

>> - PluggableAlternateMultiSelectionListSpec >> This class was added as an 'alternative' multi-selection list (used only by MessageTrace; perhaps Chris can comment) > > I do not understand what it means from a spec perspective to have an alternate spec. > Don't we simply want a > Â Â Â Â PluggableMultiSelectionListSpec with a property that changes it behavior? > Hi, the PluggableAlternateMultiSelectionListSpec is a move toward a more windows-like operation of a multi-select list. The standard PluggableMultiSelectionListSpec does not allow rapid swipes of ranges, nor does it allow using the Shift modifier to do range-selection. Alternate does. The only reason Alternate has not yet completely replaced the legacy in Squeak is because we have not yet found a way to allow Control+selection to not bring up the halos. Ha! I wonder if, in Pharo, it would actually work because doesn't Pharo pretty much hide the halos now? Currently, Alternate is only used for one tool in Squeak (MessageTrace) and that tool does not exist in Pharo. So, probably you could omit it, but I would suggest, if possible, to at least consider omitting the *other* legacy one, PluggableMultiSelectionListSpec, because I hope that it will be replaced by Alternate someday (and renamed to take its place). Whichever is easier.. - Chris >> - PluggableCodePaneSpec >> This class was added to distinguish code-editing panes from others. It implies syntax highlighting any other goodies you'd like to see in code. >> >> - PluggableListSpec >> Â * doubleClick - selector to handle double click events >> Â * keystrokePreview - selector to handle key events for filtering >> >> - PluggableTextSpec >> Â * askBeforeDiscardingEdits - whether to ask before discarding changes >> >> - PluggableWindowSpec >> Â * isDialog - if the window should behave like a dialog >> >> - UIManager: >> Â * chooseFont:for:setSelector:getSelector: - font selector dialog >> Â * confirm:label: - confirm dialog w/ both message text and label >> Â * request:initialAnswer:centerAt: - positioned #request: message >> >> All of these changes are pretty straightforward and should not cause much of an issue. >> >> Package: ToolBuilder-Morphic >> ---------------------------- >> - ListChooser >> This class was added to implement the chooser dialog in Morphic. >> >> - PluggableDialogWindow >> This class was added for dialog windows in Cobalt. >> >> - PluggableTextMorphPlus: >> Â * styler - PTMPlus has been extended to support Shout directly. >> >> - MorphicUIManager: >> Â * chooseFont: - usage of FontChooser >> Â * chooseFrom: - usage of ListChooser >> Â * confirm: - usage of UserDialogBoxMorph >> Â * informUserDuring: - usage of SystemProgressMorph >> >> There is obviously more of an issue here. Various classes have only emerged in Squeak 4.1 and won't exist in Pharo. Not sure what to do here, because it's as much of an issue between 3.x and 4.1. >> >> I'll review the Pharo changes next. >> >> Cheers, >> Â - Andreas >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > >

April 23, 2010

Re: [Pharo-project] Behavior of Rectangle

by Chris Muller

I noticed this too when developing a system whose coordinates are not laid out the same as a computer screen. My solution was to change my coordinate translation of the domain to conform to a computer-screen. :-( Another limitation of Rectangles that isn't obvious is that they are coded to assume their coordinates are all integral. I had been confounded by a bug that ended up being that, when I asked for the #center of a Rectangle with Float coordinates, i.e.: 50.1234(a)50.9876 corner: 41.1234(a)41.9876 you get a truncated answer that is completely outside the original rectangle! On Thu, Apr 22, 2010 at 2:55 PM, Alexandre Bergel <alexandre(a)bergel.eu> wrote: > Dear List, > > I spend quite some time in tracking down a bug in Mondrian. I found it. The > source of it stems from the following behavior in Pharo: > -=-=-=-=-=-= > (0@0 corner: 10@10) containsPoint: 5@5. Â => true > (10@10 corner: 0@0) containsPoint: 5@5. Â => false > -=-=-=-=-=-= > > I find the latter a bit surprising. VW returns false as well. I would expect > the second expression to return true. > There is also "(10@0 corner: 0@10) containsPoint: 5@5. => false" > > I looked in the Pharo mailing list archive, and apparently this hasn't been > discussed yet. > > The class Rectangle is central. Modifying it (either by making "(10@10 > corner: 0@0) containsPoint: 5@5" returns true or not permitting a rectangle > "(10@10 corner: 0@0)" to be valid) may have some serious impact. > > What do you think? > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel Â http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 23, 2010

[Pharo-project] [update 1.1] #11320

by StÃ©phane Ducasse

11320 ----- - Issue 2295: AllocationTests - Issue 2346: ArrayTest>>testSorted is broken - Issue 2318: Smalltalk windowSystemName - Issue 2302: optional version identification primitives from Squeak Stef

April 23, 2010

[Pharo-project] Finding all uses of a pragma in the image (was Fix 2329 - Default MC Directory Setting)

by Sean P. DeNigris

Alain Plantec-4 wrote: > > I was looking for a SystemNavigator>> allMethodsUsingPragma: aSymbol, or >> something like that. With that funtionality, I guess it really wouldn't >> matter where they were located - or am I missing an easy way to find >> these >> methods? > simply all senders of #worldMenu (or #systemsettings) > Oh, so simple! I was thinking of pragmas as 'this whole other concept to get.' After I read your reply, I rechecked Pharo By Example, which said "Each pragma is in effect a static message send with literal arguments," so it makes perfect sense to treat them like any other method, but I still wouldn't have thought of it. Sean -- View this message in context: http://forum.world.st/Fix-2329-Default-MC-Directory-Setting-tp2019559p20623… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

April 23, 2010

Re: [Pharo-project] Serialization of font object

by Henrik Johansen

On Apr 23, 2010, at 4:01 48PM, nullPointer wrote: > > > Regards > > I see in Pharo a few ways for create a font, StrikeFont, LogicalFont... I > need generate dinamically code in Smalltalk for build UIs, and my problem > now is when I have serialize the font of a widget. Which could be the best > way for do that? In other objects like arrays, points, associations is > possible get that calling #printString method. Exists some equivalence for > that in fonts, or is needed implement that mechanism of zero? > > Thanks for answers I would store the the name/boldness/size etc., then use (LogicalFont familyName: pointSize: stretchValue:weightValue: slantValue: ) realFont to discover the closest font available when loading the morph into an image again. Cheers, Henry

April 23, 2010

Re: [Pharo-project] [squeak-dev] Fix to OCompletion for Pharo 1.1

by Romain Robbes

Sean, Thanks for the fix! (and Mariano for forwarding the mail! I fixed my squeaksource address). I'm wondering though, if in the long term re-introducing a reference to the specific Morph class is a good idea. So I made a similar fix, using "UIManager default" instead of FillInTheBlank. The fix is in oCompletion version 58 on squeaksource. Romain On Apr 23, 2010, at 7:40 AM, Mariano Martinez Peck wrote: > > > ---------- Forwarded message ---------- > From: DeNigris Sean <sean(a)clipperadams.com> > Date: Fri, Apr 23, 2010 at 6:01 AM > Subject: [squeak-dev] Fix to OCompletion for Pharo 1.1 > To: squeak-dev(a)lists.squeakfoundation.org > > > My email to Romain Robbes (with the address on squeaksource) was returned. Can someone pass this along... > > OCompletionTable class >> initializeWithPackages > Changed FillInTheBlank to FillInTheBlankMorph. > (The former has no request: initialAnswer:). > > Thanks. > Sean > > > > > > > <OCompletionTable class-initializeWithPackages.st> -- Romain Robbes http://romain.robb.es rrobbes(a)dcc.uchile.cl

April 23, 2010

Re: [Pharo-project] Fix 2329 - Default MC Directory Setting

by Alain Plantec

Sean P. DeNigris a Ã©crit Hi Sean, Thanks a lot for your setting extension! > I was looking for a SystemNavigator >> allMethodsUsingPragma: aSymbol, or > something like that. With that funtionality, I guess it really wouldn't > matter where they were located - or am I missing an easy way to find these > methods? > simply all senders of #worldMenu (or #systemsettings) Alain > Sean >

April 23, 2010

[Pharo-project] Serialization of font object

by nullPointer

Regards I see in Pharo a few ways for create a font, StrikeFont, LogicalFont... I need generate dinamically code in Smalltalk for build UIs, and my problem now is when I have serialize the font of a widget. Which could be the best way for do that? In other objects like arrays, points, associations is possible get that calling #printString method. Exists some equivalence for that in fonts, or is needed implement that mechanism of zero? Thanks for answers -- View this message in context: http://forum.world.st/Serialization-of-font-object-tp2062241p2062241.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

April 23, 2010