Re: Layout Composite Widget Components Using Glade-3? / See Glade Only as Prototyping Tool?

["Tristan Van Berkom" <tvb gnome org>]

On Tue, Oct 21, 2008 at 7:25 PM, Daniel Yek <dyek real com> wrote:
[...]
> That (custom composite widget) is one approach I know of, but that doesn't
> allow me to manipulate the composite widget's children in Glade easily
> without more work.
>
> That is, if I stick to the standard GtkVBox, I can edit its children in
> Glade. Now, I am trying not to lose that ability when I subclass the
> standard GtkVBox to do minimal changes to it.
>
> If I subclass GtkVBox to add customized behavior in an object
> oriented/modular way, I am no longer using the standard GtkVBox and might
> not be able to use the same approach in manipulating this subclass's
> children.
>
> As it appears that there is a solution to allow subclassing of GtkVBox, but
> still fake it to be the standard GtkVBox, I will be able to use this
> technique to make my code more modular and reusable (within the project --
> I'm not intending to create widget library with this) and not to be
> "penalized" just for subclassing.

sigh, I am tired, I hope you have read the docs [1] thoroughly.

Whether you publish a widget library or not, if you want code support in the
plugin, the plugin will have to access your_object_get_type() and call it,
whether you take a good modular approach and actually build a library
with your app, is pretty much irrelevant.

If you want your composite custom widget's children to be editable
(i.e. allow the user to modify the properties of a child label or button ?
or even allow the user to add widgets to a child GtkBox ?) then you
have to sit in the post-create-function[2], and create a GladeWidget
wrapper using glade_widget_adaptor_create_internal()[3].

Then, depending on your usage of either GtkBuilder or libglade, you will
need to implement a get_internal_child(widget, internal_name) string
so that the parser will be able to retrieve the child object to add children
to/set properties on.

[...]
> > > I am experimenting with the parent-class construct...If successful, do I
> > > get a new tool icon in Glade-palette?
> >
> > Only if you included the <glade-widget-group> portion of the catalog.
>
> OK. This is working now -- I am getting a plain Glade-palette tool icon.
>
> I have more follow up questions though. I'm now trying to figure out what to
> do next...
>
> What functions do I need to implement to enable instantiation of the
> '<glade-widget-class name="FooBar">' composite widget?
> I.e., what libglade would call? Can that function be implemented to be
> compiled into the main application, so that I don't need to create a
> standalone .so file: <requires lib="somelib.so">?

Ahh this works differently in GtkBuilder, so for libglade I have to
say simply "no",
if you are instantiating your object from your app (compiled
--export-dynamic ofcourse),
from Glade & from libglade, then you'll need to either just remove the
<requires> string
from the glade file, or in libglade, call glade_provides().

> I'm thinking libglade would just treat the widget class as if it is a
> standard widget, so if the application registered the widget ahead of time,
> this will work.
>
> (I'm still experimenting with implementing this, but let me just send this
> email out to get answers on some of the questions.)

libglade will still require you to write a one line
glade_xml_register_widget() call
to use your class.... is there a reason you cant use GtkBuilder ?

> > > Any idea how I can get started with the approach of creating a composite
> > > widget in Glade that is basically just a GtkVBox with signal handlers
> > > custom
> > > code hooked up?
> >
> > what do you mean by "with signal handlers custom code hooked up" ?
> >
> > Do you mean your vbox does things with signals ? or it just provides new
> > ones for the user ?
>
> I goal is to create a source file for this composite widget and either
> overwrite the virtual functions to implement additional, customized,
> behavior, or hook up signal handlers to change the widget behavior, but keep
> the widget in its own source file to be modular.
>
> Does this goal make sense at all?

Sure, but I dont see how it plays in to the role of a glade plugin, if your
new object installs new signals, then glade will introspect them and allow
the user to set handlers on it.

> One related thought/doubt in my mind was whether Glade should only be
> thought of as a GUI prototyping tool and that projects having more
> modularity requirement will fare better to code the subclasses using GTK+
> API directly.

I am assuming that you are doing just that, writing a widget subclass, using
the gtk+ api directly, then compiling it - all we aim to do is put your widget
in the palette.

> I suppose one way to analyze this is to look at Glade source code itself and
> questioning why Glade application interface wasn't composed using Glade
> itself, but coded directly using GTK+ API? (Again, just figuring out
> things...)

I just havent taken the time, its a matter of writing a little catalog
to support
the editor widget, palette widget, inspector widget and design view widget,
and have glade3/src use GtkBuilder to load the core glade library.

I have things to do that will actually improve glade instead... but anyone is
welcome to come in and have a blast if they think that would be neat
(I think it would be neat...)

Cheers,
                         -Tristan

[1]http://glade.gnome.org/docs/
[2]http://glade.gnome.org/docs/gladeui-GladeWidgetAdaptor.html#GladePostCreateFunc
[3]http://glade.gnome.org/docs/gladeui-GladeWidgetAdaptor.html#glade-widget-adaptor-create-internal