Tk4.0b: please correct the binding behavior 
Author Message
 Tk4.0b: please correct the binding behavior

I posted on this topic before, but I after I thought about it, it
looks like in the current state the behavior of  bindings is not
acceptable.

Description: You want to bind <Control-Return>, for example, in a
widget. However, the Class bindings are executed first, and since
there is no <Control-Return> binding, the less specific <Return>
Class binding is executed before widget <Control-Return> binding.

The only workaround I see is to change the default order of bindings: widget
specific first, class second. It is possible to do manually, but I
think that the *default* should change too.

And: it would be really great if after executing more specific finding
on the first stage, the less specific binding on the second stage
won't be executed at all (we know already that there is something
better to do, right?).

What do you think of that?

Ilya



Sun, 20 Jul 1997 00:22:45 GMT  
 Tk4.0b: please correct the binding behavior

  I posted on this topic before, but I after I thought about it, it
  looks like in the current state the behavior of  bindings is not
  acceptable.

  Description: You want to bind <Control-Return>, for example, in a
  widget. However, the Class bindings are executed first, and since
  there is no <Control-Return> binding, the less specific <Return>
  Class binding is executed before widget <Control-Return> binding.

Yes, I was concerned about having Class bindings before widget
bindings.  I don't think it's _worse_ than it was in Tk3.6, but for my
purposes it's not useful, either.  My general solution is going to be
to completely wipe out Class bindings for widget classes I'm concerned
about.  (I can't just change the binding tag order, because you can
only do that per individual widget, not for a whole class of widgets,
which is what I'd like.  I guess I could put a wrapper around the
widget creation commands for the classes I'm interested in to do
this.)  This unfortunately means I need to track Tk internals for
things like how menus are posted from the keyboard, focus traversal,
etc.

I think John's right that the current default binding order will be
OK for 95% of the scripts people write; unfortunately, it makes the
other 5% significantly more complex.  But it _is_ possible to override,
it just takes some work.

  The only workaround I see is to change the default order of bindings:
  widget specific first, class second. It is possible to do manually, but
  I think that the *default* should change too.

I would prefer this, but don't feel very strongly about it.

j.

--



Sun, 20 Jul 1997 01:37:31 GMT  
 Tk4.0b: please correct the binding behavior
|>
|> I posted on this topic before, but I after I thought about it, it
|> looks like in the current state the behavior of  bindings is not
|> acceptable.
|>
|> Description: You want to bind <Control-Return>, for example, in a
|> widget. However, the Class bindings are executed first, and since
|> there is no <Control-Return> binding, the less specific <Return>
|> Class binding is executed before widget <Control-Return> binding.
|>
|> The only workaround I see is to change the default order of bindings: widget
|> specific first, class second. It is possible to do manually, but I
|> think that the *default* should change too.
|>

Another option, which should work pretty well in your particular case,
is just to add code in your <Control-Return> binding to backspace over
the newline character that was inserted by the class binding for <Return>.
Or, of course, you could use "bindtags" to change the order of binding
tags for that particular widget.

It's possible that the right order of binding tags is as you suggest, but
I'd like to wait a while longer and hear about more people's experiences
before making the change.  I'm certain that there will be at least a few
complaints after I make the change, so I want to make sure that there
are more than a few complaints about the current scheme.

|> And: it would be really great if after executing more specific finding
|> on the first stage, the less specific binding on the second stage
|> won't be executed at all (we know already that there is something
|> better to do, right?).

I don't think this is a good idea.  This is exactly the behavior that
existed in Tk 3.6, and it made many things very hard to do.



Tue, 22 Jul 1997 01:42:11 GMT  
 Tk4.0b: please correct the binding behavior
|> |> And: it would be really great if after executing more specific finding
|> |> on the first stage, the less specific binding on the second stage
|> |> won't be executed at all (we know already that there is something
|> |> better to do, right?).
|>
|> I don't think this is a good idea.  This is exactly the behavior that
|> existed in Tk 3.6, and it made many things very hard to do.

What about having a way to ``short circuit'' the binding actions
from within a binding?

-----------------------------------------------------------------------------

     R.W. Withrow Associates, 319 Lynnway Suite 201, Lynn MA 01901 USA



Thu, 24 Jul 1997 00:40:49 GMT  
 Tk4.0b: please correct the binding behavior
Quote:

>I posted on this topic before, but I after I thought about it, it
>looks like in the current state the behavior of  bindings is not
>acceptable.

