> Before the introduction of the HID interface, the only menu that had > the "convert selection to element" was the pop-up menu and it used > the location of the click that popped up the menu as the > coordinate. Actually there were several items in that menu that used > the coordinate, it was a useful feature now lost.
Note that HID does have an API for getting a coordinate from the user, when the action needs one. The GUI is supposed to keep track of whether it has a current coordinate (i.e. from mouse or key click, but not from a menu pick) so it can query the user as needed. Each action has a flag that says if it needs a coordinate or not, so most of the time it "just works". However, many of the actions in action.c are multi-purpose, and only some of the purposes need a coordinate, which makes it messy. There are calls to the HID api to get coordinates sprinkled throughout, I just missed the one for converting the selection to an element, which I just fixed. > The GTK interface does have an ability to request the location for a > menu operation, which is really annoying when there is a key > shortcut because for that it should use the current crosshair > position. Note that the lesstif interface keeps track of shortcuts vs menu clicks so it knows when it has a coordinate. The HID interface has nothing to do with this; it's completely within the GUI implementation. _______________________________________________ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user