cdebconf plugins (custom widgets) --------------------------------- cdebconf has the facility to load custom implementations for template types at run-time. This may be used to provide more sophisticated user interfaces than can be achieved using the standard generic template types. Naturally, these implementations are per-frontend. The CAPB command may be used to query the existence of a given plugin for the current frontend. If the type "foo" is supported by a plugin, CAPB will return the capability "plugin-foo". Plugins are dynamically-loaded libraries. The library must be in the following location: //plugin-.so (The initial "plugin-" is to allow for more convenient testing within the cdebconf source tree.) In the default cdebconf.conf, is /usr/lib/cdebconf/frontend. Thus, an implementation of the "detect-keyboard" type for the newt frontend would be stored in: /usr/lib/cdebconf/frontend/newt/plugin-detect-keyboard.so The library must provide a function with the following name: cdebconf__handler_ Any hyphens in here are substituted with underscores, so: cdebconf_newt_handler_detect_keyboard The required prototype for this function depends on the frontend. For newt and text, it is (again with hyphens in substituted with underscores): int cdebconf__handler_(struct frontend *obj, struct question *q) For gtk, it is: int cdebconf__handler_(struct frontend *obj, struct question *q, GtkWidget *questionbox); The handler should return DC_OK (defined in common.h) if all went well, DC_GOBACK if the user wants to back up to the previous question, or DC_NOTOK if an error occurred. Plugins should generally use exported functions instead of dereferencing structs directly where possible. You can find the exported functions in the headers in /usr/include/cdebconf You might want to look at existing plugins to see how things are done: cdebconf-keystep (http://archive.ubuntu.com/ubuntu/pool/main/c/cdebconf-keystep/) cdebconf-entropy (http://ftp.debian.org/debian/pool/main/c/cdebconf-entropy/)