Version 2 of Tearoff

Updated 2004-06-11 09:53:15

RLH: tearoff allows you to detach menus for the main window creating floating menus. If you create a menu you will see dotted lines at the top when you click a top menu item. If you click those dotted lines the menu tears off and becomes floating.


MAK: Tk menus support tearoff by default. This can be configured either through the menu's configure command or via the option database prior to the menu's creation:

 menu .m
 .m add cascade -label "Foo" -menu .m.foo
 menu .m.foo -tearoff 0
 menu .m.foo add cascade -label "Bar"
 menu .m.foo add cascade -label "Baz"

Or:

 option add *Menu.tearoff 0
 menu .m
 ...

Tearoff menus can be a minor annoyance when it comes to menu entryconfigure, which can reference entries in a menu either by label or by numeric index -- the reason being that the dotted line at the top of the menu counts as an entry, and the first entry is always index 0, except for the torn-off version of the menu. There the index of the first entry is 1, unless you disable the tearoff after the fact, in which case it becomes 0. What this means is that if you reference entries by numeric index, then they will be off by 1 depending on whether or not the menu allows being torn off. It's generally safer, therefore, to reference entries by their label instead.

Why would you need to reference entries at all once they're created? For starters, to disable or enable the entries based on an application's current state (disabling commands that can't safely be used until some currently running process finishes, for example) or to provide additional detail depending on other things (instead of "Save" showing "Save <filename>" when <filename> is selected in another area of the GUI, for another example). Tk provides some flexibility in referencing entries by label by using glob-style pattern matching. That is, when you say...

 .m.file entryconfig Save* -state disabled

...it doesn't require the label to be exact. Rather, the first entry whose label starts with "Save" will match. Even still, personally, I rather dislike the look of tearoff menus (particularly on platforms where it's not a standard appearance), so I generally disable them across the board with option add, sometimes (but not often, since inconsistency is also a pet peeve) enabling it specifically for the most frequently used menus that someone's really going to want to tearoff. In those cases, though, I usually make those functions available via toolbar buttons so that they don't need to tear the menu off.