Disambiguation edit
- piemenu for Tk ,by Don Hopkins
Description edit
Current version : Beta, 0.3, home [1], download [2], manual (draft) [3]This is an ongoing project. Hopefully this or some other incarnation of pie menus will prove to be a good widget for Tk. Lack of anti-aliasing and transparency is a problem in creating good looking curved canvas buttons. Ideas and help are invited and welcome. dzachThis package provides a single command piemenu, in a similar manner with Tk's menu command. The piemenu command is used to create either a toplevel or a canvas menu. If the parent of the pathName provided at creation time is a canvas widget, then the pie menu is created in that canvas. Otherwise it is created in a new toplevel window.Here is an example of how a pie menu looks like:Why use a pie menu ?
- The main reason is because it's far easier to use on touch screens, on mobile devices where simplicity matters.
- It has different aesthetics than the usual rectangular popup or drop down menus, and can make tcl/tk look nice.
- Round shapes are usually easier to the eye (can be easily made cluttered though, like everything else).
- It can help give a minimalistic appearance to an interface, when this is a requirement (e.g. OLPC's Sugar interface [4]).
- It gives the benefits of applying Fitts's Law [5] to popup menus.
BUGSThe piemenu package code needs improvement, so bug reports and patches are welcome.
schlenk Did you consider to put this into tklib? Looks like a nice and useful package.dzach I think it needs further development. It's still in beta, and there are a number of subcommands that are similar to tk's menu command that are not yet implemented. There is also the possibility to make a round (or elliptical) popup piemenu that does not show a rectangular top level window. However, if putting it in tklib would help develop it further, by attracting some more developers who find it useful, I'd be glad to.APE I modified the behaviour when user clicks (Button-1) on the canvas outside the menu commands. In this case, the menu actions are cancelled, which is the desired behaviour I suppose. To do so, I added a tag "pmcmd" in the list of tags of each command, and a variable records the current posted menu at the end of the draw and post functions :
set var(currentpm) $W.$menuWhen drawing or posting the menu, the binding is associated to this function : bind $W <Button-1> [list piemenu::Button-1-outside %W]
proc Button-1-outside {W} { upvar ::piemenu::var var if {"pmcmd" ni [$W gettags current]} { # button-1 activated outside a piemenu command : unpost menu $var(currentpm) unpost } }APE There is a side effect on the central button command : if the delayed command is activated, the "normal" command is activated when the button is released. Proposed modification : a variable var(delcmdact) is set to "1" if the delayed command is activated, so when the button-1 is released the "normal" command is not called :
if {[info exists opt($btn,-command)] && !$var(delcmdact)} { after 0 $opt($btn,-command) }