[Top][All Lists]

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

[Help-smalltalk] Re: visualgst plans

From: Paolo Bonzini
Subject: [Help-smalltalk] Re: visualgst plans
Date: Tue, 22 Jun 2010 14:56:02 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20100430 Fedora/3.0.4-3.fc13 Lightning/1.0b2pre Thunderbird/3.0.4

    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 

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

    3) I also filed these:
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". :)


reply via email to

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