Tk Source Code

HI,
using mac_styles branch...
it seems that on macOS10.15 Control-Tab is dedicated to menu next tab binding.
that's fine, but when a menu is not posted I would like to use Control-Tab for special purpose.

is it possible ?

following script never puts ok
package require Tk
package require Ttk

ttk::label .f -text "Control-Tab binding"
grid .f -sticky news
bind . <Control-Tab> {puts "ok"}


best regards,
Nicolas

I think this ticket can be closed now.

Hi,
If you're all ok, then it's ok... I just find this behaviour annoying but no problemo.

best regards,
nicolas

I found this in the Bind manual page. I think it is meant to explain what you are observing:

An event may also contain additional modifiers not specified in the binding. For example, if button 1 is pressed while the shift and control keys are down, the pattern <Control-Button-1> will match the event, but <Mod1-Button-1> will not. If no modifiers are specified, then any combination of modifiers may be present in the event.

Indeed, this is exercised exactly here.

I found this in the Bind manual page. I think it is meant to explain what you are observing:

An event may also contain additional modifiers not specified in the binding. For example, if button 1 is pressed while the shift and control keys are down, the pattern <Control-Button-1> will match the event, but <Mod1-Button-1> will not. If no modifiers are specified, then any combination of modifiers may be present in the event.

Thanks, Nicolas. Please feel free to test the latest commit too! :^)

I can't say whether that behavior is expected, or correct. But it seems to have been around for a long time. I tested with linux Tk and with the Tk 8.5 that Apple ships. In both cases, if you bind to a key then the binding also fires when you apply a modifier to the key, unless there is a specific binding to the modified key. In your case, <Tab> is bound to the tk::NextWindow keyboard traversal proc. So <Control-Tab> also does keyboard traversal.

The most information that I found was here. But that page does not explain why this happens, and it is not obvious from looking at the code either. And I didn't find any documentation about it, although it might exist somewhere.

Hi,
I've tested this branch with Control-Tab in my code and it's working as expected.
thanks!

one thing is not expected on my side (and I don't know if it's expected from yours...)
if you consider the following script, Control-Tab is giving the focus to ttk::entry (unexpected) and several Control-Tab is switching among ttk::entry (unexpected)

package require Tk
package require Ttk

proc displayStuff {} {
    for {set x 1} {$x<10} {incr x} {
        set this($x) [\
        ttk::entry .b$x\
        ]
        bind .b$x <Escape> {focus -force .}
        grid $this($x) -sticky news
    }
    grid columnconfigure . all -weight 1
    grid rowconfigure . all -weight 1
}

displayStuff

bind . <Control-Tab> {puts "Ctrl+Tab pressed"}

Thanks, Brad.  I tested the notebook in the widget demo with commit f4ee810c4b
which has the code that ignores control-tab events removed.  It seems to
work fine.  If you have some notebook widgets that you could test against
that commit it would be very helpful.

Just a note:
library/ttk/notebook.tcl has control-tab and control-shift-tab bindings.
There may be conflicts there.

I tested whether it is really necessary to ignore the Tab keyevents with the
control modifier set.  The test was to select
  "Prefer tabs when opening documents = Always"
in the dock preferences and then to start wish and create several toplevels.
The toplevels open as tabs in the main window.  The Control-Shift-Tab and
Control-Tab keys work correctly to switch to the tab on the left or right,
even when the key event is translated to an XEvent.

I think this means that it is OK to remove the code which ignores those
events.  A Tk author might be able to break tabbing by creating some weird
binding to those events.  But that would be the author's responsibility.
There seems to be no damage caused by sending XEvents in response to
those key events when there is no binding.

Hi,
here Control-Tab and control-Shift-Tab are bounded to menuBar and when a menu is posted Control-Tab is unposting it and post the next one.

For my purpose, I've moved to Shift-Tab and that's ok.
you can close this ticket if you want :)

++

Just want to point out this is currently the expected behavior as of [5944d2a36a] (not necessarily that this issue is won't-fix), see tkProcessKeyEvent: (tkMacOSXKeyEvent.c):

    /*
     * Control-Tab and Control-Shift-Tab are used to switch tabs in a tabbed
     * window.  We do not want to generate an Xevent for these since that might
     * cause the deselected tab to be reactivated.
     */

if (keyCode == 48 && (modifiers & NSControlKeyMask) == NSControlKeyMask) {
	return theEvent;
    }