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

[Daniel Yek <dyek real com>]

[Apologize for being lengthy, but at least I'm trying hard to be clear...]

Tristan Van Berkom wrote:
> ok for the sake of this conversation: you are trying to integrate your 
> custom
> widget into glade, 

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.


> the fact that it is a composite widget is of little
> consequence;
> lets start by getting your instance running in glade and your
> properties introspected.

> Scratch my previous comment about a feature we never wrote, its
> irrelevant here...

I suppose that refers to this following previous comment?
> > in trunk you are allowed non GtkWindow toplevel objects, and you are
> > allowed to use a more lax naming scheme - so it can be as easy as 
> defining some
> > widget layouts in glade... and then the art is how you parse it with 
> gtkbuilder.

> > I found this posting to be informative and mostly answered my question:
> > http://lists.ximian.com/pipermail/glade-users/2007-October/003647.html
> > http://lists.ximian.com/pipermail/glade-users/2007-October/003648.html
> >
> > However, the testcatalog.xml in the blog is no longer available:
> > http://www.gnome.org/~tvb/testcatalog.xml 
> > <http://www.gnome.org/%7Etvb/testcatalog.xml>
> > http://blogs.gnome.org/tvb/2007/07/25/some-popular-features/
>   
> My fault I cleaned up my home dir... I posted on in its place just for 
> you :)

Thanks.

> > 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">?

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

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

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

Thank you very much.

--
Daniel Yek.