July 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] feedup of selecting doit or typing " above and below expressions in comments?

by StÃ©phane Ducasse

cool On Jul 6, 2010, at 10:54 PM, Lukas Renggli wrote: >>> Another thing that is related to the above and to the different browsers: >>> >>> In Core: When I select a method I can choose "Senders of..." >>> and "Implementors of..." to either search for senders/implementors >>> of the selected method AND the messages sent into the selected >>> method. >>> >>> In Pharo: with OB I can just do "senders" and "implementors" >>> which looks for the senders/implementors of the selected method >>> One is NOT able to search for senders/implementors of >>> the messages sent within the selected method. >>> Here I have to select the entire selector which is >>> time consuming as described above. >> >> enter a bug entry. > > This was removed on request of Stef and I completely agree on this: > for me it is time consuming to be forced to search for the selector in > a sorted list when the selector is written/selected right in front of > me. > >>> So Pharo with OB is (compared to core) really a step backwards here. >> >> I imagine that the enh I did also to get Cmd-M on class name browsing the class and Cmd-B on >> selectors do an implementors should also be pushed in OB. > > The Cmd-B was always part of OB, I've done the same for Cmd-M. Also I > updated the edit pane menu to match the one of the standard browser. > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 6, 2010

Re: [Pharo-project] Markup Builder in Smalltalk

by Lukas Renggli

>>I may perhaps be unaware of the XML/SGML builder generation from Seaside, love to be pointed out to.., The Html generation of >>Seaside uses explicit construct of classes ( WA**Tags) to do so.. Builders in dynamic manner >> use doesNotUnderstand: construct to generate the stream.. > > While it may seem desirable to have an API that uses #doesNotUnderstand: (or its equivalent in other languages) to facilitate markup generation by accepting arbitrary messages and taking them to be the names of tags, this approach is not a good idea for at least two reasons: 1) namespace prefixes cannot be specified in this way, as ":" is not a legal character within identifiers in Smalltalk (or in most other languages, for that matter), and 2) unary messages intended to be treated as tag names can collide with already-defined unary messages in the writer class or its superclasses. 3) The approach with #doesNotUnderstand: absolutely doesn't scale. Tools break in subtle ways (editors, debuggers, program checkers). Debugging is a pain. And it is slow. We've had that in Seaside up to version 2.6. Lukas -- Lukas Renggli www.lukas-renggli.ch

July 6, 2010

Re: [Pharo-project] Issue 2635 - methods recategorization

by Pavel Krivanek

code: SystemNavigation organization renameCategory: '*multilingual-editor' toBe: '*Multilingual-Encodings'. Project class organization classify: #spawnNewProcessIfThisIsUI: under: '*Morphic'. Project class organization removeCategory:'squeaklet on server'. ImmX11 organization classify: #keyboardFocusForAMorph: under: '*Morphic'. FileStream class organization classify: #fileReaderServicesForFile:suffix: under: '*Tools-FileList'. FileStream class organization classify: #serviceFileIn under: '*Tools-FileList'. FileStream class organization classify: #serviceRemoveLineFeeds under: '*Tools-FileList'. FileStream class organization classify: #services under: '*Tools-FileList'. Character organization classify: #macRomanToUnicode under: '*Multilingual-TextConversion'. Character organization classify: #unicodeToMacRoman under: '*Multilingual-TextConversion'. TranscriptStream organization classify: #codePaneMenu:shifted: under: '*Tools-Base'. TranscriptStream class organization classify: #openMorphicTranscript under: '*Morphic'. description: SystemNavigation organization renameCategory: '*multilingual-editor' toBe: '*Multilingual-Encodings'. - move the single method allSelect: to a base Multilingual package Project class organization classify: #spawnNewProcessIfThisIsUI: under: '*Morphic'. Project class organization removeCategory:'squeaklet on server'. - UI specific and sent only from Morphic dependent methods ImmX11 organization classify: #keyboardFocusForAMorph: under: '*Morphic'. - used only for Morphic FileStream class organization classify: #fileReaderServicesForFile:suffix: under: '*Tools-FileList'. FileStream class organization classify: #serviceFileIn under: '*Tools-FileList'. FileStream class organization classify: #serviceRemoveLineFeeds under: '*Tools-FileList'. FileStream class organization classify: #services under: '*Tools-FileList'. - FileList files associations. However a deeper refactoring is welcome. Character organization classify: #macRomanToUnicode under: '*Multilingual-TextConversion'. Character organization classify: #unicodeToMacRoman under: '*Multilingual-TextConversion'. - both packages in the PharoKernel. Move to a more fitting package. TranscriptStream organization classify: #codePaneMenu:shifted: under: '*Tools-Base'. TranscriptStream class organization classify: #openMorphicTranscript under: '*Morphic'.