>Description: You want to bind <Control-Return>, for example, in a
>widget. However, the Class bindings are executed first, and since
>there is no <Control-Return> binding, the less specific <Return>
>Class binding is executed before widget <Control-Return> binding.

>The only workaround I see is to change the default order of bindings: widget
>specific first, class second. It is possible to do manually, but I
>think that the *default* should change too.

At first I also thought the new behaviour odd, but when I actually thought
about the power of the new binding tags mechanism I came to thinking the default
behaviour is in fact usually the best course.  For most actions appending
a window-specific binding to the Class binding is EXACTLY what you want to
do; for example adding an action on selecting an entry in a listbox is now
very clean and has enabled me to remove a lot of extraneous code!  The example
you give is definitely NOT the norm and your workaround is hardly difficult to
implement with bindtags!!

--
Paul Alexander
Department of Physics, Cavendish Laboratory,
University of Cambridge,
Cambridge, UK.



Wed, 23 Jul 1997 23:27:19 GMT  
 Tk4.0b: please correct the binding behavior

:

:|>
:|> The only workaround I see is to change the default order of bindings: widget
:|> specific first, class second. It is possible to do manually, but I
:|> think that the *default* should change too.
:|>
:
:
:It's possible that the right order of binding tags is as you suggest, but
:I'd like to wait a while longer and hear about more people's experiences
:before making the change.  I'm certain that there will be at least a few
:complaints after I make the change, so I want to make sure that there
:are more than a few complaints about the current scheme.
:
:|> And: it would be really great if after executing more specific finding
:|> on the first stage, the less specific binding on the second stage
:|> won't be executed at all (we know already that there is something
:|> better to do, right?).
:
:I don't think this is a good idea.  This is exactly the behavior that
:existed in Tk 3.6, and it made many things very hard to do.
:

As an non-Tcl user of Tk4.0b2 (I am doing a perl5 port) let me add my $0.02:

It seems to me that if the order was widget/class/all as suggested above
then using 'break' in the binding would allow the Tk3.6 behaviour
to be emulated.

A case in point: as it stands Label class FocusIn is bound to "reject"
the focus if it arrives via keyboard traversal. The current order
means that this class binding gives focus away with no chance for
a particular label to accept the focus.

This makes it hard to "derive" new widgets from labels (which I can
do in perl5 and I guess [incr tcl] could too).

One possible alternative would be if *all* widgets accepted a
-class configure option (similar to that of Frame/Toplevel), this
could be implemeted in Tk_ConfigureWidget (I think).  With this scheme
one could then have an alternate set of class bindings.



Sun, 27 Jul 1997 02:33:46 GMT  
 Tk4.0b: please correct the binding behavior

Quote:
>:|> And: it would be really great if after executing more specific finding
>:|> on the first stage, the less specific binding on the second stage
>:|> won't be executed at all (we know already that there is something
>:|> better to do, right?).
>:
>:I don't think this is a good idea.  This is exactly the behavior that
>:existed in Tk 3.6, and it made many things very hard to do.

How about a half way house. If a routine handling a more specific binding
returned a 1 then Tk should continue to do the less specific bindings,
else Tk skips them. This allows one to have the best of both worlds.

graham
--
                      Je suis pour le communisme
                      Je suis pour le socialisme
                      Je suis pour le capitalisme
                     Parce que je suis opportuniste



Sun, 27 Jul 1997 07:47:16 GMT  
 Tk4.0b: please correct the binding behavior

|> :

|> :|> And: it would be really great if after executing more specific finding
|> :|> on the first stage, the less specific binding on the second stage
|> :|> won't be executed at all (we know already that there is something
|> :|> better to do, right?).
|> :
|> :I don't think this is a good idea.  This is exactly the behavior that
|> :existed in Tk 3.6, and it made many things very hard to do.
|> :
|>
|> As an non-Tcl user of Tk4.0b2 (I am doing a perl5 port) let me add my $0.02:
|>
|> It seems to me that if the order was widget/class/all as suggested above
|> then using 'break' in the binding would allow the Tk3.6 behaviour
|> to be emulated.

Don't forget that you can always change the order of the binding tags
to widget/class/all if that's what you want:  just use the "bindtags"
command.  The default behavior can't possibly make everyone happy;  the
goal is to find the default behavior that will make the most people happy.
I think that the jury is still out on this issue.



Mon, 28 Jul 1997 08:42:28 GMT  
 Tk4.0b: please correct the binding behavior

