visualgst plans

Hi Gwen,

1) I pushed my changes and rebased them on top of the save widget stuff.
It can be pulled. The main fixes are that Tools menu behavior is more
uniform across all browsers, and that many bugs in "Accept it" were
fixed.  I also finished my previous refactoring by moving more methods
from browsers to BrowserState, so that the Commands can rely on the
state more and more instead of asking the browsers.

There are still a couple of sore points in the class hierarchy, but I
think we're relying less and less on duck typing---which makes the
system easier to understand and enhance.

I'm thinking of dropping the webkit stuff since it's probably bitrotted
and not too used.  Is this fine for you?

2) I took a look at the state save widget. It looks great, it could
"feel" much better. There it makes sense to choose
between accept, cancel and close. In the future, instead of "accept" you
may even propose special choices such as declaring variables as
temporary or instance.

However, there is one serious problem: it makes the modal choice of
"what to do after clicking somewhere in the upper half of the browser"
modeless. It is great when you have a compile error, much better than
the "insert error as selection" you have in Squeak. I think the old
dialog should be preserved in case the state changed. In this case you
have to choose between accept/cancel/revisit (the third choice brings
back the old selection), but you have to do so modally. If you choose
accept and there is a compile error, the choice should be changed to
revisit, and the save widget should pop up.

Also, the save widget must work with all browsers. With my recent
changes I moved "accept it" to the GtkSourceCodeWidget, and this should
make it easier to refactor save widget stuff so that it works in the
debugger, inspector browser, SUnit browser, GtkLauncher, and regular
class browsers (sender/inspector should already be taken care of).

The compiler errors pane in GtkLauncher can then be removed, and no
Debuggers should pop up upon a compiler error.

Do you agree?

At the same time (actually, after everything above is sorted out since
this is a relatively trivial change and should be done in a separate
commit) we may want to rename accept/cancel/revisit to
accept/drop/cancel. What do you think?

3) I also filed these:

http://smalltalk.gnu.org/project/issue/508
http://smalltalk.gnu.org/project/issue/509

509 is totally unimportant. 508 is a bit more urgent, but less than
sorting out the save widget. The widget is a step in the right
direction and it's fine to have it in 3.2.1 (compiler errors were
quite broken, or at least less usable than Squeak/Pharo) but it is
not finished and that's the priority.

4) Least important of all, the redesign of the sender/inspector
browsers. I think it would be nice to have the symbols expandable in the
left pane, and the expansion will hold the senders/inspectors of those
symbols. I'm not sure if GtkTreeModel supports on the fly loading of
rows as soon as the parent is expanded. I think not, so don't rush on
this. It can definitely be done past 3.2.1, or not at all. I just
included it in this email because you mentioned on IRC that you wanted
to have different kinds of sidebars.

Paolo

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

Yes, I just want to decouple it as much as possible from VisualGST (e.g.
no tools menu, etc.).

You can do that with the dialog box as well if you click "revisit".

For me, there was a big confusion the first time I saw the widget
because the selection is A but the source code widget shows B (which is
only described in the save widget itself).  This is different from any
other browser in existence.  I think we can get the best of both worlds. :)

>     Also, the save widget must work with all browsers. With my recent
>     changes I moved "accept it" to the GtkSourceCodeWidget, and this should
>     make it easier to refactor save widget stuff so that it works in the
>     debugger, inspector browser, SUnit browser, GtkLauncher, and regular
>     class browsers (sender/inspector should already be taken care of).
>
> In fact the save widget is used by the GtkTextWidget, so I think that
> should work anywhere but may be there are some other changes to do, I've not look.

Yes, maybe.  If you implement the widget properly in GtkLauncher I can
take care of the others.

>     3) I also filed these:
>
>     http://smalltalk.gnu.org/project/issue/508
 >
> For 509 this is normal I add the new stuff at the end, and for 508 it
> seems that I use the compile:classified:ifError and this message  doesn't
> care about the category, I think should only use the browser category
> and not
> the pragma (like in Squeak/Pharo), also that means that we need to support
> drag and drop for changing the category.

But well, until we have the drag and drop...  Anyway with your info
maybe I can look at it too.

I think there's an example in the GTK+ devel about it.  But it's the
least urgent thing of all.  Now we need to finish the save widget so we
can add another "tick" to the "this is why VisualGST is a modern browser
UI". :)

Paolo

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