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

[Pharo-project] pharo-2.0-tests Â» 32,win - Build # 246 - Failure!

by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr

July 20, 2012

Re: [Pharo-project] Customizing the Caret of a PluggableTextMorph

by Denis Kudriashov

Hello 2012/7/20 Fernando Olivero <fernando.olivero(a)usi.ch> > Hi Sean, you can take a look at Athens-PangoCairo (in squeaksource). > > Using NativeBoost, i'm using the Pango layout library [1], and the > Pango-Cairo binding [2], to avoid laying out text using the outdated > (and messy) stuff in the image. > > Check out the classes: ParagraphDescription & AthensPangoCairoParagraph. > > I'm using them as the basis for the TextShape,LabelShape, and > EditableTextShape in Shapes / Gaucho ( using TextEditor, > SingleLineEditor ). > > Maybe somebody can do the same for Morphic? use Pango to layout the > text, and code a new TextMorph on top of it? > How I can try your code? Do you have ready image to play with it? I am very interested with clean and simple alternative to morphic. I want it for Presenty framework. (But I really like morphic as live user interface environment) Best regards, Denis

July 20, 2012

Re: [Pharo-project] Customizing the Caret of a PluggableTextMorph

by phil＠highoctane.be

I wouldn't do that for basic morphs as it would make Cairo necessary and then make completely ununderstandable what happens for laying out text for someone who wants to understand it (which is an important aspect of an open smalltalk image). TextMorph>>onBlinkCursor leads you to Paragraph (of course since it deals with the display) onBlinkCursor "Blink the cursor" | para | para := self paragraph ifNil:[^nil]. Time millisecondClockValue < self blinkStart ifTrue:[ "don't blink yet" ^para showCaret: para focused. ]. para showCaret: para showCaret not. para caretRect ifNotNil:[:r| self invalidRect: r]. so, para>>focused if where to look (but it is only a variable change so, you'll need to track the usage) Phil 2012/7/20 Fernando Olivero <fernando.olivero(a)usi.ch> > Hi Sean, you can take a look at Athens-PangoCairo (in squeaksource). > > Using NativeBoost, i'm using the Pango layout library [1], and the > Pango-Cairo binding [2], to avoid laying out text using the outdated > (and messy) stuff in the image. > > Check out the classes: ParagraphDescription & AthensPangoCairoParagraph. > > I'm using them as the basis for the TextShape,LabelShape, and > EditableTextShape in Shapes / Gaucho ( using TextEditor, > SingleLineEditor ). > > Maybe somebody can do the same for Morphic? use Pango to layout the > text, and code a new TextMorph on top of it? > > Fernando > > [1] http://developer.gnome.org/pango/stable/pango-Layout-Objects.html > [2] http://developer.gnome.org/pango/stable/pango-Cairo-Rendering.html > On Wed, Jul 18, 2012 at 7:28 AM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: > > > > On Jul 16, 2012, at 9:38 PM, Sean P. DeNigris wrote: > > > >> For VimPharo, I want to have a different cursor depending on whether a > tool > >> is in insert or normal mode. > >> > >> I tried a handful of ways, but they all failed or worked > >> partially/inconsistently. Here's some of them: > >> * add the state to the paragraph, but the entire paragraph gets replaced > >> during the life of the tool, so the state gets lost > >> * add the state to the editor, but the situation is the same > >> * add the state to PluggableTextMorph, override and access it from > >> TextMorphForEditView>>updateFromParagraph. This was an extreme PITA and > got > >> me very acquainted with the emergency evaluator. It "worked", but only > after > >> using the arrows a bit. > >> > >> Does anyone have any idea where I might hook in? > >> > >> <rant>I find the whole text system very confusing. What the heck does a > >> paragraph know about insertion points?? A view has one paragraph object, > >> even if there are several paragraphs (as understood by the rest of > humanity > >> as a block of text with breaks between the adjoining ones. Editors and > >> Paragraphs are thrown out and replaced on a whim. I'm finding it very > hard > >> to understand and modify</rant> > > > > I got burned by that when I worked on my botanics envâ¦. > > it was terrible. > > > >> > >> Thanks, > >> Sean > >> > >> -- > >> View this message in context: > http://forum.world.st/Customizing-the-Caret-of-a-PluggableTextMorph-tp46402… > >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > >> > > > > > >

