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)
Re: Debconf - adding "treeselect" type(s)?
Thomas Goirand wrote: >On 11/29/20 11:37 PM, Timo Weingärtner wrote: >> >> Would checking "a" automatically also check "a/*"? >> Is it only about UI, meaning "a/*" would be collapsed under "a"? >> Shall it be possible to check "a", but uncheck "a/b"? >> >> GrüÃe >> Timo > >I very much agree that this needs to be discussed, then specified correctly. I think I've been clear on this bit in the thread? What's missing? >Also, would that sound crazy if we were to introduce the tree as >described with json? That's simple enough, so that even a human can do >it by hand, and also understood by all languages. json is all well and good for more powerful languages (and yes, I'd be convinced there!), but nigh-on impossible to do reliably in shell AFAICS. Shell is (one of) the most common environments for driving debconf, in package config and postinst scripts. I don't think that's going to fly. Oh, except... We'd only have to generate the json from shell, not parse it. That may be more tractable. Thanks, that could be a good suggestion! >Otherwise, what would be the way to describe a tree? I'm playing with ideas so far, let's see shortly. :-) -- Steve McIntyre, Cambridge, UK.st...@einval.com "You can't barbecue lettuce!" -- Ellie Crane
Re: Debconf - adding "treeselect" type(s)?
Thomas Goirand wrote: >On 11/30/20 11:18 AM, Steve McIntyre wrote: >> 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. > >å§ [1] Maybe... >>> 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. > >How would it be pre-seeded? Just like a multiselect? With only leafs >that could potentially be in the pre-seed? That's exactly my plan, yes. The non-leaf bits are just syntactic sugar for the UI. -- Steve McIntyre, Cambridge, UK.st...@einval.com "You can't barbecue lettuce!" -- Ellie Crane
Re: Debconf - adding "treeselect" type(s)?
On 11/30/20 11:18 AM, Steve McIntyre wrote: > 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. 囧 [1] >> 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. How would it be pre-seeded? Just like a multiselect? With only leafs that could potentially be in the pre-seed? Cheers, Thomas Goirand (zigo) [1] https://www.urbandictionary.com/define.php?term=%E5%9B%A7
Re: Debconf - adding "treeselect" type(s)?
On 11/29/20 11:37 PM, Timo Weingärtner wrote: > What are the proposed semantics of this multitreeselect? > > If we imagine something like: > > [ ] a > [ ] a/b > [ ] a/c > [ ] b > [ ] b/a > > Would checking "a" automatically also check "a/*"? > Is it only about UI, meaning "a/*" would be collapsed under "a"? > Shall it be possible to check "a", but uncheck "a/b"? > > Grüße > Timo I very much agree that this needs to be discussed, then specified correctly. Also, would that sound crazy if we were to introduce the tree as described with json? That's simple enough, so that even a human can do it by hand, and also understood by all languages. Otherwise, what would be the way to describe a tree? Cheers, Thomas Goirand (zigo)
Re: Debconf - adding "treeselect" type(s)?
Timo wrote: >-=-=-=-=-=- > >Hallo Steve McIntyre, > >30.11.20 16:36 Steve McIntyre: >> I'll admit that I'm thinking of this *mostly* in terms of the needs of >> tasksel so far, but I'd expect switching to a new template type is >> likely to need a rethink to make best use of them anyway. > >In my mind there is also locales where we should have three levels: >de > de_AT > de_DE >[ ] de_DE >[ ] de_DE@euro >[ ] de_DE.UTF-8 >en > en_DK > en_GB > en_US ACK. For the tasksel work I'm also looking at a 3-level tree to organise the Blends stuff, at least. -- Steve McIntyre, Cambridge, UK.st...@einval.com "You can't barbecue lettuce!" -- Ellie Crane
Re: Debconf - adding "treeselect" type(s)?
Hallo Steve McIntyre, 30.11.20 16:36 Steve McIntyre: > I'll admit that I'm thinking of this *mostly* in terms of the needs of > tasksel so far, but I'd expect switching to a new template type is > likely to need a rethink to make best use of them anyway. In my mind there is also locales where we should have three levels: de de_AT de_DE [ ] de_DE [ ] de_DE@euro [ ] de_DE.UTF-8 en en_DK en_GB en_US Grüße Timo signature.asc Description: This is a digitally signed message part.
Re: Debconf - adding "treeselect" type(s)?
Colin Watson wrote: >On Mon, Nov 30, 2020 at 10:24:56AM +, Steve McIntyre wrote: >> Timo wrote: >> >What are the proposed semantics of this multitreeselect? >> > >> >If we imagine something like: >> > >> >[ ] a >> > [ ] a/b >> > [ ] a/c >> >[ ] b >> > [ ] b/a >> > >> >Would checking "a" automatically also check "a/*"? >> >Is it only about UI, meaning "a/*" would be collapsed under "a"? >> >Shall it be possible to check "a", but uncheck "a/b"? >> >> Yes, I'm thinking just about UI here: my plan would be to not have >> anything *selectable* at "a" - it would just toggle the display of the >> "a/*" subtree in those frontends that can display such a thing. > >If we took that approach then it wouldn't work so well for the grub2 >case, where "a" would be a whole disk and "a/b" and "a/c" would be >individual partitions. (Unless we rephrased the choices to include an >explicit "Whole disk" option or something.) That might be the best bet anyway, I think. I'll admit that I'm thinking of this *mostly* in terms of the needs of tasksel so far, but I'd expect switching to a new template type is likely to need a rethink to make best use of them anyway. -- Steve McIntyre, Cambridge, UK.st...@einval.com "You can't barbecue lettuce!" -- Ellie Crane
Re: Debconf - adding "treeselect" type(s)?
On Mon, Nov 30, 2020 at 10:18:05AM +, Steve McIntyre wrote: > Colin Watson wrote: > >On Sun, Nov 29, 2020 at 07:21:54PM +, 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]
Re: Debconf - adding "treeselect" type(s)?
On Mon, Nov 30, 2020 at 10:24:56AM +, Steve McIntyre wrote: > Timo wrote: > >What are the proposed semantics of this multitreeselect? > > > >If we imagine something like: > > > >[ ] a > > [ ] a/b > > [ ] a/c > >[ ] b > > [ ] b/a > > > >Would checking "a" automatically also check "a/*"? > >Is it only about UI, meaning "a/*" would be collapsed under "a"? > >Shall it be possible to check "a", but uncheck "a/b"? > > Yes, I'm thinking just about UI here: my plan would be to not have > anything *selectable* at "a" - it would just toggle the display of the > "a/*" subtree in those frontends that can display such a thing. If we took that approach then it wouldn't work so well for the grub2 case, where "a" would be a whole disk and "a/b" and "a/c" would be individual partitions. (Unless we rephrased the choices to include an explicit "Whole disk" option or something.) -- Colin Watson (he/him) [cjwat...@debian.org]
Re: Debconf - adding "treeselect" type(s)?
Colin Watson wrote: >On Sun, Nov 29, 2020 at 07:21:54PM +, 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.st...@einval.com "You can't barbecue lettuce!" -- Ellie Crane
Re: Debconf - adding "treeselect" type(s)?
Hi!
Timo wrote:
>29.11.20 20:21 Steve McIntyre:
>> 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*.
>
>What are the proposed semantics of this multitreeselect?
>
>If we imagine something like:
>
>[ ] a
> [ ] a/b
> [ ] a/c
>[ ] b
> [ ] b/a
>
>Would checking "a" automatically also check "a/*"?
>Is it only about UI, meaning "a/*" would be collapsed under "a"?
>Shall it be possible to check "a", but uncheck "a/b"?
Yes, I'm thinking just about UI here: my plan would be to not have
anything *selectable* at "a" - it would just toggle the display of the
"a/*" subtree in those frontends that can display such a thing. So,
yes: it would be possible to hit "a" and then not show have any of
"a/*" selected.
For simpler frontends that can't handle that kind of toggling, I'm
thinking we'd just display the tree nodes ("a", "b") as headings to
the user to group things together. Maybe we could do better - ask an
extra question at that point in the listing to show the user that
sub-tree or not.
--
Steve McIntyre, Cambridge, UK.st...@einval.com
"You can't barbecue lettuce!" -- Ellie Crane
Re: Debconf - adding "treeselect" type(s)?
Hallo Steve McIntyre, 29.11.20 20:21 Steve McIntyre: > 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*. What are the proposed semantics of this multitreeselect? If we imagine something like: [ ] a [ ] a/b [ ] a/c [ ] b [ ] b/a Would checking "a" automatically also check "a/*"? Is it only about UI, meaning "a/*" would be collapsed under "a"? Shall it be possible to check "a", but uncheck "a/b"? Grüße Timo signature.asc Description: This is a digitally signed message part.
Re: Debconf - adding "treeselect" type(s)?
On Sun, Nov 29, 2020 at 07:21:54PM +, 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) [cjwat...@debian.org]
