GNOME Bugzilla – Bug 614473
Using named placeholders to make glade forward compatible
Last modified: 2010-12-16 20:20:43 UTC
1) Gtkbuilder & Gtk are moving targets There will always be new widgets and new Gtkbuilder DTD snippets. 2) Glade depends on catalogs Which might be too new or too old or missing (plugins/optional libs) 3) Because of 1 & 2 glade cannot and should not support all features available For example there is no point in having full native-custom-glade editor to create UIManager. (My opinion & sensing same point of view from the maintainer based on comments on bug reports here.) So to make sure that older Glade release doesn't whipe clean objects which it can't parse (but older glade can) and vice versa. Here is my proposal: Instead of using: </placeholder> Use: <placeholder name"$parrent-id-NN"></placeholder>, where NN is sequential placeholder Eg: <object class="GtkVBox" id="vbox1"> <property name="visible">True</property> <property name="orientation">vertical</property> <child> <placeholder name="vbox1-01"><placeholder/> </child> <child> <placeholder name="vbox1-02"><placeholder/> </child> </object> Benefits: 1) Allows plugins. This will make standard glade produced gtkbuilder files be extended via plugins. 2) Newer constructs can be separated in a different file such that you can merge one file when building against gtk2.20 & gtk2.22. 3) Exotic GtkBuilder features can be written by expert developers and still use glade for majority of project. 4) Future & Backwords compatability by splitting newer stuff in separate files. Code Changes: 1) This will be handled just like current placeholder, transperent to the user. User cannot edit the name (it will be reset to this $parent-id-XX on changes / load & safe). 2) Glade DTD should be updated (Yes, No, please advice) 3) Placeholder parsing & writting will needs to be altered. I did read quite a bit of glom code to get the feel for this. As far as I see this is very close to current glade's handling of placeholders. I would want to work on this, but I'm quite limited in my gtk/xml skills. Pointers at where to look for functions which need changes are welcome. Please let me know if this proposal makes sence and if something has been overlooked. Any help in implementing this is also welcome. I think I can manage it on my own but it will take long time for me cause I haven't done any C/Gtk development before. (I did do C & PyGtk before though). Thanks.
I think you are trying to add something which is already addressed. The GtkBuilder format is extendable and as such you can define your own constructs for GtkBuilder in the GtkWidgets that you write. If you want for example to define a custom builder construct in your library, then you can do it and you can make it editable in Glade by doing the normal catalog and further implementing the cataloged widget's read_widget/write_widget function. For instance, looking at benefits 1, 2, 3 and 4 you listed: (In reply to comment #0) > Benefits: > 1) Allows plugins. This will make standard glade produced gtkbuilder files be > extended via plugins. Currently is already the case, the GtkWidget implementation defines its own customized builder format (this is the main advantage over libglade). > 2) Newer constructs can be separated in a different file such that you can > merge one file when building against gtk2.20 & gtk2.22. That we dont have and IMO we dont want, we protect versions by setting a target version for each included library/catalog... GtkBuilder is supposed to fire a signal letting you fail the parse in the case of unpassed version checks for your libraries (I just didnt write the patch yet since not many people are using catalogs, more people include widgets into their app directly). > 3) Exotic GtkBuilder features can be written by expert developers and still use > glade for majority of project. If they write proper Glade support for their fancy widgets, (and I wrote lots of documentation for it, it shouldnt be a problem to do for these widget authors really) - then they can already use exotic builder formats and still use Glade for 100% of the project including their own fancy widgets. > 4) Future & Backwords compatability by splitting newer stuff in separate files. Again, we have target versions for that, I really dont think developers what to keep there Glade file stored in 3 glade files instead of 1 well version encoded file
[...] > So to make sure that older Glade release doesn't whipe clean objects which it > can't parse (but older glade can) and vice versa. Here is my proposal: The way I want to address that is at the xml load/save level, Glade needs to hold on to unrecognized attributes and unknown object children at load time, store them as added unrecognized data on the loaded widgets and then reapply them at save time. I think/hope there is another bug open for that...
*** This bug has been marked as a duplicate of bug 376628 ***