help-smalltalk
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Help-smalltalk] User interface of VisualGST


From: Paolo Bonzini
Subject: Re: [Help-smalltalk] User interface of VisualGST
Date: Wed, 14 Oct 2009 17:55:53 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.4pre) Gecko/20090922 Fedora/3.0-2.7.b4.fc11 Lightning/1.0pre Thunderbird/3.0b4


- 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]