One option would have been to create a brand new Bonobo component by
defining an interface in IDL and compile it with
ORBit's IDL compiler.
This would have required applications willing to use this component
to link against the ORBit-generated stub code.
I preferred a more straightforward approach: reuse the existing
Bonobo/Control interface and implementation, and define the control's
interface with a
property bag.
The following properties help you configure the control:
- setModulesConfFile: set this string property to the location of the
modules.conf file. Default: /etc/modules.conf
- setLanguage: set this string property to the 2 characters code that
represents the language to use
- setVerbosity: for debug purposes, set this short property
to the desired verbosity level
The following properties trigger certain actions when set:
- showModule: set this string property to the name of the module
to display in the control's notebook widget
- installPackage: set this string property to the URI of a
DKMS package
(tarball or RPM) to install, or set it to an empty string. This brings
up the DKMS installation manager dialog
- unInstallPackage: set this string property to the name of a
DKMS package to un-install (not implemented yet)
- saveOptions: set this property (no type) to make the control
save all the unsaved options changes to (by default) the
/etc/modules.conf file
The following properties can be queried:
- getModuleUsage: querying this string property returns the usage of
the currently displayed module
- hasUnsavedChanges: querying this bool property returns whether
there are any unsaved options changes
In addition, the control uses a Bonobo Event Source to
feed back messages to the client embedding it. Applications are encouraged
to register a Bonobo Listener to catch those messages. For
example the gmodconfig application listens to those messages and
displays them in its status bar.
|