|> >:|> And: it would be really great if after executing more specific finding
|> >:|> on the first stage, the less specific binding on the second stage
|> >:|> won't be executed at all (we know already that there is something
|> >:|> better to do, right?).
|> >:
|> >:I don't think this is a good idea.  This is exactly the behavior that
|> >:existed in Tk 3.6, and it made many things very hard to do.
|>
|> How about a half way house. If a routine handling a more specific binding
|> returned a 1 then Tk should continue to do the less specific bindings,
|> else Tk skips them. This allows one to have the best of both worlds.
|>

This feature is already implemented.  Just invoke the "break" command.
I believe that this is all described in the README file for Tk 4.0 and
in the relevant man pages (but let me know if I missed something).



Mon, 28 Jul 1997 08:43:59 GMT  
 Tk4.0b: please correct the binding behavior

Quote:

> Don't forget that you can always change the order of the binding tags
> to widget/class/all if that's what you want:  just use the "bindtags"
> command.

But you can't do this for an entire class, you have to give a
particular window.  If you could say something like "bindtags Text
{<widget> Text <toplevel> all}", then I wouldn't care what the default
ordering was, but as it is, the current bindings mechanism is always
going to be just a little more work for me than the Tk 3 one was.  I'd
much prefer having class bindings after widget bindings.

(But as you say, you can always get around it with some work.)

j.

--

BU Information Technology                                (MIME ok)
111 Cummington Street                         fax: +1 617 353 6260
Boston, MA 02115                              vox: +1 617 353 8257



Mon, 28 Jul 1997 10:19:18 GMT  
 Tk4.0b: please correct the binding behavior

|> > Don't forget that you can always change the order of the binding tags
|> > to widget/class/all if that's what you want:  just use the "bindtags"
|> > command.
|>
|> But you can't do this for an entire class, you have to give a
|> particular window.  If you could say something like "bindtags Text
|> {<widget> Text <toplevel> all}", then I wouldn't care what the default
|> ordering was, but as it is, the current bindings mechanism is always
|> going to be just a little more work for me than the Tk 3 one was.  I'd
|> much prefer having class bindings after widget bindings.
|>
|> (But as you say, you can always get around it with some work.)

Wait a minute.  We were talking about changing the bindtags for some
component of a megawidget.  That is, we wanted to establish a binding
tag for the megawidget and define its position in the bindtags order.

Seems to me that this is just one line of code in the procedure that
creates an instance of the megawidget:

proc myMega {w args} {
        frame $w -class Mymega
        text $w.text
        pack $w.text -fill x
        ... whatever all is done to process args and make the
            megawidget ...
        bindtags $w.text [list MyMega Class $w.text [winfo toplevel $w] all]
                # ... or whatever ...
        return $w

Quote:
}

It's only if you want binding tags to be changed willy-nilly
throughout an application that you'd need to have something like
a wholesale `bindtags' for a widget class.  It's far from clear that
would EVER be desirable; you'd also need versions of the Tk library
bindings that expect the new binding order, and so on.

--
73 de ke9tv/2, Kevin KENNY      GE Corporate R&D, Niskayuna, New York, USA



Tue, 29 Jul 1997 06:44:16 GMT  
 Tk4.0b: please correct the binding behavior

Quote:
> |> But you can't do this for an entire class, you have to give a
> |> particular window.  If you could say something like "bindtags Text
> |> {<widget> Text <toplevel> all}", then I wouldn't care what the default
> |> ordering was [...]
> Wait a minute.  We were talking about changing the bindtags for some
> component of a megawidget.  That is, we wanted to establish a binding
> tag for the megawidget and define its position in the bindtags order.

No, that's a different thread. :-)  (Seriously, somebody might have brought
up megawidgets in this thread, but that wasn't particularly what I was
talking about.)

Quote:
> It's only if you want binding tags to be changed willy-nilly
> throughout an application that you'd need to have something like
> a wholesale `bindtags' for a widget class.  It's far from clear that
> would EVER be desirable; you'd also need versions of the Tk library
> bindings that expect the new binding order, and so on.

Not if you're only talking about swapping widget and class bindings,
which is what I'd want to do 90% of the time, because the Tk library
bindings don't depend on there even being widget bindings.  (And yes,
the other 10% of the time I'd have to be careful.  But with class
bindings first I have to be careful 100% of the time. :-)

j.

--

BU Information Technology                                (MIME ok)
111 Cummington Street                         fax: +1 617 353 6260
Boston, MA 02115                              vox: +1 617 353 8257



