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

Re: cdebconf plugins (custom widgets)

Colin Watson wrote:
> There are a few open questions remaining:
>   * With this design, udeb code is likely to look something like "if
>     this all-dancing widget is supported, then use it; otherwise, do it
>     by hand pretty much the way it looks at the moment". My sample
>     implementation exports the list of supported plugins as "plugin-foo"
>     capabilities in the CAPB response, but I wonder if a new SUPPORTS
>     command (so you could do "db_supports whizzy-new-widget") mightn't
>     be better. On the other hand, that's more client-side divergence
>     from debconf, and maybe a simple /bin/debconf-supports command would
>     be simpler.

I actually like the capb approach. I think we may eventually want to
expand it so a given widget can cause multiple capbs to be set.

>   * I envisage custom widgets being fairly complex in some cases, with
>     several items of data being returned at once: for example, consider
>     a combined language/country chooser widget that dynamically updates
>     the list of countries presented as you change the selected language,
>     or something like that. It's hard (and arguably a bad idea) to put
>     much structured data in a single question, though. I don't have a
>     clear answer to this at the moment; maybe the right approach is for
>     a complex widget to register extra templates for itself, and just
>     put the answers there, so that 'db_input foo/whizzy' gives you
>     answers to foo/whizzy/language and foo/whizzy/country, or something
>     like that.

Well you could implement the container question type (see versions of
the debconf spec before it was removed). Then you have essentially,
nestable structs of questions.

> The required prototype for this function depends on the frontend. For newt
> and text, it is (again with hyphens in <type> substituted with underscores):
>   int <frontend>_handler_<type>(struct frontend *obj, struct question *q)
> For gtk, it is:
>   int <frontend>_handler_<type>(struct frontend *obj, struct question *q, GtkWidget *questionbox);

Maybe mention that the return code is DC_OK or DC_GOBACK.

see shy jo

Attachment: signature.asc
Description: Digital signature

Reply to: