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?
Thanks people.
Cheers, Gene Heskett
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.
- 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.
- 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
Hi Gene!
Am Sonntag, 15. November 2015 schrieb Gene Heskett:
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.
- 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.
- 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?
Thanks people.
Cheers, Gene Heskett
Well, don't use the mouse :-)
Try this:
<alt>+F, <down>, <right>, 2, <enter>
And you've loaded the second recent file ..
Nik
On Sunday 15 November 2015 17:17:16 Dr. Nikolaus Klepp wrote:
Hi Gene!
Am Sonntag, 15. November 2015 schrieb Gene Heskett:
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.
- 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.
- 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?
Thanks people.
Cheers, Gene Heskett
Well, don't use the mouse :-)
Try this:
<alt>+F, <down>, <right>, 2, <enter>
Is it fussy which <alt>?
Didn't work the first time, menu opened, but keyboard arrows were sent to /dev/null. Closed it, hit it again, worked. ??
And you've loaded the second recent file ..
I'll give that a shot when I'm out there making Mahogany chips again. Tomorrow.
Thanks Nik, that sounds useable, but fixing the mouse would be even better as its a one handed operation.
Nik
Cheers, Gene Heskett
On Sunday 15 November 2015 22:27:38 Gene Heskett wrote:
On Sunday 15 November 2015 17:17:16 Dr. Nikolaus Klepp wrote:
Hi Gene!
Am Sonntag, 15. November 2015 schrieb Gene Heskett:
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.
- 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.
- 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?
Thanks people.
Cheers, Gene Heskett
Well, don't use the mouse :-)
Try this:
<alt>+F, <down>, <right>, 2, <enter>
Is it fussy which <alt>?
Didn't work the first time, menu opened, but keyboard arrows were sent to /dev/null. Closed it, hit it again, worked. ??
And you've loaded the second recent file ..
I'll give that a shot when I'm out there making Mahogany chips again. Tomorrow.
Thanks Nik, that sounds useable, but fixing the mouse would be even better as its a one handed operation.
Since it is a problem which is universal to every system and website I remember having ever used, it is unlikely to get fixed soon.
Lisi
Nik
Cheers, Gene Heskett
Hi Gene & Lisi!
<alt>+F, <down>, <right>, 2, <enter>
Is it fussy which <alt>?
Yep, must be the one left of space. The other one is "alt gr"
Didn't work the first time, menu opened, but keyboard arrows were sent to /dev/null. Closed it, hit it again, worked. ??
And you've loaded the second recent file ..
I'll give that a shot when I'm out there making Mahogany chips again. Tomorrow.
Thanks Nik, that sounds useable, but fixing the mouse would be even better as its a one handed operation.
You can make "<alt>" sticky, then it's a one handed operation: TDE control center, "Regional settings/Accessibility", there 2. Tab "sticky keys" (sorry, translated from german, might be labeled otherwise), then it's:
<alt>, f, <down>, <right>, 2, <enter>
You could automate this sequence with a tool like "xbindkeys" and e.g. use the darn capslock-key to play that sequence :-)
Nik
On Sunday 15 November 2015 22:46:02 Dr. Nikolaus Klepp wrote:
Hi Gene & Lisi!
<alt>+F, <down>, <right>, 2, <enter>
Is it fussy which <alt>?
Yep, must be the one left of space. The other one is "alt gr"
Didn't work the first time, menu opened, but keyboard arrows were sent to /dev/null. Closed it, hit it again, worked. ??
And you've loaded the second recent file ..
I'll give that a shot when I'm out there making Mahogany chips again. Tomorrow.
Thanks Nik, that sounds useable, but fixing the mouse would be even better as its a one handed operation.
You can make "<alt>" sticky, then it's a one handed operation: TDE control center, "Regional settings/Accessibility", there 2. Tab "sticky keys" (sorry, translated from german, might be labeled otherwise), then it's:
<alt>, f, <down>, <right>, 2, <enter>
You could automate this sequence with a tool like "xbindkeys" and e.g. use the darn capslock-key to play that sequence :-)
Another, less elegant, one-handed solution: Click on <menu> or whatever with mouse. Move mouse well out of way in a harmless direction. Use arrow keys on keyboard from then on.
Lisi
On Sunday 15 November 2015 17:46:02 Dr. Nikolaus Klepp wrote:
Hi Gene & Lisi!
<alt>+F, <down>, <right>, 2, <enter>
Is it fussy which <alt>?
Yep, must be the one left of space. The other one is "alt gr"
And I think thats why it didn't work the first time.
Didn't work the first time, menu opened, but keyboard arrows were sent to /dev/null. Closed it, hit it again, worked. ??
And you've loaded the second recent file ..
I'll give that a shot when I'm out there making Mahogany chips again. Tomorrow.
Thanks Nik, that sounds useable, but fixing the mouse would be even better as its a one handed operation.
You can make "<alt>" sticky, then it's a one handed operation: TDE control center, "Regional settings/Accessibility", there 2. Tab "sticky keys" (sorry, translated from german, might be labeled otherwise), then it's:
<alt>, f, <down>, <right>, 2, <enter>
You could automate this sequence with a tool like "xbindkeys" and e.g. use the darn capslock-key to play that sequence :-)
Logitech K360 keyboard, square sided keys, don't get jamed with swarf near as often as a regular keyboard, cheap and compact, has some unused media keys above the esc key that might be stealable for that. :)
Thanks you two.
Nik
Cheers, Gene Heskett
-
Dr. Nikolaus Klepp -
Gene Heskett -
Lisi Reisz