On Tue, Oct 21, 2008 at 7:25 PM, Daniel Yek <[EMAIL PROTECTED]> 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 _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list