July 6, 2010

Re: [Pharo-project] Markup Builder in Smalltalk

by jaayer

---- On Tue, 06 Jul 2010 02:37:38 -0700 Sudhakar Krishnamachari wrote ---- >I may perhaps be unaware of the XML/SGML builder generation from Seaside, love to be pointed out to.., The Html generation of >Seaside uses explicit construct of classes ( WA**Tags) to do so.. Builders in dynamic manner > use doesNotUnderstand: construct to generate the stream.. While it may seem desirable to have an API that uses #doesNotUnderstand: (or its equivalent in other languages) to facilitate markup generation by accepting arbitrary messages and taking them to be the names of tags, this approach is not a good idea for at least two reasons: 1) namespace prefixes cannot be specified in this way, as ":" is not a legal character within identifiers in Smalltalk (or in most other languages, for that matter), and 2) unary messages intended to be treated as tag names can collide with already-defined unary messages in the writer class or its superclasses.

July 6, 2010

Re: [Pharo-project] Issue 2635 - methods recategorization

by Pavel Krivanek

On Tue, Jul 6, 2010 at 11:05 PM, Michael Roberts <mike(a)mjr104.co.uk> wrote: >>> 2) e.g you move somethings to *Tools and some things to *Tools-Explorer >>> is that not going to create the same problem that happened to System, >>> with both parent and child packages defined in the same image? >> >> There's only one MC package named Tools and this package is not >> splitted. But we may make future split of this package easier if we >> will use a category name Tools-Base (or more fitting one) instead of >> Tools. >> > > ok fair enough. but if i look in #12038 there appear a few cases: > Graphics-Stef.256 > Graphics-* > > Multilingual-Markus.2 > Multilingual-* At least the Multilingual package is automatically registered because of one method in the Character class and the fix is already mentioned in this thread. However I have no idea why MC registers automatically the Graphics package Cheers, -- Pavel > > this needs fixing before applying more recategorisation? > > > thanks, > Mike > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 6, 2010

Re: [Pharo-project] Issue 2635 - methods recategorization

by Michael Roberts

>> 2) e.g you move somethings to *Tools and some things to *Tools-Explorer >> is that not going to create the same problem that happened to System, >> with both parent and child packages defined in the same image? > > There's only one MC package named Tools and this package is not > splitted. But we may make future split of this package easier if we > will use a category name Tools-Base (or more fitting one) instead of > Tools. > ok fair enough. but if i look in #12038 there appear a few cases: Graphics-Stef.256 Graphics-* Multilingual-Markus.2 Multilingual-* this needs fixing before applying more recategorisation? thanks, Mike

July 6, 2010

Re: [Pharo-project] Markup Builder in Smalltalk (XMLWriter)

by jaayer

---- On Tue, 06 Jul 2010 03:19:48 -0700 Torsten Bergmann wrote ---- >Just check "XMLWriter-tbn.5" which can be found in "http://squeaksource.com/PharoGoodies/" > >------------------------------------------------------ >|writer| >writer := XMLTagWriter xml. >writer comment: 'A new xml file'. >writer tag: 'package' with: [ >Â Â Â Â writer cData: 'name' with: 'XMLWriter'. >]. >writer contents > >returns > > > > > > >------------------------------------------------------ > >You can also access the stream (writer stream). >Indenting is not yet working fully but at least >it should give you idea. Check out the test cases for >more. > >I once saw such an XMLWriter written by Ernest Micklei >in VAST (credits for the idea) and rebuilt it in Pharo. > >Bye >T. >-- >GMX DSL: Internet-, Telefon- und Handy-Flat ab 19,99 EUR/mtl. >Bis zu 150 EUR Startguthaben inklusive! http://portal.gmx.net/de/go/dsl > >_______________________________________________ >Pharo-project mailing list >Pharo-project(a)lists.gforge.inria.fr >http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > The next version of XMLSupport will feature an XMLWriter with an API similar to XMLTagWriter. I had decided a few weeks that any API using explicit start/end methods was unsmalltalk-like and should be replaced with one based on execute-around methods, though I was unaware of XMLTagWriter and instead modeled the API loosely on Seaside's HTML generation. You now send XMLWriter messages that create markup-writing objects for the parts of a document. These objects can then be configured using messages like #attributeAt:put: and written to the document explicitly with a serialization message (which typically accepts content) or implicitly by creating another markup writer after it. The new API looks like this: | writer | ((writer := XMLWriter new) enablePrettyPrinting; xmlDeclaration; tag: 'foo') xmlnsAt: 'foo' put: 'http://foo'; attributeAt: 'a' put: 'one'; attributeAt: 'b' put: 'two'; content: [ writer tag: 'bar' content: [ (writer string: 'test'; tag: 'baz'; tag: 'foobar') content: 'test']] which produces: <?xml version="1.0" encoding="UTF-8"?> <foo xmlns:foo="http://foo" a="one" b="two"> <bar>test<baz /> <foobar>test</foobar> </bar> </foo>

