GNOME Bugzilla – Bug 345446
Project options and conversions
Last modified: 2008-04-09 18:31:33 UTC
Ok, Gtk builder is comming... we are supporting all widgets including gnome catalogs and depricated gtk+ widgets... and we will be supporting load and save in both formats; we need a system that is going to define what widgets, properties, signals are valid for which format etc etc... Here is a description of my vision of the feature that is going to handle all of this stuff: o GladeProject will have to maintain a list of options... these options will include: - catalogs that are required by the project - formats that currently support this project - minimum Gtk+ version this project is targetting - allow the use of depricated widgets or not o There should be a dialog with the user upon creation of new projects that decide the base project options o Features in the glade UI will have to conform to the afore mentioned options: - widgets in the palette or "add" submenues that do not conform to the project options should be marked as such but not be insensitive... Adding a widget that doesnt conform should trigger a popup asking the user if they wish to modify thier project options to conform to this new object. - properties & signals should be handled the same way... if an unconforming property is changed from its default... or an unconforming signal be added... the same dialog should show. (properties and signals should also indicate that they do not conform by showing a special icon or displaying its text in a special colour). o Project Options should be able to change at any time: when changing any project options: - if the current project does not conform to the target options then a list of objects/properties/signals that do not conform to the target options should be displayed with some indication of why they do not conform (i.e. "not available in gtk+-2.8", or "only available in gnomeui catalog") - the user at this point should have the option of pressing a single button that deletes all project objects & signals that do not conform (and default all properties that do not conform). objects that *do* conform but are children of objects that do *not* conform will be removed as a side effect of this feature. - Changing project options must be an undo/redo'able action (especially when it involves autodeleting of properties/objects). o Versioning metadata will have to be added somehow... at this point I am not entirely sure how this should be done; it can be done by adding "since" tags/properties in the right places in the catalog. The reason I am weary of doing that is because gtk-doc gets this information straight from the gtk+ sources... so we should first explore any possabilities of introspecting versioning information before we resort to hard-coding it into the catalog.
*** Bug 352062 has been marked as a duplicate of this bug. ***
IMHO versioning metadata can or even should be hardcoded. 1) You will not need sources of gtk when building catalogue - important if it is done (i don't know) when compiling/installing glade at user's system. 2) Information in the source can get corrupted accidentaly, for example with some typo, or be not available at all. 3) It does not change often and new widgets are hardly ever (never?) backported to previous gtk versions so there will be no problem with sync. On the other hand, some extraction tool can useful to glade catalogue developers anyway.
> Gtk builder is comming... we are supporting all widgets > including gnome catalogs and depricated gtk+ widgets... and > we will be supporting load and save in both formats; we need > a system that is going to define what widgets, properties, signals > are valid for which format etc etc... Good, but I am against the idea of supporting both formats equally. We can however, take a pragmatic approach, let me explain... As soon as GtkBuilder lands in GTK+, the libglade format will marked as deprecated and. Why should Glade support a legacy format fully, especially if nobody is going to use it for new projects in 2007? If people need to use libglade for a legacy code, then they can always use versions 3.0 or 3.2 of glade. IMO, Glade 3.4 should only support GtkBuilder for normal operation, with the ability to convert to and from the old libglade format at load/save time. Glade will do the conversion without any guarantees on whether a libglade feature is loaded or saved successfully. So in the Save/Open dialogs there will still be the option of saving/opening glade files. My main argument about supporting both formats equally is about user interface design (usability) and architectural complexity. For example, if we support both formats, we would need a menu editor for GtkBuilder/GtkUIManager/GtkAction, and another one for libglade. That's not really good for users and it's not good for us developers, as we would have to develop and support dual implementations of components. Some of the tasks relating to supporting dual formats outlined in your message also look like they will incur a heavy burden on glade's architectural complexity. Think about this - If go ahead and support libglade fully, looking 2 or 3 years into the future, it's quite probable that someone will want to go ahead and remove glade's support for the old forgotten libglade format. discuss
implemented in trunk, closing.