[Pharo-project] Customizing the Caret of a PluggableTextMorph

phil at highoctane.be phil at highoctane.be
Fri Jul 20 06:20:58 EDT 2012

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

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

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 at 0 extent: extX at extY);

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.


2012/7/18 Stéphane Ducasse <stephane.ducasse at 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-tp4640245.html
> > Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
> >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20120720/959ade0b/attachment-0001.html>

More information about the Pharo-dev mailing list