User interface of VisualGST

First of all, let me state that I realize that VisualGST is a work in progress and that the main target platform is probably Gnomish and my ideas may be too Mac-ish (although I think Gnome is inspired by many of the better concepts of Mac OS 9). That being said, I have a few comments:

1. The toolbar is always the same no matter what window you're using. It should probably have things in it that apply specifically to the current window. The Debugger, for example, could have:

Run / Restart / Step Into / Step Over / Step Out

2. Windows such as the debugger and message finders may not even need a menu bar (maybe File and Edit for Gnome / Windows environments - on OS X it could be removed completely). It's a little strange to pick Tools->Browser in the Debugger and get a new tab in a different window!

Ok, those two were a little self-serving ... if there was only one really important menu bar, OS X could dispense with the others. But I do that window-specific toolbars make sense. :)

3. Using GtkSeparatorMenuItem instead of a blank GtkMenuItem looks nicer in OS X, under many GTK themes and is more correct anyway... I've attached a patch.

Eli

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

> 1. The toolbar is always the same no matter what window you're using.

100% agreed, I reopened http://smalltalk.gnu.org/project/comments/add/382

> 2. Windows such as the debugger and message finders may not even need a menu bar (maybe File and Edit for Gnome / Windows environments - on OS X it could be removed completely).

Long term, I wonder if we want to create at all new windows for
everything but debuggers.  There should be of course a Tools->New Window
menu that creates a new window if the user wants one, but tools should
probably open as new tabs.

> 3. Using GtkSeparatorMenuItem instead of a blank GtkMenuItem looks nicer in OS X, under many GTK themes and is more correct anyway...

Gwen, please apply this.

Paolo


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

On Wed, 2009-10-14 at 14:51 +0200, Paolo Bonzini wrote:
Hi,

thanks for your review. Yes VisualGST is a young project :)

- For the icons if you give me icons I'll put the icons everywhere ;)
(overloaded method, methods with halt inside, test method, ...)  

- For the window yes I had the same ideas in fact changing is not really
the ui is not really the problem everything is widget in VisualGST
I can plug everything in VisualGST without a "big" refactoring.

- Thanks for the patch. Paolo I'll check this evening if the patch for
the Restarting a saved image with the browser loaded is fine.

The project is not only young and we should not only attach attention
only on the UI.

How do we manage sources : image based approach or file based approach
or both ? What kind of versioning tool do we want (git, monticello, a
framework on which we can plug svn/git/monticello ?) with metacello ?
Integrate SUnit test inside the browser, SLint inside the browser too
(can be nice) Refactorings the "refactorings" are tooooo simple :p ? If
we act like an image we'll need a changeset (may be delta stream of
Goran Krample) ? if we output the file Nicolas want that we preserver
the same format (i.e. 1 tab = 4 spaces ... ) ...

For the debugger : see what part of the code is executed : impossible to
know it now, a decompiler, show the byte code, a stuff that can be nice
"Debugging Backwards in Time" , evaluating code failed sometimes ... .

SUnit : need to display the backtrace, have information on the time
taken, regression, statistic, ...

In the inspector we need more views sets, dictionaires, compMethods,
compBlock, ... may be for GtkWidget (drawing the widget inside the
textview ^^)

Improve the sender/implementor : list the implementor/sender in the
implementor/sender and navigate.

An other stupid problem RBParser is used to parse the St code and
highlight it that's fine ... but the version is old and if you have
a at: .. put: 3. if failed ... I am porting a newer version of RBParser
(I improved it) so we can have pattern rewritting and Refactorings
without loosing format (RBFormat in last versions for example loose
comments ...)

The problem is not really the UI changing the menu bar, toolbar, ... is
easy...

I spend a lot of time on it really but the problem is not a question
of toolbar or whatever (but at the end I should change the toolbar
add some icons...)

I've a lot of ideas but what I need is time and a little help.
I enjoy to work on it and with this community by trying to improve
VisualGST step by step that's fun !

Cheers,
Gwenael



_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

> - For the icons if you give me icons I'll put the icons everywhere ;)
> (overloaded method, methods with halt inside, test method, ...)

You can get icons from
http://tango.freedesktop.org/releases/tango-icon-theme-0.8.90.tar.gz

For example:

actions/go-next.svg -> step (into)
actions/go-jump.svg -> next (step over)
actions/go-up.svg -> finish
actions/media-playback-start.svg -> run (we can ask them to make a green
version)

I created https://bugs.freedesktop.org/show_bug.cgi?id=24526

> - For the window yes I had the same ideas in fact changing is not really
> the ui is not really the problem everything is widget in VisualGST
> I can plug everything in VisualGST without a "big" refactoring.

That's great to hear (what about the toolbar though?  Can it change
dynamically?).

> How do we manage sources : image based approach or file based approach
> or both ?

