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

[Damon Chaplin]

On Thu, 2004-01-08 at 16:18, John (J5) Palmieri wrote:
> On Thu, 2004-01-08 at 10:54, Damon Chaplin wrote:

> >  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.

Keeping all windows in one file is OK for small projects, but not for large
apps:

 1) You may have lots of developers, so you may get lots of conflicts
    with the .glade file.
 2) You will be wasting resources, since lots of the windows won't
    be needed, and it may take a while to parse the file on startup.

I think using separate files for each window is the way to go.
(We can still support the other option, but just not recommend it.)


> >  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.

Yes, but we need a standard way to connect signals, that we know works
across all our supported platforms.

It could use symbol lookup, as libglade does now, or it may mean the IDE
generating code to handle signal connection.


> >  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.

I think libglade is used in too many different ways - one/multiple
windows per glade file, automatic/manual signal connection,
keeping/freeing the GladeXML object.

We should just have a standard way to use libglade that is fine in 99%
of projects. That makes it easier to maintain and reuse the code.

Damon