[Debconf-devel] Debconf - adding "treeselect" type(s)?

[Colin Watson]

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)                              [cjwatson at debian.org]