Smalltalk › Gnu

Fwd: Re: [Help-smalltalk] VisualGST

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

1 message

MrGwen

Fwd: Re: [Help-smalltalk] VisualGST

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

On 03/21/2011 08:35 AM, Paolo Bonzini wrote:

> On Sun, Mar 20, 2011 at 10:01, Gwenael Casaccio<[hidden email]> 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

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