GUI Roadmap/TODO list

[Brian T. Rice]

On Wed, April 19, 2006 6:28 pm, Timmy Douglas said:
> "Brian T. Rice" <water at tunes.org> writes:
>
>> Yeah, that's how you should take it. I played a few visionary cards
>> in writing that, ported some basic CLIM stuff, and haven't been able
>> to flesh it out enough beyond that.
>
> Yeah I have noticed some of this clim visionary code and I'd have no
> idea where to start if I had to add code like that. I don't have much
> experience using clim and it's not like I've ever designed the
> internals or lower levels of a ui system before. but it seems that
> most of that has been taken care of.

Well, first of all, CLIM works as a set of concepts and has real
implementations that do things elegantly in ways that Squeak Morphic
can't. It is not visionary stuff except that most developers don't bother
to learn it and that very few other toolkits can do what it does. I'm
assuming that you're coming from the Squeak Morphic viewpoint, and I
should state that I consider this a highly-flawed one, for reasons I'll
detail as reply to your further observations/questions.

>> At some point there's going to have to be some rationalization of
>> the efforts of the multiple, non-interacting contributors... what we
>> have now is just too chaotic (even if it is loads simpler than
>> Squeak's setup).
>
> So lets say the goal (for now, for me or anyone interested) is to make
> a browser like squeak's system browser or omnibrowser or whatever.

See src/lib/browser.slate for a sketchy port of the OmniBrowser model,
which is what I would prefer to have as the basis of Slate structured
navigation (inspectors, browsers, etc.).

> I guess this would include (questions are in parenthesis):
>
> - Draggable morphs (looks like code is there for this?)

Yes. Here's the deal: Todd wrote code for dynamic mixins where
draggability and so forth could be dynamically added. See the Behavior
code in src/ui/morph.slate with #handle:for: and #morph:handle:for:. I
consider this a step forward from the Morphic code base simply because in
Morphic, all the behavior that will ever be needed is lumped into the base
class or some relatively high-placed abstract class. Unfortunately, that
behavior is only needed in specific contexts (and many behaviors are often
only needed in independent contexts), otherwise it is wasted.

Anyway, Todd's demo code in demo/ui.slate has draggable things and resize
handles.

> - Morph manipulation (using halos? it'd be nice if there were like
>   keyboard shortcuts also... like dragging morphs by holding alt and
>   dragging.. etc), deleting, resizing, duplication

A toolset user interface for this does need to be written. Squeak's halo
interface is really bad from a usability standpoint, but the idea of
exposable controls is a good one. I'd prefer something a little more
video-game-like.

> - Balloons

Balloon-help is desirable. Just make sure that the concrete aspects of it
are not implicit in the protocol for dealing with the actual content.

> - A bordered display element
>   - Containing a title bar
>   - Resizable
>   - stretch-to-fit area

These are easy to make.

> - Scrollable elements (not sure how this would be done clim-style or
>   anything) I haven't had time to understand the spaceRequirement
>   stuff yet.

It's just a way to communicate desired limits in resizing. I can't recall
what McCLIM does, but it can be looked up. I'll try to get that done
before Saturday when I leave for Toronto.

> - Listboxes (should this be like the pluggable type in squeak where
>   you set it up to work with another class that is like a model?)

Yes, of course there should be a model-view separation. The details will
differ substantially from Squeak's, however.

Just make something that's not as mind-bogglingly limited as Squeak's...
make it work as generically as is easy to do, and we'll work on making it
more generic once it *works*.

> - Buttons (since there isn't exactly a 'target' in MD languages, how
>   would this be set up? and which morphs receive what mouse actions?)

What are you talking about? Just use a block or send a message. Don't
sweat this stuff until something works. We'll change it when we need more
flexibility.

> - Text (same questions as above and I'm not really sure on how to hold
>   the buffer data or the best way for displaying it..if it should
>   follow a MVC paradigm approach, etc.) my only experience in this
>   field is when i wrote the junk at:
>   http://www-static.cc.gatech.edu/~timmy/te.html . The only decently
>   interesting part of that was that the buffer held objects instead of
>   just plain text so it was more interesting to draw I guess. On the
>   other hand, I feel like some of the buffer operations took more code
>   than I think they should have, and there wasn't a good way to only
>   redraw the changed regions.

Not bad. I'm a little too busy with my mind on other things to have any
recommendations in that area right now. "The Craft of Text Editing" is a
book that is available online that is at least somewhat helpful for
thinking about text-editing-specific engine issues.

>   I don't really know how squeak works
>   except that the undo isn't very good and it's not powerful enough.

Slate has src/ui/command.slate which is supposed to hint at the idea of
extending events to be actual commands that remember undo information
(which requires the person deriving a new command type to add appropriate
state and a related #undo method).

One overall element is not complete for this, which is an observer or
publish/subscribe model of updates. src/lib/observer.slate exists, but
it's a toy and needs proper concurrency (*sigh*) to be really useful.

Also the GC needs to be instrumented in such a way that it can understand
how to handle weak references when the object is marked weak, which I keep
not-getting-around-to. There is a map flag reserved for weak-reference
objects that is not utilized yet for this, although it mostly would seem
that only weak object-arrays would be sufficient. I'm not sure if weak
named-slots are going to be common enough. In any case, that would make a
basis for weak Sets and Dictionaries for observer relation tracking.

I'm rambling, though. Just hack and send something and I'll work with it.

I will say, though, that Squeak's code and concepts just plain suck on
most levels, so don't try to ape it by default - try to think from a less
nuanced perspective.

--
http://tunes.org/~water/brice.vcf