Tue, 29 Jul 1997 09:46:46 GMT  
 Tk4.0b: please correct the binding behavior

Jay> But you can't do this for an entire class, you have to give a
Jay> particular window.  If you could say something like "bindtags
Jay> Text {<widget> Text <toplevel> all}", then I wouldn't care what
Jay> the default ordering was, but as it is, the current bindings
Jay> mechanism is always going to be just a little more work for me
Jay> than the Tk 3 one was.  I'd much prefer having class bindings
Jay> after widget bindings.

Since most of the posts I've seen seem to espouse this point of view,
I thought I'd put in my $.02.  I like the current behavior, and I'd
much prefer having class bindings before widget bindings.  In my
application I almost always want to do something in addition to what
is done in the class bindings, and it usually works out that it is
better to have my code run after the class bindings have run.  Please
don't change this!

Tom
--

"{*filter*} and farce are always inexplicably linked"
        -- Alexander Theroux



Wed, 30 Jul 1997 03:01:15 GMT  
 Tk4.0b: please correct the binding behavior

The original, or nearly original article had problems with a widget specific
<Control-Return> binding and a class specific <Return> binding -- both were
being invoked in response to hitting <Control-Return>.

However, I had thought that <Control-Return>, being more specific, would have
its bindings executed in preference to the bindings of <Return>.  I would
guess that the code executing bindings was whizzing down the bind-tags list
looking for a matching event in each group.

Perhaps instead there should be a two passes: the first pass looks for the
most specific event which is matched in any of the bind tags, the second pass
executes bindings that exactly match that most specific event.  So, in the
original case, the first pass looks for all bindings that match
<Control-Return>: it find binding in the class for <Return> but a more
specific binding for the widget in <Control-Return>.  The second pass no
executes only the widget's <Control-Return> binding.  You still get nice
behaviour in the light of other modifiers: for example, <Shift-Control-Return>
matches both <Return> and <Control-Return>, but the latter is still more
specific so we execute the <Control-Return> bindings.

There is a potential conflict here though: if there's a class binding for
<Shift-Return> and <Return> and a widget binding for <Control-Return>; what
does <Shift-Control-Return> execute?  At present, both the <Control-Return>
and <Shift-Return> bindings are executed and they are both equally specific.
I'd be tempted to ignore this ambuguity, but perhaps pass 1 above could
resolve it by taking the first (or maybe last) matching event of greatest
specifity (no there's a word to get the tongue around :-)
--

--

ISODE Consortium                                        +44 181 332 9091

These are my opinions and have nothing to do with my employer.



Sat, 02 Aug 1997 17:54:04 GMT  
 Tk4.0b: please correct the binding behavior

   Since most of the posts I've seen seem to espouse this point of view,
   I thought I'd put in my $.02.  I like the current behavior, and I'd
   much prefer having class bindings before widget bindings.  In my
   application I almost always want to do something in addition to what
   is done in the class bindings, and it usually works out that it is
   better to have my code run after the class bindings have run.  Please
   don't change this!

I agree with this.  Having the class bindings first means that, for example,
the button is already pressed in a Button widget, the radio selection already
selected and so on.  This actually makes a good deal of sense in almost all
cases for these widgets.

The main exceptions to bind tags order seems to be for Text and Entry (and
maybe canvas) widgets where people don't want to augment the class bindings,
they want to modify them.

I think that is what it boils down to: augmenting class bindings implies class
bindings first, modifying class binding implies widget bindings first.  I'd go
with augmenting everytime because it ensures widgets always behave in the
`expected' way -- modulo getting the specifity right, see

--

--

ISODE Consortium                                        +44 181 332 9091

These are my opinions and have nothing to do with my employer.



Sun, 03 Aug 1997 17:46:43 GMT  
 
 [ 16 post ]  Go to page: [1] [2]

 Relevant Pages 

1. binding in tk4.1 vs. tk4.2

2. tk4.0b(ummer)3 problem

3. More on tk4.0b(ummer)3 problem (execution trace)

4. Tk4.0b[12] option-database bug & patch

5. tk4.0b{1,2} crash on {Irix5.2,Linux1.1.51}

6. Tk4.0b canvas bugs

7. correct behavior

8. Is this behavior correct?

9. the correct behavior

10. correct Numeric behavior?

11. Correct behavior for file-write-date?

12. Correct behavior for failure during __init__()

 

 
Powered by phpBB® Forum Software