July 6, 2010

Re: [Pharo-project] Morph rendering with antialiasing

by Henrik Sperre Johansen

On 06.07.2010 22:28, Denis Kudriashov wrote: > Hello. > > Is somebody implement morphs rendering with antialiasing? > Maybe it is already possible? > > In practice I need circle button. But without antialiasing it seems > really ugly. > > If there is no existed solution. How do you think It can be implemented? > > I know that fonts rendered with antialiasing. How its approach can be > applyed for morphs? > > I notice browser buttons (senders, implementors..) has rounded > corners. And its nice rendered. What secrete? Can it be done for any > morph corner rounding Using shape rendering primitives, no. Balloon does AA, though you'll have problems with small thin lines (which is why smaller sized TTFonts doesn't exactly look stellar). The "secret" method used by both fonts and browser buttons is to instead display AA'd bitmaps (ie. you use the alpha channel), instead of rendering shapes. Cheers, Henry

July 6, 2010

Re: [Pharo-project] feedup of selecting doit or typing " above and below expressions in comments?

by Lukas Renggli

>> Another thing that is related to the above and to the different browsers: >> >> In Core: When I select a method I can choose "Senders of..." >> Â Â Â Â and "Implementors of..." to either search for senders/implementors >> Â Â Â Â of the selected method AND the messages sent into the selected >> Â Â Â Â method. >> >> In Pharo: with OB I can just do "senders" and "implementors" >> Â Â Â Â Â which looks for the senders/implementors of the selected method >> Â Â Â Â Â One is NOT able to search for senders/implementors of >> Â Â Â Â Â the messages sent within the selected method. >> Â Â Â Â Â Here I have to select the entire selector which is >> Â Â Â Â Â time consuming as described above. > > enter a bug entry. This was removed on request of Stef and I completely agree on this: for me it is time consuming to be forced to search for the selector in a sorted list when the selector is written/selected right in front of me. >> So Pharo with OB is (compared to core) really a step backwards here. > > I imagine that the enh I did also to get Cmd-M on class name browsing the class and Cmd-B on > selectors do an implementors should also be pushed in OB. The Cmd-B was always part of OB, I've done the same for Cmd-M. Also I updated the edit pane menu to match the one of the standard browser. Lukas -- Lukas Renggli www.lukas-renggli.ch

July 6, 2010

Re: [Pharo-project] Issue 2635 - methods recategorization

by Pavel Krivanek

code: MethodReference organization moveCategory: '*Kernel-Traits' to: '*Traits-Kernel'. LRUCache organization moveCategory: '*Polymorph-Widgets-override' to: 'accessing'. Project class organization moveCategory: 'utilities' to: '*Morphic'. Character organization moveCategory: '*Multilingual' to: '*Multilingual-Encodings'. TranscriptStream organization moveCategory: 'toolbuilder' to: '*ToolBuilder-Kernel'. TranscriptStream class organization moveCategory: 'toolbuilder' to: '*ToolBuilder-Kernel'. description: MethodReference organization moveCategory: '*Kernel-Traits' to: '*Traits-Kernel'. - swap package name parts to a more logical ownership. It contains only a method actualClass that has no other kernel implementation. Both packages will be in the kernel image. LRUCache organization moveCategory: '*Polymorph-Widgets-override' to: 'accessing'. - only one method. Declared as override but has no old version in the history and has general functionality Project class organization moveCategory: 'utilities' to: '*Morphic'. - all methods have no real senders or are called only from Morphic Character organization moveCategory: '*Multilingual' to: '*Multilingual-Encodings'. - only fix MC package name TranscriptStream organization moveCategory: 'toolbuilder' to: '*ToolBuilder-Kernel'. - single method buildWith:, used only for the Toolbuilder TranscriptStream class organization moveCategory: 'toolbuilder' to: '*ToolBuilder-Kernel'. - the same

July 6, 2010