[Glade-devel] Embedding glade in other applications (like IDE )

[johnp martianrock com (John (J5) Palmieri)]

On Thu, 2004-01-08 at 10:54, Damon Chaplin wrote:
> On Wed, 2004-01-07 at 17:37, Paolo Borelli wrote:
>
> > Note however that generating code is a _bad_ idea also with the current
> > glade-2 and it is strongly discouraged.
>
> I think for large projects with multiple developers libglade is probably
> a better idea (though I think you can work around the problems with
> generated code if you need to).
>
> But for small projects I don't think it really matters too much. Lots of
> people have built apps using generated code.
>
> One current advantage of generated code is that you can just click on
> 'Build' and you get a complete app ready to compile and run.
This is the job of an IDE not glade so in that sense it is wrong but
since no IDE's currently integrates Glade I aggree for some it is a good
thing to have however even in small projects changeing some layout and
rebuilding has the potential of overwritting other changes.

> There are also other issues with libglade that need resolving:
>
>  o libglade works best if you keep each window in a separate XML file,
>    but Glade is currently oriented to keeping all windows in one file.
>    (Glade-3 is probably the same.)

I'm not sure this is true.  When I use libglade I usualy load everything
in the beginning, assign the widgets I am interested in to structs and
discard my XML.  One file works within this framework.  Again I think
this is an IDE issue since glade can work either way.  What would be
nice is the ability to create aggregate widgets without a top level
window.  This would allow visualy creating menus and toolbars that would
later be used for plugin UI merging.

>  o signal connection, which I just mentioned in another mail.
>    This has to be done automatically to be used in a decent IDE,
>    where you will also be able to type in signal handler code.
>    Why did you suggest doing it manually, Paolo?

Again this is an IDE issue not Glade.  Glade just needs an API that
exports a create or change callback signal.

>  o I'm still not quite sure about memory management issues in libglade.
>    e.g. the glade_xml_new() docs say that the parse tree is cached,
>    and indeed the GladeInterface is kept around. But I can't see where
>    that is reused. Where is that code? Is it possible to clear the
>    cache?

Unref the GladeXML object?  I'm not a big fan of keeping libglade around
after information is pulled out of it.  At that point you have the
widget tree and the XML tree inmemory but I guess if it is cached the
situation is much better.

>    Also, if I call glade_xml_new() with no root node, does that mean
>    that one instance of every window is created. That could lead to
>    wasted resources, since many windows may not be needed.

It depends on your project.  Big projects might get a boost in
performance by managing their resources better.  Small projects often
don't want to deal with it so they load every window and use hide and
show instead of creating and destroying dialogs .   It is a tradoff
between speed of development/speed of responsivness vs. memory
requirements.

--
J5