- Pharo-dev - lists.pharo.org

[Pharo-project] Preference to settings refactoring: #annotationPanes case
by Alain Plantec May 13, 2009

May 13, 2009

http://code.google.com/p/pharo/issues/detail?id=810 Alain ---------------------------------------------- annotationPanes : "if true, a thin horizontal pane is used in browsers" We have 3 implementations : Old browser and MC implementation in Pharo-core and OB one in Pharo-dev. Pharo-core Old browser implementation: It first relies on the #annotation related methods. (changed: #annotation, Browser>>annotation, ChangeList>>annotation, CodeHolder>>annotation). CodeHolder>>wantsAnnotationPane is the only user of the annotationPanes preference. CodeHolder>>addOptionalAnnotationsTo: window at: fractions plus: verticalOffset is the only user of wantsAnnotationPane. It has two senders: Browser>>openAsMorphMessageEditing: and CodeHolder>>addLowerPanesTo: window at: nominalFractions with: editString. method source with #annotation gives more interesting results such as: CodeHolder>>refreshAnnotation "If the receiver has an annotation pane that does not bear unaccepted edits, refresh it" (aPane := self dependents detect: [:m | (m inheritsFromAnyIn: #('PluggableTextView' 'PluggableTextMorph' )) and: [m getTextSelector == #annotation]] ifNone: []) ifNotNil: [:aPane | aPane hasUnacceptedEdits ifFalse: [aPane update: #annotation]] other "cool" pieces of code: PluggableTextMorph>>accept .... ok := self acceptTextInModel. ok == true ifTrue: [self setText: self getText. self hasUnacceptedEdits: false. (model dependents detect: [:dep | (dep isKindOf: PluggableTextMorph) and: [dep getTextSelector == #annotation]] ifNone: []) ifNotNilDo: [:aPane | model changed: #annotation]]. ... PluggableTextMorph>>cancel self setText: self getText. self setSelection: self getSelection. getTextSelector == #annotation ifFalse: [(aPane := model dependents detect: [:dep | (dep isKindOf: PluggableTextMorph) and: [dep getTextSelector == #annotation]] ifNone: []) ifNotNil: [:aPane | model changed: #annotation]] The displayed annotation is set only when a browser or message list is opened. Then, displayed information concerns only the method on which the browser is opened or only the method FROM which sender/implementor message list is opened. The annotation is never updated even a new method is selected. Pharo-core MC implementation: MCSnapshotBrowser, MCPatchBrowser, MCMergeBrowser: display (well) annotation when a method is selected. The method author initials, the date and the time of change and the category are displayed. Note that the height of the pane is sometime too thin, depending on the height of the font. When a vertical scrollbar is shown, the pane is always too thin. The implementation relies on #annotations and #annotations: methods. #annotations implementations MCCodeTool>>annotations (subclassresponsibility) ok MCConflict>>annotations ok MCPatchBrowser>>annotations ok MCSnapshotBrowser>>annotations ok MCDefinition>>annotations and MCPatchOperation>>annotations make use of Preferences class>>defaultAnnotationRequests. Preferences class>>defaultAnnotationRequests ^ Parameters at: #MethodAnnotations ifAbsent: [self setDefaultAnnotationInfo "Preferences annotationInfo"] #annotations: implementations MCDefinition>>annotations: and MCPatchOperation>>annotations: are the same MCDefinition>>annotations: requests "Answer a string for an annotation pane, trying to fulfill the annotation requests. These might include anything that Preferences defaultAnnotationRequests might return. Which includes anything in Preferences annotationInfo To edit these, use:" "Preferences editAnnotations" ^ String streamContents: [:s | self printAnnotations: requests on: s] MCSnapshotBrowser>>annotations: stuff self changed: #annotations The displayed data is given by Preferences annotationInfo which is supposed to be adaptable with the help of a specific tool opened with Preferences editAnnotations. The annotation is well updated each time a new method is selected. I didn't succeed in making Preferences editAnnotations work. Found the implementation clean except the Preferences annotationInfo/editAnnotations part. Pharo-dev OB implementation Relies on a OBAnnotationPanel for the view and on the OBSelectionChanged announcement for the annotation update. It works well. The implementation is simple and clean (The only bad point I've found is that, as for the Pharo-core MC implementation, the height of the panel is fixed whereas it should be dynamically computed from current code font height) action: Would remove the annotationPanes preference from pharo-core and make an OBBrowser specific setting. Why: because old browser implementation is really confusing and dirty and because it do not give useful feedback to the user. Would also remove MC implementation because it is not used by default and I think that MC user do not care about it. If people want to keep it, then it should not relies on a specific setting. Anyway, the Preferences annotationInfo/editAnnotations part should be removed. Consequence: Clean/remove all annotation related code from Pharo-core. Ask OB maintainers to add an OB specific settings as follow: OBCodeBrowser class>>showAnnotationPanel <setting> ^ ShowAnnotationPanel ifNil: [ShowAnnotationPanel := (SettingManager newSetting: 'Show annotation panel') default: true; parent: #obBrowsing; description: 'If true, a thin horizontal panel is used in browsers. The annotation panel is used to display useful informations about the selected method'] I will propose a .cs for the cleaning of Pharo-core when I will know what to do with MC implementation (keep, remove, ok to keep with cleaning?). Then I will propose a .cs to OB maintainers for Pharo-dev. Alain -------------------------------------

1 0