File, definitely.  But managing sources is the most complicated thing to
design.  The least code we write, the more freedom we have later.

For now, having one namespace per package and one class per file (so
that you can fileout namespace from the UI + git commit from the command
line) is good enough.

The first step could be to port gitocello's git interface and
incorporate it into VisualGST.  Then the second could be to abstract it
and add svn support.  I can look at it as soon as I'm done with Swazoo
(shouldn't take much longer).

> For the debugger : see what part of the code is executed : impossible to
> know it now, a decompiler, show the byte code, a stuff that can be nice
> "Debugging Backwards in Time" , evaluating code failed sometimes ... .

All are very low priority, I'd say.

> SUnit : need to display the backtrace, have information on the time
> taken, regression, statistic, ...

The most important thing to do is to provide a "Debug this" menu item.
Without it, the SUnit browser is only good if all tests are green. :-)
There's already a bug opened for this.  Everything else can come later.

> In the inspector we need more views sets, dictionaires, compMethods,
> compBlock, ... may be for GtkWidget (drawing the widget inside the
> textview ^^)

Please create a bug for this.  It's low priority though.

> An other stupid problem RBParser is used to parse the St code and
> highlight it that's fine ... but the version is old and if you have
> a at: .. put: 3. if failed ... I am porting a newer version of RBParser
> (I improved it) so we can have pattern rewritting and Refactorings
> without loosing format (RBFormat in last versions for example loose
> comments ...)

That would be absolutely great for gst-convert too.

> The problem is not really the UI changing the menu bar, toolbar, ... is
> easy...
>
> I spend a lot of time on it really but the problem is not a question
> of toolbar or whatever (but at the end I should change the toolbar
> add some icons...)

That's a start though.  Remember people won't complain about missing
features as much as about existing features (me included).

There's no hurry.  Maybe however you can branch visualgst so that the UI
work can get some priority if that's easy.

Paolo


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

 
On Wednesday, October 14, 2009, at 05:55PM, "Paolo Bonzini" <[hidden email]> wrote:
>
>> - For the icons if you give me icons I'll put the icons everywhere ;)
>> (overloaded method, methods with halt inside, test method, ...)
>

Icons were the least of my worries. :)

>> - For the window yes I had the same ideas in fact changing is not really
>> the ui is not really the problem everything is widget in VisualGST
>> I can plug everything in VisualGST without a "big" refactoring.
>
>That's great to hear (what about the toolbar though?  Can it change
>dynamically?).

I think this is frowned upon in UI circles... maybe something like a sidebar would be a good idea (think Firefox, Evolution, etc). This could have various "small" tools in it, like the method finder; this way, the tools could simply reuse the class browser that it was tied to or even offer a context menu option "Open in new Class Browser".

The nice thing about a sidebar is that you can add a very large number of panels to it and they only take up space when they're being used, so it can be a good place to put items that are part of your normal workflow but not as common as the class browser.

>> How do we manage sources : image based approach or file based approach
>> or both ?
>
>File, definitely.  But managing sources is the most complicated thing to
>design.  The least code we write, the more freedom we have later.
>
>For now, having one namespace per package and one class per file (so
>that you can fileout namespace from the UI + git commit from the command
>line) is good enough.

There's a complication here (of course!): extensions to classes that don't belong in your namespace. Monticello's method, of course, is to match class packages with method categories so that the Seaside package is bundled together with methods in the *seaside category in other classes.

The SqueakSVN project used an even more radical approach of saving each method to a separate file. Of course, this would make diffs very easy to generate for each method but easy diff'ing is a problem that has been solved already.




_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

>>> - For the window yes I had the same ideas in fact changing is not really
>>> the ui is not really the problem everything is widget in VisualGST
>>> I can plug everything in VisualGST without a "big" refactoring.
>>
>> That's great to hear (what about the toolbar though?  Can it change
>> dynamically?).
>
> I think this is frowned upon in UI circles... maybe something like a sidebar would be a good idea

What would you put in the sidebar?  It's just a bunch of icons, nothing
like the history or bookmarks of Firefox.  Seriously, I wouldn't bother
too much.

Also, in the browser it's the horizontal space that is at a premium.

That's true.  For that we need some kind of UI to remember what a
"project" is about, or a DWIM "fileout project" command that also files
out categories named after a namespace (similar to Monticello, also with
the * prefix).

Paolo


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

On Oct 14, 2009, at 19:12, Paolo Bonzini wrote:

I wasn't suggesting putting the buttons there, I would put the actual  
tools. For example, the "Search for Senders" tool is really just a  
text entry widget and two lists: a list of matching messages and a  
list of classes/methods that send the selected message. Well, instead  
of two lists, the text entry box could be an auto-complete widget that  
lets you pick the message. After the message is selected, the senders  
could be displayed in the list.

This whole setup could easily fit in a panel in a sidebar.


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

CONTENTS DELETED