Re: Implementing plugins in the GTK frontend
Colin Watson wrote:
On Mon, Jan 30, 2006 at 02:23:55AM +0100, Attilio Fiandrotti wrote:
today i carefully red the plugins documentation and i finally understood
they are meant to replace a question handler basing on the question's
"type" and not "tag" field.. doh! :(
I suppose i won't be able to move out of the GTK frontend the handlers
for "countrychooser/country-name" nor "partman/choose_partition" unless
a plugin system per-question-tag is implemented or the countrychooser
and partman are modified to ask a, respectively, "country-name" and
"choose_partition" type of questions.
IMHO, it's usually a bad idea to do anything on the basis of question
names in cdebconf; question names belong to the package asking the
questions, not to cdebconf or even to cdebconf plugins, and might change
at any time. That said, I suppose if the plugins were added to the
source packages owning the questions (which is the right way to do it
anyway), then it would be OK to make them per-question-name.
Luckily, there are only two special question handlers hardcoded inside
cdebconf's GTK FE, but of course i would like to clean up the GTK
frontend as much as possible (hardcoded hacks were meant to be
tempoarary only).
Anyway, if someday partman/choose_partition should ever change in
something else for any reason, nothink would stop working: the default
SELECT handler would take the place of the specific hardcoded frontend.
I red that there are plans to replace debconf (written in perl,
graphical frontend GNOME-based ) with cdebconf: in this case the GTK fe
still needs a lot of polishing that i would be hapy to do.
My intention when designing the plugins interface was to have packages
check for a plugin capability using CAPB, and if they find that the
plugin they want is present then they can ask a *different* question
with a suitable type. (You can't change the types for
countrychooser/country-name or partman/choose_partition because then
other frontends wouldn't know what to do with them, but you can modify
localechooser and partman-base to ask different questions if some
appropriate plugin is there.)
Adding plugin support per-question-name ( = per-question-tag) may be
useful, as a client (e.g. : partmat) may remain simpler as wouldn't
have to query explicitly the server (cdebconf) for a plugin, but placing
GTK (or NEWT or something else) pieces of code inside the client package
(e.g. partman) may be a bad idea.
Plugin support per-question-type (the actual design) puts more
complexity into the client app (e.g. : partman) that does have to
explicitly ask the frontend if a special handler is supported, but for
sure the overall design is much more clean and plugin code stays inside
its frontend package instead that inside the client's.
A thing i was planning to do in the future is creating a plugin that
shows a worldmap like the Gnome's timezone choosing app does: in this
case the actual plugin mechanism could be very useful if applied to
clock-setup.
ciao
Attilio
Reply to: