[Help-smalltalk] Re: visualgst plans

[Paolo Bonzini]

>     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?
>
> We can put it on a separate package, that can be interesting to have
> an HTML renderer for browsing the doc (gtk+, or GNU Smalltalk ;-) ,
> or editing HTML (it is possible to do it with Webkit)

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

>     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.
>
> With the tabs this widget popup is nice: you can switch on other tabs, or
> open other tools. But if we close the tool (window) or a tab displaying a
> dialog box is better I think.

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.

>     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.
>
> Nice idea, I don't know if it is possible to do with the GtkTreeModel, but
> the idea is nice.

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