On Sunday 15 November 2015 22:09:55 Gene Heskett wrote:
> Greetings all;
>
> One of the un-nessessarily difficult aspects of running linuxcnc, is how
> the mouse vs menu's is handled.
>
> LinuxCNC's file menu in particular has a behaviour that needs a liberal
> application of a LART but when I ask the developers about it I am told
> its whatever the window manager does.
>
> In this case chase the  mouse over and click on the left hand "file"
> menu, which brings up a list of next operation  choices, as you would
> expect. 2nd on the menu is "recent files".  Makes perfect sense because
> one is often cycleing thru at least 2 file, maybe more, and several tool
> changes before removing that workpiece from the jig.
>
> Problem is, in order to maintain that 2nd menu, the mouse cursor must not
> leave the "recent files" line of text in the primary menu, else the
> secondary menu disappears to be replaced by the sub-menu the mouse might
> be traveling over, ostensibly on its way to the 2nd menu's display.  Net
> result is that sub-menu's are popping up and disappearing as the mouse
> mopves, and when the pointer arrives at where the filename you wanted to
> click on, its not there, having been replaced by something else whose
> only commonality is that it belongs in the "file" menu category.
>
> 1. Clicking on the already highlighted "recent files" line of text does
> nothing, although one would normally expect the click to at least lock
> it to that function.
>
> 2. So I must pull over my chair and sit down so I can guide the  mouse as
> it moves sideways, such that it never leaves that line of text.  A 3
> second click here, click on the name, done, simply is not possible.  The
> operation can take as long as 30 seconds to get lucky and guide the
> mouse accurately enough not to lose the menu and get something else.
>
> Is it possible to let the mouse click select the menu, then click select
> the sub-menu, then click select the filename one wants without all this
> gingerbread popping up and derailing ones line of thought?  IOW, do
> nothing between clicks, just check to see where the click was, totally
> ignoring how the mouse got to where the click was issued?
>
> Its called useability by me, and the present menu's popping in and out of
> existence as the mouse is moved performance is a huge hindrance to
> productivity.
>
> Obviously, showing the pointer moving is fine, but doing nothing else
> until a click is issued would be the ideal target.
>
> Is it fixable someplace?

I solve this exact problem by navigating the menu with the keyboard pointer 
keys instead of the mouse.  (The reason it is inconvenient is different, but 
the problem is the same.)

Works for me.  Just keep the mouse well out of the way so that it can't slip 
into the frame.

Lisi