Re: Debconf - adding "treeselect" type(s)?
Colin Watson wrote:
>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.)
Yup.
>> 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.
>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.
>> 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.
I guess so.
--
Steve McIntyre, Cambridge, UK. steve@einval.com
"You can't barbecue lettuce!" -- Ellie Crane
Reply to: