[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debconf - adding "treeselect" type(s)?



On 03/12/2020 03:48, Steve McIntyre wrote:
> Thomas Goirand wrote:
>> Otherwise, what would be the way to describe a tree?
> 
> I'm playing with ideas so far, let's see shortly. :-)

I have an idea to do this without new types but I'm not sure how
feasible/suitable it is. I'd define the template names to be a tree and
ask the frontend a bundle of them at the same time, where the frontend
would render these in a tree if it understands the tree structure or
show multiple questions if it does not.

For some example templates:

    Template: foo/bar
    Type: multiselect
    Choices: a b c

    Template: foo/bar/a
    Type: select
    Choices: 1 2

    Template: foo/bar/b
    Type: multiselect
    Choices: x y z

    Template: foo/bar/b/x
    Type: select
    Choices: d e

(This would not work if it's being mapped to the filesystem in some way,
foo/bar would impossibly need to be both a file and a directory. But it
may be mitigable by using e.g. foo/bar:b, foo/bar:b:x instead of the
last two templates.)

We could call something like:

    db_input foo/bar
    db_input foo/bar/a
    db_input foo/bar/b
    db_input foo/bar/b/x
    db_go

Then, frontends could arrange them however they want it best. They could
show/hide child choices with a frontend-specific mechanism:

    foo/bar:        foo/bar:        foo/bar:        foo/bar:

    [ ] a           [ ] a           [ ] a       ->  [ ] a
        [ ] 1           [ ] 1           [ ] 1       [ ] b
        [ ] 2           [ ] 2           [ ] 2           [ ] x
    [ ] b      ->   [ ] b           [ ] b                   [ ] d
    [ ] c               [ ] x  ->       [ ] x               [ ] e
                        [ ] y               [ ] d       [ ] y
                        [ ] z               [ ] e       [ ] z
                    [ ] c               [ ] y       [ ] c
                                        [ ] z
                                    [ ] c

(I thought of using selection to show the children, but the grub2's
whole-disk-vs-partitions concern applies to that as well.)

Alternatively, things would fallback to individual questions if the
frontend can't recognize that we wanted a tree:

    foo/bar:   ->   foo/bar/a:  ->  foo/bar/b:  ->  foo/bar/b/x:

    [ ] a           [ ] 1           [ ] x           [ ] d
    [ ] b           [ ] 2           [ ] y           [ ] e
    [ ] c                           [ ] z

(One problem about this fallback would be asking too much questions for
localechooser, e.g. one question for each language)


Reply to: