[UI] Re: MenuMorph hand weirdness

[Gary Chambers]

> -----Original Message-----
> From: ui-bounces at lists.squeakfoundation.org
> [mailto:ui-bounces at lists.squeakfoundation.org]On Behalf Of Bill Schwab
> Sent: 20 November 2007 2:44 PM
> To: ui at lists.squeakfoundation.org
> Subject: RE: [UI] Re: MenuMorph hand weirdness
>
>
> Gary,
>
> In terms of describing an interface, I immediately zoom out to the two
> ways one might approach it: graphical editing, and writing code.  The
> nature of the GUI editor and the language are "just details."  IMHO,
> both methods are essential for happy programmers.  I have some GUI
> generating/translating tools that I would expect to port to whatever
> Smalltalk system I end up using; they speak MVP.  If I land in Squeak,
> it will have an MVP framework, if only because I will write one out of
> frustration :)

	a concise (programmatic) construction framework would be nice as a basis
for graphical tools. Code generation-reintegration is, IMHO, more flexible
and explict than live prototypes. It is alway good to know that there is a
basis for recreating a (specific) UI for a system. Similar to the concept of
the image, good to know that it can (essentially) be regenerated if
corruption problems occur.

>
> As I have mentioned before, I am concerned that any MVP work I do would
> be tainted with Object Arts' intellectual property.  However, if I
> create a framework (tainted) and my own tests for it (by definition
> clean - right???), then the tests could be the basis for a clean MVP
> framework for Squeak.  Any flaws?  It is a lot of wasted work to write
> and then have someone else rewrite a framework, but it might solve the
> problem.  At least the rewrite would occur with the benefit of tests.
>

	MVP, as I remember, predates Dolphin in research terms...

> With some cleverness, Morphs as views, native widgets, SVG, etc., are
> hopefully just different types of views in the framework.
>

	Indeed, though a mechanism (call it a theme or configuration perhaps) to
bind a coherent set of things together will help. If things are
cross-pluggable then it should be easy to mix-n-match to suit any need.

> As a practical matter, I have a few too many Squeak images for my own
> good.  I need to archive them all, mine code out of them, and create one
> image that will move back and forth between Linux and Windows.  Any
> thoughts on 3.9 vs. 3.10?  For 3.9, I would want the
> delay/queue/semaphore fixes; IIRC, those are included in 3.10??
>
> Bill

	Since I'm currently working on deployment to customers I'll be sticking
with 3.9 (fixes applied) for the moment. Others in the office are on the
3.10 dev beta images. Once our release is stable we'll migrate to 3.10 in
the background, I don't forsee any real problems, not the right time to
abandon 3.9 for our deliverables just yet.

	Found another process related bug i may have to air in the dev list. Looks
like Process>>isTerminated is not thread safe/and/or correct. Have has
instances where a live process has responded "true" to isTerminated,
briefly! (we are using quite a few processes at various priorities -
preemption bites!)

	For me, for a fresh start, I'd like to start at "the bottom", basic
drawing/interation (Cairo/BitBlt/Balloon/GTK etc). Perhaps we can meet
halfway...