July 20, 2012

Re: [Pharo-project] Customizing the Caret of a PluggableTextMorph

by phil＠highoctane.be

Ah, the morass into which I am currently digging... Well, if we look at it for a while, it becomes a tad clearer. PluggableTextMorph is just a shell for a TextMorph. The TextMorph basically displays a Text (which can be styled with TextAttributes) When moving into edition, there is an editor known by the TextMorph but this is not an editor like I understood it, but rather a helper object that will come handy with TextMorph>>handleInteraction: interactionBlock Inside handleInteraction, there is that editor and paragraph and then a call to interaction blockValue. And the interactionBlock is containing a bunch of various things that delegate the real editing work to the editor. Like in aTextMorph>>handleInteraction: [editor mouseUp: evt] If you then look into the editor (mostly SmalltalkEditor right now in the image), you see a quite large method for that mouseUp: evt handling. And lots of other things. There should be a cleanup occuring in the Editor -> TextEditor -> SmalltalkEditor hierarchy. The TextEditor knows a bit too much and I am currently implementing a child of TextEditor to have a simple, clean editor that does only the basics for my purpose. Once I am please with it, it may become an interesting child of Editor (maybe the TextEditor itself, with TextEditor renamed to something else (for example, TextEditor has something with codeCompletionAround). TextEditor and friends do have a ton of class side methods with all the commands, keystrokes, and menu entries. Very important to grasp how that works. The TextMorph>>editorClass returns the editor class to use. Currently the SmalltalkEditor (yikes!) If gets taken in TextMorph>>installEditorToReplace: priorEditor, where we get editor := self editorClass forMorph: self. digging further, we get TextEditor>>forMorph: aMorph returning ^self basicNew initWithMorph: aMorph. and ... we'll get there! ... TextEditor>>initWithMorph: aMorph super initialize. morph := aMorph. self resetState. So, we now have both linked. That dance occurs everytime we get something occuring to the TextMorph. >>handleEvent: anEvent will do anEvent sendTo: self and then the usual: evt sendTo: anObject, which will handle the event with ^anObjject handleMouseUp, donw, ... That is where we get back to the self handleInteraction: evt which calls the [editor mouseUp: evt] through the TextMorph handleInteraction. An interesting bit occurs with the TextMorph>>yellowActivity; shiftKeyState for the menus (and the PragmaMenuBuilder and strings like 'smalltalkMenu' looking into SmallTalk editor for menu entries (Class side, yellowButtonMenu and shifted friend). That's it for editor, except we need to say a word on its lifecyle: It gets created and destroyed all the time: created with TextMorph>>hasFocus, going away with keyBoardFocusChange Then for Paragraph, just realize that Paragraphis something to be used like; Paragraph new compose: text "Coming from the TextMorph" style: textStyle copy "always copy these beasties" from: 1 in (0@0 extent: extX@extY); adjustRightX; ... So, the Paragraph is composing the text into an area, taking into account the styles that are in the text The TextStyle is the default style, it can be overriden by some TextAttribute. And that's where the TextMorph>>drawOn: aCanvas comes into play. if will invoke Canvas>>paragraph: which will draw the text. This will lead us to CharacterScanner and friends (CompositionScanner) and TextComposer depending on it. look for composeLineFrom: to: .... or composeAllLines. This will call Paragraph>>composeAll ^self multiComposeLinesFrom: firstCharIndex to: text size delta: 0 into: OrderedCollection new "Ah, there we will end up into" priorLines: Array new atY: container top. So, it may be interesting to see how Paragraph works, but paragraph has nothing to do with Editor. Paragraph renders the text if an editing change has to be shown display wise. But doesn't know about the Editor. TextMorph uses TextMorph>>updateFromParagraph and >>fit to do the stuff. In CharacterScanner you can find interesting display code: CharacterScanner>>basicScanCharactersFrom: startIndex to: stopIndex in: sourceString rightX: rightX stopConditions: stops "this one still a tad foggy to me" kern: kernDelta There is a primitive rendering a char down there. This is all for StrikeFont. I don't know how TrueType is supported but there are As you are doing Vim keystrokes, check TextMorph>>basicKeyStroke that does the same dance as the mouse events but invokes self handleInteraction: [editor keystroke evt] self updateFromParagraph. super keystroke: evt. So, hope this makes it all a bit clearer. All of the PluggableTextMorph story builds upon all of the above to ensure a scrolling window and widget pluggability. Which I do not care at this point since I am designing a specific UI for a game. Phil 2012/7/18 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > > On Jul 16, 2012, at 9:38 PM, Sean P. DeNigris wrote: > > > For VimPharo, I want to have a different cursor depending on whether a > tool > > is in insert or normal mode. > > > > I tried a handful of ways, but they all failed or worked > > partially/inconsistently. Here's some of them: > > * add the state to the paragraph, but the entire paragraph gets replaced > > during the life of the tool, so the state gets lost > > * add the state to the editor, but the situation is the same > > * add the state to PluggableTextMorph, override and access it from > > TextMorphForEditView>>updateFromParagraph. This was an extreme PITA and > got > > me very acquainted with the emergency evaluator. It "worked", but only > after > > using the arrows a bit. > > > > Does anyone have any idea where I might hook in? > > > > <rant>I find the whole text system very confusing. What the heck does a > > paragraph know about insertion points?? A view has one paragraph object, > > even if there are several paragraphs (as understood by the rest of > humanity > > as a block of text with breaks between the adjoining ones. Editors and > > Paragraphs are thrown out and replaced on a whim. I'm finding it very > hard > > to understand and modify</rant> > > I got burned by that when I worked on my botanics envâ¦. > it was terrible. > > > > > Thanks, > > Sean > > > > -- > > View this message in context: > http://forum.world.st/Customizing-the-Caret-of-a-PluggableTextMorph-tp46402… > > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > > > >

July 20, 2012

Re: [Pharo-project] Customizing the Caret of a PluggableTextMorph

by Fernando Olivero

Hi Sean, you can take a look at Athens-PangoCairo (in squeaksource). Using NativeBoost, i'm using the Pango layout library [1], and the Pango-Cairo binding [2], to avoid laying out text using the outdated (and messy) stuff in the image. Check out the classes: ParagraphDescription & AthensPangoCairoParagraph. I'm using them as the basis for the TextShape,LabelShape, and EditableTextShape in Shapes / Gaucho ( using TextEditor, SingleLineEditor ). Maybe somebody can do the same for Morphic? use Pango to layout the text, and code a new TextMorph on top of it? Fernando [1] http://developer.gnome.org/pango/stable/pango-Layout-Objects.html [2] http://developer.gnome.org/pango/stable/pango-Cairo-Rendering.html On Wed, Jul 18, 2012 at 7:28 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Jul 16, 2012, at 9:38 PM, Sean P. DeNigris wrote: > >> For VimPharo, I want to have a different cursor depending on whether a tool >> is in insert or normal mode. >> >> I tried a handful of ways, but they all failed or worked >> partially/inconsistently. Here's some of them: >> * add the state to the paragraph, but the entire paragraph gets replaced >> during the life of the tool, so the state gets lost >> * add the state to the editor, but the situation is the same >> * add the state to PluggableTextMorph, override and access it from >> TextMorphForEditView>>updateFromParagraph. This was an extreme PITA and got >> me very acquainted with the emergency evaluator. It "worked", but only after >> using the arrows a bit. >> >> Does anyone have any idea where I might hook in? >> >> <rant>I find the whole text system very confusing. What the heck does a >> paragraph know about insertion points?? A view has one paragraph object, >> even if there are several paragraphs (as understood by the rest of humanity >> as a block of text with breaks between the adjoining ones. Editors and >> Paragraphs are thrown out and replaced on a whim. I'm finding it very hard >> to understand and modify</rant> > > I got burned by that when I worked on my botanics envâ¦. > it was terrible. > >> >> Thanks, >> Sean >> >> -- >> View this message in context: http://forum.world.st/Customizing-the-Caret-of-a-PluggableTextMorph-tp46402… >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> > >

July 20, 2012

Re: [Pharo-project] We crossed 6000 closed issues!

by Sven Van Caekenberghe

Great momentum indeed. On 20 Jul 2012, at 09:44, Marcus Denker wrote: > Today the bug tracker: > > http://code.google.com/p/pharo/issues/list > > says 411 open out of 6426 issues. > > This means we crossed the line of 6000 reports being closed last week. > > We crossed 5000 just this March 6th. We even have less open issues than back then > (411 intead of 436). > > Marcus > > > -- > Marcus Denker -- http://marcusdenker.de

July 20, 2012

Re: [Pharo-project] Spec Enhancement Request

by Goubier Thierry

Le 18/07/2012 07:30, StÃ©phane Ducasse a Ã©crit : > > On Jul 17, 2012, at 9:46 AM, Goubier Thierry wrote: > >> Hi, >> >> could Spec gives access to drag and drop on morphs ? > > yes it should. > A spec should capture all the description of the underlying widget. Many of the behavior/presentation are not captured right > just because we wanted to make sure that the idea work and we took a breadth first approach. > Because adding new meta-data is simple. Ok. Maybe an experiment could be to let Spec users extend on current Spec for a few cases of drag and drop, study the resulting code, and generalize an architecture for spec from that ? Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

July 20, 2012

Re: [Pharo-project] Spec questions

by Goubier Thierry

Le 18/07/2012 07:26, StÃ©phane Ducasse a Ã©crit : > this is a good summary > Ben willcertainly comment it. Thanks. My small attempt at documenting it :-) >> Here I come with somme feedback on Spec. >> >> I tried to rebuilt an example using a tree view using spec this week-end, and it went fairly well (after a few misunderstandings). >> >> So, if I summarize what Spec is : >> >> * A herarchical view of models (a model is composed of submodels, where submodels may themselves be composite), up to elementary models provided by Spec. >> * A related hierarchy of views, which are created by specs. >> * Each model provides a defaultSpec to create the display. >> * Each model, even a composite, must implement the following methods : initializePresenter, initializeWidgets. And use instantiateModels:! >> * Models are linked to one another by appropriate "trigger" blocks. >> >> Good points : >> >> * Creating a window is very easy; just call openWithSpec. >> * The declarative aspect of Spec methods seems nice for a GUI painter. >> * There are enough models for a good start. >> >> A bit confusing so far with Spec: >> >> * Some examples have twice the submodels initialization (ClassMethodBrowser, in initialize and initializeWidgets) >> * Two syntaxes are available in xSpec methods >> * Two syntaxes are available in calls to instantiateModels: > this will be fixed. Maybe documenting both is enough; the array-based one is good for future tools (easy to manipulate), the code-based one is better for programmers (especially since the RB formatter doesn't do well, IMO, with dynamic arrays). >> * I don't know yet how an existing application would connect to a Spec-based GUI (i.e. I don't know how to do a M-MVC app with it). > indeed for now not clear if we will handle that Ok. >> * I haven't found a declarative way of setting up relations between models. > How would it be possible? A few objects defining more or less standard interactions (share, transform two-ways), with a bit of customisation and a painter for composite views... no ? In it's current state, Spec is already interesting. Good work ! Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

July 20, 2012

[Pharo-project] We crossed 6000 closed issues!

by Marcus Denker

Today the bug tracker: http://code.google.com/p/pharo/issues/list says 411 open out of 6426 issues. This means we crossed the line of 6000 reports being closed last week. We crossed 5000 just this March 6th. We even have less open issues than back then (411 intead of 436). Marcus -- Marcus Denker -- http://marcusdenker.de

July 20, 2012

[Pharo-project] [update 2.0] #20229

by Marcus Denker

20229 ----- Issue 6429: move methodReference to Ring http://code.google.com/p/pharo/issues/detail?id=6429 Issue 6428: add save option to FuelCommandLineHandler http://code.google.com/p/pharo/issues/detail?id=6428 -- Marcus Denker -- http://marcusdenker.de

July 20, 2012