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