[Pharo-project] [squeak-dev] Re: Optimizing RunArray

David T. Lewis lewis at mail.msen.com
Wed Aug 3 02:03:36 UTC 2011

On Wed, Aug 03, 2011 at 02:38:07AM +0200, Nicolas Cellier wrote:
> 2011/8/3 David T. Lewis <lewis at mail.msen.com>:
> > On Wed, Aug 03, 2011 at 01:01:11AM +0200, Nicolas Cellier wrote:
> >> One thing that super upset me is that TextEditor is still using the
> >> old selectors #readKeyboard #keyboard #keyboardPeek instead of using
> >> events.
> >
> > I would like to see this fixed, but I would also like to see it done
> > right whenever it does get fixed. That means make it work properly in
> > MVC as well as in Morphic (and SimpleMorphic). It will be more work
> > to do it that way, but IMO it is better to take the time to do it
> > right if it is going to be done at all.
> >
> > One of the many things that is nice about Cuis is the use of events
> > in TextEditor. When comparing SimpleMorphic (extracted from Cuis)
> > to Morphic, a large portion of the differences were due to this alone.
> > But we should use the Squeak Project structure along with ToolBuilder
> > to make sure that all types of project work in reasonable ways.
> >
> > I think that MVC is important not just because it is small and
> > efficient, but also because it provides a real test of portability
> > across different styles of UI interaction. This gives a real way to
> > test if some concept or feature is truly generic (and thus should
> > be supported in a general way in projects and tool builder), or if
> > it is a feature that is specific to one type of UI. In other words,
> > if something works in a Morphic project and in an MVC project, then
> > there is a fairly good chance that it is generic enough that it
> > will work in a SeasideProject or an AidaProject or a TabletUIProject
> > or whatever.
> >
> > So please: Whoever steps up to do the work of changing TextEditor
> > to use events, please also make it work in MVC while you are at it.
> > Or ask for a collaborator to work with you to make sure it gets done.
> >
> > $0.02,
> >
> > Dave
> >
> Yes, I didn't propose to erase and kill MVC, I proposed to move the
> hack in proper place because it has nothing to do in normal Morphic
> code.
> So the hack will go in TextMorphEditor which is a glue for ParagrapheEditor.
> It will be in TextMorphEditor keyStroke: and maybe in mouseUp:
> mouseDown: and mouseMove: (didn't analyse if really necessary yet).
> I have defined the method:
> TextMorphEditor>>fakeSensorWithEvent: anEvent
> 	"Pass the event to a polling-friendly-sensor-fake so that old st-80
> code shall still work"
> 	self sensor: (KeyboardBuffer new startingEvent: anEvent).
> then
> TextMorphEditor>>keyStroke: anEvent
> 	self fakeSensorWithEvent: anEvent.
> 	self readKeyboard.
> 	self storeSelectionInParagraph
> then
> 	TextMorphEditor removeSelector: readKeyboard.
> (it did call super and storeSelectionInParagraph, keyStroke: do both)
> I don't know how to test MVC, but I think it should work as well (bad
> ?) as previously.

A minimal test is just to open a workspace in an MVC project and
try some typing and editing. Success means that it works no worse
than it did before you made a change. I would suggest testing
incrementally, checking after each significant change to make sure
that the corresponding function still works no worse in MVC than
before the change.

This is a rather subjective procedure, because MVC works poorly,
with slow keyboard event handling and cursor placement showing up
somewhere it used to be back before some slow event finally got
delivered. Symptoms are less horrible with Cog, possibly because
the VM does everything faster (including event delivery).

So the minimal objective is: Do not make it worse. A better outcome
would be to figure out what is bolluxed up in the keyboard event
delivery in MVC. It's probably something simple, but I don't know
where to look for it, and perhaps in the course of reworking the
TextEditor to use events, the problem will make itself visible :)

For reference, the last solid MVC appeared in Squeak 3.8. It is
much better now in Squeak trunk than in some previous Squeak
versions, but it is still not nearly as good as it was in
Squeak 3.8 and earlier.


More information about the Squeak-dev mailing list