Jon A. Cruz wrote:
- id-clashes.cpp - this is a stopgap solution at best...
Probably the #1 first step here would be to remove the legacy behavior of adding an id attribute on every object.
This is a good idea in itself, but I think it's rather loosely related to the original problem - all defs still need an ID if they are to be used anywhere, and it's the defs that cause the ID collision problems.
Converting to C++ is good, but it wouldn't get rid of the need for toolbox.cpp.
With an action-based UI, why not have virtual methods that register the actions and build the interface? Most of toolbox.cpp functionality would be split between the tool classes. The remaining few bits could be handled by the base class or a separate controller object. Probably the toolbox widget would need extensive modification but I believe it is possible to separate everything into independent tool objects.
Jon A. Cruz wrote:
Please note that we have garbage collection as a factor, so eating memory may or may not be a leak. Tracking info down needs to keep this in mind.
In the memory dialog the standard malloc value keeps increasing over time even when nothing is done. On the other hand, the libgc value doesn't change. Maybe the changing values are due to the reallocation of strings for display in the memory dialog and there is no leak at all?
Jon A. Cruz wrote:
GtkUIManager *can* do dynamic UI, but its XML has taken the wrong approach. It's a very pixel-tweaking oriented approach, which is quite different from what we need (a more abstract representation).
I don't know about any pixel-tweaking in GtkUIManager, or for that matter any presentational things except separators. (See UI Definitions in the link below). http://library.gnome.org/devel/gtk/stable/GtkUIManager.html
Regards, Krzysztof Kosiński