Thu 20 Jun 2013 07:58:51 PM UTC, comment #9:
Oops. I don't think anyone saw that there were patches attached to this bug report until now. I made the two changes suggested in this changeset (http://hg.savannah.gnu.org/hgweb/octave/rev/3d981b47be42) and this one (http://hg.savannah.gnu.org/hgweb/octave/rev/0e75f5412f1e). Marking report as fixed and closing.
|
Fri 27 Jul 2012 11:07:13 PM UTC, comment #8:
Your proposals work correctly. I'm enclosing patch (fltk_ginput.diff) of the respective files.
Furthermore I enclose a patch for gnuplot's ginput (gnuplot_ginput_m.diff). For compatibility, it should stop when hitting a return key.
Can somebody commit both patches?
(file #26276, file #26277)
|
Thu 28 Jun 2012 06:22:52 PM UTC, comment #7:
I'm not an fltk expert, but at least I could figure out a quite simple patch in order to get the correct button (1,2,3). This patch was applied to octave 3.6.2.
As I'm not yet familiar with diff/changesets etc. I'll propose the patch in here. Two files need to be changed:
_init_fltk_.cc in line 1272 (case FL_PUSH:)
call
fp.execute_windowbuttondownfcn ();
with argument
Fl::event_button()
fp.execute_windowbuttondownfcn (Fl::event_button());
_fltk_ginput_.m in function ginput_windowbuttondownfcn
The second argument (data) will be set to 1,2,3 (left, middle, right) mouse button.
Then just use
button = data;
instead of
button = 1;
|
Sun 19 Feb 2012 09:56:57 PM UTC, comment #6:
I've tried octave-3.6.0 and the bug is still there.
|
Mon 31 Jan 2011 09:31:49 PM UTC, comment #5:
OK, I removed the lines.
Now I see the incorrect coordinates. This seems to only happen when there are keypresses. With mouse clicks only, the coordinates returned are not all the same. However, they do not seem to be the graph coordinates. I'll file a separate report about that.
|
Mon 31 Jan 2011 09:10:36 PM UTC, comment #4:
You haven't applied the patch correctly, please remove these lines:
## FIXME -- got to get the buttons somehow
button = ones (size (x));
otherwise you cannot see key values.
Now:
graphics_backend fltk; plot(1:10)
[a,b,c]=ginput(3)
and: click MB1 at coordinates (2,2), then press key o at (4,4) and key p at (6,6) => the resulting coords is a triplet of (2,2) instead of [2,4,6 2,4,6].
|
Sun 30 Jan 2011 08:24:18 AM UTC, comment #3:
I checked in your change with a few minor edits.
I do seem to get current mouse location. Can you describe precisely what you are doing that results in the last mouse position being returned instead of the current one?
Thanks.
|
Thu 20 Jan 2011 10:21:07 AM UTC, comment #2:
I have fixed fltk_ginput.m just a little bit to accept key presses (patch enclosed); that was easy thanks to info send to one of the subroutines.
However, there are still 3 bugs - FIXME's:
# FIXME: Key presses cannot toggle menu items nor hotkey functionality (grid, autoscale) during ginput!
# FIXME How to get the actual mouse button pressed (1,2,3) into "butt"?
# FIXME "point" does not contain current mouse position but previous clicked position!
A fltk expert will have to fix them.
(file #22464)
|
Thu 20 Jan 2011 08:45:09 AM UTC, comment #1:
For me, it waits for N clicks then returns.
It doesn't seem to matter whether I press the first, second, or third mouse button, it still gathers the location data. But it does always return ones(N,1) for the button numbers. That's acknowledged in a FIXME comment in the _fltk_ginput_ function. I'm not an expert in fltk programming, so someone else will have to fix this.
|
Wed 19 Jan 2011 01:35:36 PM UTC, original submission:
The fltk backend accepts only Mouse Button 1 or Enter pressed in ginput(n) command instead of waiting for n events. Further, this function should return mouse button numbers or key codes in the 3rd output argument:
|