Am 20.12.2010 03:14, schrieb pete.goodeve@xxxxxxxxxxxx:
On Sun, Dec 19, 2010 at 06:31:36PM -0600, Travis D. Reed wrote:Here's the problem. Without tweaking code, a popup menu will disappear when the user releases the mouse button that activated it, selecting whatever menu item the pointer happened to be on at the moment.I'm afraid that I'm not bothered at all by this behaviour. (:-/) I'm very used to the press-and-move-to-select paradigm, and it's what I normally do. In fact I'm a little more disturbed (but not much either) by menus that *don't* disappear when I release the button.
Even if someone works as you are describing (click + hold), if you right click and immediately release the mouse button, two unexpected things happen: It cannot be intentional by the user to make a popup menu flicker to live and immediately vanish. Second, and what is worse, it cannot be intentional to invoke a menu item that you can't have seen properly. Sorry for repeating what Travis has already described, but my point is that it's pretty much non-negotiable that these things happening are unintentional. By fixing the second problem, one /could/ have at least a consistent workflow, i.e. the user being *forced* to click and hold. But see below.
What's a little incosistent, I guess, is that pop-ups invoked from a menubar *do* stay up if you release the button without moving, but apparently if you use Go() they don't. (The menubar action seems just right to me -- if you drag to a desired item it gets selected; if you happen to just click, the menu stays available.)
Several things indicate that your workflow (click & hold) may not be so good: As you say, menu bars already allow to be navigated with released button. Many app programmers thought it a good idea to allow pop ups to be navigated without a button pressed. These options exist probably for good reasons. For example, I think it's very awkward to lift up and put down your mouse if you reach the end of your pad with a button pressed. Using a tablet and pen as input, it's also awkward to even press the second button, having to keep it pressed is even more awkward. In general having to keep the button pressed seems unnecessary work.
IMHO this thing ought to be fixed, and it should be possible to keep the button pressed. The menu navigation implementation already aims to provide this, but it has the described bugs. Those need to be fixed. For a consistent behavior, the awkward BPopUp menu configuration options for app programmers should be ignored in the code, with a consistent built-in solution taking there place. Whether Travis' patch is a good solution, I cannot say.
Best regards, -Stephan
