Fwd: Re: [Help-smalltalk] VisualGST

[Gwenael Casaccio]

-------- Original Message --------
Subject: Re: [Help-smalltalk] VisualGST
Date: Mon, 21 Mar 2011 11:56:51 +0100
From: Gwenael Casaccio <address@hidden>
To: Paolo Bonzini <address@hidden>

On 03/21/2011 08:35 AM, Paolo Bonzini wrote:
> On Sun, Mar 20, 2011 at 10:01, Gwenael Casaccio<address@hidden>  wrote:
> > That's true and this is something I've in mind for such
> > a time but yesterday I've hacked a bit VisualGST
> > and made a simple prototype (this is just a "new" widget):
> >
> > http://www.youtube.com/watch?v=-B4s6niwZEw
> >
> > or you can try the browserWidget branch on VisualGST git
>
> It is interesting indeed.  I like the idea.  However, please make sure
> that it is implemented with a sane state model---such as my newState
> experiment, though not necessarily that one.  The biggest bug (not
> limitation!) in VisualGST right now is that the behavior is quite
> unpredictable when you entered code that does not compile.

This is good to recall me that important point Paolo, now this is just a
prototype I've to thing more about it and polish it. Someone pointed
me that StrongTalk IDE was closed to this UI model I should take a look.

> However, the obvious devil's advocate question is: why do you like
> this, but not merging the transcript/workspace tab strip with the
> browsers tabstrip?

In a perfect world :) the tools will fit to you. Now I like the paned
separation because I've access to everything and meanwhile I browse
smalltalk code, I can evaluate code without switching a tab =>
I have both informations. And the panned separation make the UI
consistent on top browsers => bottom text.

I think with the new widget I like this model because it is lightweight
only for that And also I only have one same model everywhere at the end
even the debugger could be refactored in that way. It makes everything
consistent

> > Now I want to merge the transcript (should be replaced by
> > a kind of log tool), the workspace and the source widget. They are
> > not exactly the same but share same functionalities the user can
> > evaluate/inspect/debug but the major difference I want to introduce is
> > the idea of "scope" inside a Namespace the source widget will work
> > like a normal workspace inside a class too but inside a method.
>
> That's nice indeed.  Adding Namespace selection to a workspace is a
> very good idea, especially if we can get rid of the
> Namespace>>#current: method in 3.3.
>
> However, remember that a workspace has the additional functionality of
> tracking undefined variables.  How would that fit?

Undefined variables could be tracked inside a namespace like that we
could reuse them with other "workspace" in the same namespace but they
should not be seen as globals. Source code could be tracked too but I
don't know how I've to think more about the model. A model like that
could make sens :

When I begin a new project I first create few classes of my program =>
and generally instead of writing tests I evaluate code inside a
workspace. Here it can be done in the scoped namespace. This new model
brings a kind of link between the "draft" code in the workspace and the
classes in the namespaces. Now the model should be polished and reified.

Also with the new model a simple scenario:

 we are in a namespace so the source widget acts as a workspace.
 now we go inside a class and method (the source is saved).
 add new methods, ...
 click on the namespace button it restores the source code.

> Paolo