info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Change [listbox]'s -selectmode from a string to a list
36 views
Skip to first unread message
Mike Griffiths
Feb 21, 2018, 5:55:52 AM2/21/18
to
I'm not able to raise a TIP, so thought I'd float the suggestion here and see if anyone who can is interested in supporting this. :)
The -selectmode argument for Tk's [listbox] can be any arbitrary value, but the existing bindings expect it to be one of a fixed number of values (single, browse, extended or multiple). This means that, while you can use an alternative value for -selectmode to introduce new behaviours, you have to replace, rather than extend, the current functionality.
If -selectmode were made to be a list instead of a string, however, you could more easily extend the functionality without having to reimpliment the defaults.
The changes needed to handle this would be fairly minor - mostly changing the binding checks from things like
if { [$w cget -selectmode] eq "single" }
to
if { "single" in [$w cget -selectmode] }
- and I'd be happy to do a patch for this if there's interest.
It wouldn't be guaranteed to be 100% backwards compatible - because it's currently an arbitrary string, someone somewhere might be using
-selectmode "foo{bar"
or some other value which isn't a valid list. Potentially someone could also be using a multi-word value which contains one of the Tk defaults, like
-selectmode "this is not browse"
which, after the change, would cause the -selectmode browse bindings to trigger where they currently don't.
I imagine either case would be pretty rare, though, and those edge cases would be the only things that would either error (in the first case) or work differently (in the second); everything else should work exactly the same out of the box.
Admittedly, it's a fairly minor functionality change, and you can achieve much the same by switching [bindtag]s in and out instead. But since the -selectmode option is there and takes arbitrary values, it'd be nice if you could make use of it more easily, IMHO. I'd be interested to hear other people's thoughts on it, though.
The -selectmode argument for Tk's [listbox] can be any arbitrary value, but the existing bindings expect it to be one of a fixed number of values (single, browse, extended or multiple). This means that, while you can use an alternative value for -selectmode to introduce new behaviours, you have to replace, rather than extend, the current functionality.
If -selectmode were made to be a list instead of a string, however, you could more easily extend the functionality without having to reimpliment the defaults.
The changes needed to handle this would be fairly minor - mostly changing the binding checks from things like
if { [$w cget -selectmode] eq "single" }
to
if { "single" in [$w cget -selectmode] }
- and I'd be happy to do a patch for this if there's interest.
It wouldn't be guaranteed to be 100% backwards compatible - because it's currently an arbitrary string, someone somewhere might be using
-selectmode "foo{bar"
or some other value which isn't a valid list. Potentially someone could also be using a multi-word value which contains one of the Tk defaults, like
-selectmode "this is not browse"
which, after the change, would cause the -selectmode browse bindings to trigger where they currently don't.
I imagine either case would be pretty rare, though, and those edge cases would be the only things that would either error (in the first case) or work differently (in the second); everything else should work exactly the same out of the box.
Admittedly, it's a fairly minor functionality change, and you can achieve much the same by switching [bindtag]s in and out instead. But since the -selectmode option is there and takes arbitrary values, it'd be nice if you could make use of it more easily, IMHO. I'd be interested to hear other people's thoughts on it, though.
Francois
Feb 22, 2018, 1:53:20 AM2/22/18
to
Mike Griffiths <mi...@keyboardzombie.com> Wrote in message:
any means.
The bindings in the default library expect some precise values,
and this is documented, but should not fail with non-standard
ones. However if you want to use a new value you'll probably need
to redefine the bindings anyway.
> This means that, while you can use an alternative value for -selectmode to introduce new behaviours, you have to replace, rather than extend, the current functionality.
I don't understand this statement.
The current values describe behaviors that are mutually exclusive.
So you would like to have an additional value that is not
exclusive to the existing ones? Omething that, say, refine the
behavior of the existing ones? I'm curious about the use
case.
Regards,
Francois
----Android NewsGroup Reader----
http://usenet.sinaapp.com/
> The -selectmode argument for Tk's [listbox] can be any arbitrary value, but the existing bindings expect it to be one of a fixed number of values (single, browse, extended or multiple).
I don't think it's the case. The number of values is not fixed by
any means.
The bindings in the default library expect some precise values,
and this is documented, but should not fail with non-standard
ones. However if you want to use a new value you'll probably need
to redefine the bindings anyway.
> This means that, while you can use an alternative value for -selectmode to introduce new behaviours, you have to replace, rather than extend, the current functionality.
The current values describe behaviors that are mutually exclusive.
So you would like to have an additional value that is not
exclusive to the existing ones? Omething that, say, refine the
behavior of the existing ones? I'm curious about the use
case.
Regards,
Francois
----Android NewsGroup Reader----
http://usenet.sinaapp.com/
Mike Griffiths
Feb 22, 2018, 5:15:03 AM2/22/18
to
$lb configure -selectmode [list single draganddrop]
and have the bindings applied to the "Listbox" widget class universally, but have them check for the presence of 'draganddrop' in -selectmode, so the behaviour can be toggled on and off for each listbox widget as desired (as happens already with the built-in bindings when you change -selectmode).
0 new messages