After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 345446 - Project options and conversions
Project options and conversions
Product: glade
Classification: Applications
Component: general
Other Linux
: Normal normal
: ---
Assigned To: Glade 3 Maintainers
Glade 3 Maintainers
: 352062 (view as bug list)
Depends on:
Reported: 2006-06-20 16:36 UTC by Tristan Van Berkom
Modified: 2008-04-09 18:31 UTC
See Also:
GNOME target: ---
GNOME version: ---

Description Tristan Van Berkom 2006-06-20 16:36:36 UTC
   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.
Comment 1 Tristan Van Berkom 2006-08-19 18:40:57 UTC
*** Bug 352062 has been marked as a duplicate of this bug. ***
Comment 2 Thomas Rydzynski 2006-08-19 18:58:19 UTC
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.
Comment 3 Vincent Geddes 2006-12-04 21:40:47 UTC
>    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.


Comment 4 Tristan Van Berkom 2008-04-09 18:14:01 UTC
implemented in trunk, closing.
Comment 5 Tristan Van Berkom 2008-04-09 18:31:33 UTC
implemented in trunk, closing.