Re: [gtkmm] Is there plug in support?

>You might want to start with 
>but I think for the most part this is something that is up to the individual
>programmer's needs and desires.

warning: glib's module code (at least as of glib1.2, i haven't checked
in 2.X) uses RTLD_GLOBAL when it loads shared objects. this can have
nasty effects if the plugins don't know that this is coming.

>I have a base class, and from that I derive a plug in.  At run time, I
>somehow load the object file (maybe it sits in a plug in directory of
>which all files within are loaded and presentable in a gtkmm program for
>selection by the user), query it for properties, allowing the user to
>set those properties (and the program then setting them by sending back
>to the object the property name and value), then call the run() method
>of that plug in, which then uses those just previously set properties to
>do something.  

designing plugin APIs is not a small thing. although what you have
described covers the basics of it all, there is a lot of work and
often domain-specific work involved in defining a complete API. the
work the audio software community has done on this is probably as
advanced as anything (since most interesting new audio software these
days is written as a plugin), and the APIs that we use are really
quite complex (certainly more than you outline above).


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]