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 [email protected] http://lists.gnu.org/mailman/listinfo/help-smalltalk
