[sugar] Re: "TreeView" widget for Sugar and Hierarchy as a Necessary Evil

[Eben Eliason]

> Develop currently uses the GTK TreeView to display the directory structure
> of the activity the user is hacking on, and one double clicks on rows
> display the files for editing, drag and drops for moves, etc.

I would make a single click focus the tab for the file (opening a new
tab if required).  Double click is unnecessary.

> So, I figure we should probably write a Sugar TreeView-ish widget.

Necessary evil, indeed, but you're probably right.

> Don's pie-menus aren't really appropriate for this task, mostly because
> they are very wasteful of screen space.  Thus, they are  better suited
> to display menus rather than trees of data.

I'm absolutely in agreement with this.  Pie menus don't work as a
directory tree.

> That said, is a "TreeView" considered a reasonable way to display a
> hierachical tree of information?  I know that any form of hierarchial
> display is not considered kosher for OLPC, but there's really no
> getting around that requirement for Develop.  Unless, of course,
> someone can think up a better way of representing a directory structure

A tree view is reasonable, I suppose.  When I'm browsing directories I
usually find that a column view is more desirable.  Additionally, a
column view is ever so slightly less hierarchical in nature, in that
each column represents a directory "object."  But I'm not sure that's
a good candidate in this case, since it would require a horizontal
layout and wouldn't allow one to see/scroll past every file in the
project.

In this case, we may just want to do our best to make a "file tree"
that fits inside of sugar, visually.  Oh, and we definitely won't call
it the "file tree." =)

> Develop's current (and very traditional IDE-style) interface:
> http://wiki.laptop.org/go/Image:Develop-activity-very-early.png
> Eben, I would greatly appreciate any insight into how I can make this
> better. :D

It's a good start.  Once we have a slightly more finished spec for the
whole UI, I can mockup a slightly different look for it.  Overall,
it's pretty straightforward, though.  I think there will probably be
some niceties to add though.  For instance, I usually like having a
column to the left with line numbers in it.  This is also useful for
bookmarking lines, or revealing which lines have errors.  I would
detach the line numbers from the actual scrolling text view, so even
if you scroll far to the right they remain on screen.

We could make the line number, col. number fields at the bottom
editable, providing a way to jump to a line for those who don't know
the key command for the same.

We should probably add a methods popup, so you can jump to a method
easily.  This should go down in the bottom bar adjacent to the line
number, and should update as the cursor moves through the code.

I would think one of the buttons should be a compile button, but the
closest thing I see right now is a next button....is that what it's
supposed to be?

I'm sure I'll have plenty more comments in the future, but these are a
few first reactions.

Oh, also, I'm not sure if we can support this or not, but it would be
great if we could code in some form of crossmark, so that annotations
can be attached to blocks of code.  This way, I suppose that's really
just another way of commenting, but I could actually see it being used
as a way to make collaborative editing easier.  Rather than mucking up
the comments with "I changed this thing you wrote because...", these
types of back and forth discussions could happen inside annotations
that aren't actually part of the source.

Finally, if you want to see something cool, check out this screencast
for a text editor on OSX:
http://macromates.com/screencast/objective-c_part_1.mov

This "snippet" system is extraordinarily powerful, especially combined
with the scoping system for the languages.  Something like this could
make coding some basic things much more accessible to kids, since the
syntax is in many cases implicit.

- Eben