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

[Colin Watson]

On Sun, Nov 29, 2020 at 07:21:54PM +0000, Steve McIntyre wrote:
> On and off, I've been hacking on tasksel for quite a while to improve
> the UI there and add better support for things like Blends. I've made
> some progress in my hacking, but I think I've hit a brick wall and I
> need to change tack. :-/
> 
> What I've ended up doing so far is hacking tasksel to give a poor
> *approximation* of a tree-style layout: classifying some existing
> tasks under headers and building a tree, then displaying each of the
> nodes of the tree one level at a time via the existing debconf
> setup. It just about works, but it's ugly as all hell and I'm not
> happy with where I've got to. I've sunk a lot of development time into
> this, but I don't think it's ready to fly this way. :-(
> 
> What I *actually* need here is proper support in debconf for
> tree-style selection. I'm thinking of adding that, adding new types
> "treeselect" as a tree-equivalent of "select" and "multitreeselect" as
> an extension of "multitselect". The first one may not even be needed,
> but would be a trivial simplification of the second, so *meh*.

grub2's maintainer scripts attempt to emulate something a bit like a
tree-style multiselect by putting "- " at the start of the partition
descriptions to indicate that they're under the disks.  It's certainly
not ideal; I'd be open to considering something better, although it
might take some time to be usable by packages in general.  (tasksel has
an easier time of it than some, since it's a full debconf-based
application rather than needing to work at the preconfiguration stage.)

> 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.

How were you imagining Choices working here?

>  2. Is anybody actually ever using the more obscure (to me!) frontends
>     (e.g. kde, editor)? Is it worth spending time there?

Although these require manual selection, I think they do have at least
some use, and I'd rather keep them going.  It shouldn't be too hard to
get full coverage, pulling in help from specialists if necessary.

-- 
Colin Watson (he/him)                              [cjwatson at debian.org]