Re: inline outliners

[Jecel Assumpcao Jr <jecel@lsi.usp.br>]

Randy Smith wrote:
> But not so sure about your last case there... what if you have a
> tightly-packed run of very small morphs (like on a tool bar) and you're
> trying to look at a bunch of them at once? Even of most of these
> outliners were collapsed, it could be a pain and visually obscuring,
> confusing or misleading.

I think my idea would limit you to having an outliner for at
most one morph in this case. This is even worse than it sounds,
since closing that outliner and "opening" another is a bit
difficult due to the problems of selecting a given morph in
such a nested structure.

Unfortunately, I have not used the Self 4 interface enough to
know how common this kind of situation is.

> We talked about having outliners pop-up adjacent to the morph, yet stuck
> to the edge of the morph so that the two moved together. But stuck in a
> "loose" way, so that some simple gesture could undo the connection.

You might think of my idea as having the ouliner stuck *under*
the morph. This is actually backwards conceptually - I would
say it makes more sense to have the outliner in the morph than
the other way around. Then you would sprout the outliner from
the morph. But it makes more sense visually to draw the outliner
around the morph. That makes sprouting the morph strange, of
course, since it should stay in place and the ouliner should
move out of the way.

> Perhaps simply grabbing the outliner would free it from its morph. Some
> animation or direction indicator might be used to show a disconnected
> outliner's desire to "return home."

It might be best to simply reuse the visual pointers already
present in the interface. Maybe making them "bidirectional" by
having them stick to the edges on both the morph and the outliner
to show the neither is "contained" in the other. Or the pointer
could start in an empty box in the outliner's title to be
consistent with the (wrong) idea above that the morph is *in*
the outliner.

> If this appeals, it should be easy to do using the same mechanism that
> is used for the sprouted "pointers" from outliner slots.  If you sprout
> the little button (or pointer thing) at the end of a slot it runs out and
> sticks to appropriate target outliner, and will even follow it around if
> the target moves.  But if you grab the pointer, you just end up holding
> the pointer.

Right - it should be easy to get rid of the connecting line. But
you wouldn't be allowed to drop the pointer head on other morphs
(changing what morph the outliner is related to) or the outliner
would start to look like a traditional tool. Other than that,
it would be great to reuse the sprouting pointer conventions
(and code).

-- 
-----=============( Jecel Mattos de Assumpcao Jr )===========-----
http://www.lsi.usp.br/~jecel/merlin.html | mailto:jecel@lsi.usp.br