[Pharo-project] Bug in FTPClient
by Nicolas Cellier May 13, 2009

May 13, 2009

There are two bugs in this code: lookForCode: code ifDifferent: handleBlock "We are expecting a certain numeric code next. However, in the FTP protocol, multiple lines are allowed. If the response is multi-line, the fourth character of the first line is a $- and the last line repeats the numeric code but the code is followed by a space. So it's possible that there are more lines left of the last response that we need to throw away. We use peekForAll: so that we don't discard the next response that is not a continuation line." | headToDiscard | "check for multi-line response" (self lastResponse size > 3 and: [(self lastResponse at: 4) = $-]) ifTrue: ["Discard continuation lines." [headToDiscard _ self lastResponse first: 4. [[self stream peekForAll: headToDiscard] whileTrue: [self stream nextLine]] on: Exception do: [:ex | ^handleBlock value: nil]]]. ^ super lookForCode: code ifDifferent: handleBlock 1) it attempts to catch Exception, which is generally a bad idea. Error would be more appropriated. 2) but the whole ifTrue: conditions is a no-op: it simply creates a block that is not used. Maybe intention was: ifTrue: ["Discard continuation lines." headToDiscard := self lastResponse first: 4. [[self stream peekForAll: headToDiscard] whileTrue: [self stream nextLine]] on: Exception do: [:ex | ^handleBlock value: nil]]. Is this code used?

1 0

[Pharo-project] how do I change fonts?
by Jon Hancock May 13, 2009

May 13, 2009

I'm playing with pharo, web09.04.1 image. Looks good, but would be _much_ better if I could use my OS X fonts. Last year while tweaking squeak, with quite a bit of effort I was able to get some decent fonts. I need not only a better, cleaner fixed width font, but I require everything in the UI to be larger as I have pretty bad eyesight. Any ideas? thanks, Jon

2 1

Re: [Pharo-project] RBNamespace does not like Trait ?
by FranÃ§ois Tanguy May 12, 2009

May 12, 2009

Hello, it is okay, I can deal without it. My use case is the following: - extension of Fame to support Traits - use the fame code generator to add behavior to generated classes Because Fame is using RB to generate code, I was expecting that RB was handling Traits. But no matter, I add Trait in a second pass myself. Cheers FranÃ§ois >> Hi, >> >> In general, RB does not know about Traits too much. They are treated >> like classes, which >> works most of the time. >> >> There has been work done for Traits support (and Traits related >> refactorings). But >> this has not yet been integrated. >> >> Marcus On 11.05.2009, at 07:52, Fran?ois Tanguy wrote: > Hello, > > no class is created when sending defineClass: message to an > RBNamespace instance with the following class string definition > > Object subclass: #SCElement > uses: {TPrintable} > instanceVariableNames: '' > classVariableNames: '' > poolDictionaries: '' > category: #'SC' > > Having a quick look to the implementation, RBNamespace does not like > Trait... > > Francois

1 0

[Pharo-project] Capturing window events
by Alexandre Bergel May 12, 2009

May 12, 2009

Dear All, Is there an easy way to capture windows related events such as resizing and hiding ? I do not have the feeling this is supported currently. One way to implement this I guess, is to redefine the method SystemWindow>>extent: to emit an instance of a subclass of Announcement, which could be named MorphicWindowResize. I plan to do this for Mondrian, but maybe this is of an interest to GUI guys. Any comment before I proceed? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

3 4

[Pharo-project] windowsesque theme
by Steve Wirts May 12, 2009

May 12, 2009

I've attached a rough draft of a windowsesque UITheme called UIThemeXP, I was hoping it could be added to the themes in the main distribution. It may need to be renamed, and certainly put into the proper package. After you filein, evaluate.... UIThemeXP setup. then to see some examples of it, evaluate UITheme exampleBasicControls The "UIThemeXP<<setup" function assumes you are on a windows machine as it requires Tahoma font be installed. Otherwise you can just set it as the preferred look and feel, and it will use the standard Accuny font. It would be nice if the FreeType fonts could be somehow persisted inside methods like images so they would be available on other platforms.

4 6

[Pharo-project] RBNamespace does not like Trait ?
by FranÃ§ois Tanguy May 12, 2009

May 12, 2009

Hello, no class is created when sending defineClass: message to an RBNamespace instance with the following class string definition Object subclass: #SCElement uses: {TPrintable} instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: #'SC' Having a quick look to the implementation, RBNamespace does not like Trait... Francois

2 1

[Pharo-project] Preference to settings refactoring: alternativeBrowseIt case
by Alain Plantec May 12, 2009

May 12, 2009

http://code.google.com/p/pharo/issues/detail?id=808 Alain

2 2

May 12, 2009

UIManager default informUserDuring: [:bar | #(one two three) do: [ :info | bar value: info. (Delay forSeconds: 1)]] leads to an error. Apparently barValue does not like to be a symbol. Stef

2 2

[Pharo-project] windowsesque theme
by Torsten Bergmann May 12, 2009

May 12, 2009

>Any name would be great though, as without a Theme like this I would >never be able to use Pharo at my job. Nice we now have a Win95/2000 look and a vistary look. Maybe your company is upgrading to XP to make pharo even more complete ;) Bye T. -- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss fÃ¼r nur 17,95 Euro/mtl.!* http://dslspecial.gmx.de/freedsl-surfflat/?ac=OM.AD.PD003K11308T4569a

1 0