Re: [Help-smalltalk] User interface of VisualGST

[Eli Green]

On Wednesday, October 14, 2009, at 05:55PM, "Paolo Bonzini" <address@hidden> 
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.