[Top][All Lists]

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

Fwd: Re: [Help-smalltalk] VisualGST

From: Gwenael Casaccio
Subject: Fwd: Re: [Help-smalltalk] VisualGST
Date: Mon, 21 Mar 2011 11:59:34 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110223 Thunderbird/3.1.8

-------- 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):

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

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.


reply via email to

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