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 _______________________________________________ Sugar mailing list [email protected] http://mailman.laptop.org/mailman/listinfo/sugar
