Hey "Joaquin Cuenca Abela" <[EMAIL PROTECTED]> writes:
> Hi! > > Tommi wrote: > > > > Hi, > > > > Please find attached a patch that moves loading of the > > library module before the call to foo_get_type() that's > > supposedly in that library. > > With the patch I was able to get custom widgets to appear in > > glade palette. > > Thank you for the patch, but unfortunately it's not correct (even if you're > right when you say that without it custom widgets don't work). > > The "library" variable refers to the name of the library that contains the > special functions that may be needed by glade-3 to handle specially some of > the widgets contained in the real library. > > Let me explain it with an example. > > Let's say that you want to add support for a library that contains a widget > named foo. We will call this library libfoo.so. > > If you're lucky, you should be able to add support for this library just > adding an entry to glade-palette.xml and gtk-base.xml or gtk-additional.xml > (or eventually another special xml file, let's say gtk-foo-catalog.xml). > > If you need some light customization of the handling of this widget by > glade-3, you can do it with an special xml file that will be indicated in > gtk-foo-catalog.xml. One example will be to ignore some property in > "edition" mode, like "visibility" (however you don't need to handle > specially "visibility" as it's already done in gtkwidget.xml, and these > things inherite). Another example will be to change the default value of > some properties, when you can't change it in the widget itself (for example, > because you want to retain backward compatibility). > > And, in the worst of cases, you will need to add special code to handle your > widget (usually neccesary, but not limited to, containers, for instance, as > you have to add programatically some placeholders here and there). That > special code should go in a special library, with a name derived from the > name specified in the "library" attribute of your GladeCatalog (it should be > named "libglade" + library attribute, and it should go in the MODULES > directory of glade-3). It our case it may be libgladefoo.so. > > That's the library that it's loaded by g_module_open in the code that you > move with your patch, and it's unrelated to the library that contains the > real Foo widget. Intriguing, knew all that but never bothered to comprehend it all in on gigantic piece. Nice :-) > > As you see, there's a missing piece, and it's the code that loads the > library that contains the Foo widget, as you need it to call the > foo_get_type function. That is, AFAIR, the only missing thing to make the > plugable widgets really work. That is already done! Why that was infact my first patch to glade-3 (back when it was still called glade-2) :D. You can take a look in glade-widget-class.c There is some code like, glade_widget_class_get_get_type_func or something. Tommi... wanna take a shot at it :D > > If you can cook a patch to load that library, it will be great. > > I was thinking about having a special attribute in GladeCatalog to indicate > the name of the "main" library (libfoo.so), and not reusing the "library" > attribute for both libraries. Cheers! Archit Baweja _______________________________________________ Glade-devel maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/glade-devel
