On Mon, Nov 30, 2020 at 10:18:05AM +0000, Steve McIntyre wrote: > Colin Watson wrote: > >On Sun, Nov 29, 2020 at 07:21:54PM +0000, Steve McIntyre wrote: > >> AFAICS I'd need to add at least basic support for the new type(s) into > >> all the frontends that *can* support it. So, I have a couple of > >> questions: > >> > >> 1. How flexible is Debconf at coping with a frontend not including > >> support for a type?? > > > >Not hugely. The INPUT command would return an internal error with the > >text "unable to make an input element". I think we'll need at least > >minimal support across all the frontends, which may need to inform the > >design of the element. > > Bah, I was afraid you were going to say that. :-( > > For frontends that can't meaningfully deal with a tree (like > showing/hiding sub-trees), I think the best way is to maybe just > display the entire tree and treat it as the equivalent > select/multiselect. It's not great, but at least it should work.
Agreed. That shouldn't be too much work. > >How were you imagining Choices working here? > > I'm envisaging treating the Choices *mostly* like in an existing > select/multiselect, but with extra decoration to indicate the position > in the tree for display. It would then be up to the frontend to decode > that and work out a sensible way to display things as best it can. Not > sure on the best way to do the decoration, hoping there'll be an > available special character or similar that we could use in strings to > avoid too big an upheaval here. Since the question type is new, you'd have room to define this. I worry a bit about how in-band decoration would interact with localisation, though - it would be easy for translators to accidentally break the tree structure, and potentially difficult to spot. An alternative might be to have the contents of each subtree listed in a different field somehow. But I'm not sure - it may be worth prototyping a couple of different approaches. -- Colin Watson (he/him) [cjwat...@debian.org]
