Hi,
Please excuse my out of context reply, I happen to have read the
email and I can't resist... actually I received the email from another
mail account I've been having trouble with, so I can't properly
reply to that composer port thread.
On Tue, 2012-09-04 at 12:08 -0400, Matthew Barnes wrote:
> On Sun, 2012-09-02 at 00:16 +0200, Dan Vratil wrote:
[...]
>
> > EEditorDialog* - implementations of all the dialogs. I decided to throw away
> > the Glade file and single .c with implementation of all the dialogs
> > because it completely violates all principles of OOP and because I have
> > to provide my own implementation of most of the actions in the dialogs
> > anyway, so the single signals file would be huuuge and ugly.
>
> +1 - Nowadays I think XML UI definitions are more trouble than they're
> worth. Plus GtkBuilder still has problems handling single-letter
> type name prefixes (e.g. "E"), so using our own custom widgets in
> our own XML files requires frequent ugly hacks. Not worth it.
Please, this model of programming with glade files is over 10 years
old and I think we all agree that it's inefficient.
Until we merge composite-templates branch into GTK+ (which will
essentially allow you to assign a glade file to any GtkContainerClass
and automate much more of the process of writing UIs), there are still
good ways of using GtkBuilder script with good OOP design principals.
In a nutshell, Glade files should be loaded by the composite object
class in it's ->constructor() method so that it is completely
wrapped into an object class (and then even reusable in other
Glade files).
In case it helps; I'm attaching a small tarball which is
essentially a demo of good practice with GtkBuilder (I had it
handy from a talk I gave last year).
The contents are:
o my-demo.[ch]: A simple composite object class
o my-demo.glade: A Glade file defining the composite children of the
MyDemo object
o demo.xml: A Glade catalog to include the MyDemo object created with
Glade xml (you can place this in a directory with all of your
custom Glade catalogs defining your custom widgets and
start Glade with GLADE_CATALOG_SEARCH_PATH env var
pointing to a directory with your local catalogs,
the created libdemo.so needs to be installed in
a standard search path or optionally in a directory
indicated by the GLADE_MODULE_SEARCH_PATH env var)
Again, sorry for the sort of off topic reply. I realize that my
blathering on will not cause you to have time for a refactor, just
thought I had to mention that Glade files by themselves do not go
against OOP design... if you put all your UI definition into one
XML file and handle all callbacks in one C file, that's another story.
Best Regards,
-Tristan
Attachment:
demo.tgz
Description: GNU Zip compressed data