Tue 31 Mar 2015 08:25:24 PM UTC, comment #9:
Thanks, that was a very quick fix!
(Indeed Rik, I think 1,5 weeks ago it still worked, as scripts I made around that time that invoked ginput worked fine. Today I continued work on that code and ginput no longer worked)
|
Tue 31 Mar 2015 06:32:58 PM UTC, comment #8:
I fixed Qt to behave the same as FLTK and include the button number when executing the windowbuttondownfcn callback (http://hg.savannah.gnu.org/hgweb/octave/rev/0376c1225660).
|
Tue 31 Mar 2015 05:49:08 PM UTC, comment #7:
I think we have a small Matlab incompatibility here. Matlab's WindowButtonDownFcn is just a callback without arguments. In Octave, the file ginput.m expects that the first argument to the callback is the button number.
And in _init_fltk_.cc
so it works for FLTK.
In Canvas.cc, however,
so it doesn't work for Qt.
Easiest solution would be to add "button_number (event)" to the windowbuttondownfcn callback.
Alternatively, we can do what Matlab user's would do and check the "SelectionType" property of current figure to determine if it was "normal", "extended", or "alt".
|
Tue 31 Mar 2015 05:29:15 PM UTC, comment #6:
Yeah, I thought I fixed this problem recently with this patch:
http://hg.savannah.gnu.org/hgweb/octave/rev/b38b677c0fa8
What happened? Oh, I think it was this change:
http://hg.savannah.gnu.org/hgweb/octave/rev/6e5365ee200a
Should be easy to fix by also passing the button number to the windowbuttondownfcn callback.
|
Tue 31 Mar 2015 05:26:13 PM UTC, comment #5:
I tried to use 'hg bisect', but I couldn't find when ginput was ever correctly reporting button clicks. So, it is confirmed that there is a problem with ginput and Qt.
|
Tue 31 Mar 2015 03:38:42 PM UTC, comment #4:
For gnuplot, it had been reported before on being a value of 1023 sometimes, which I had seen in Windows only and had been fixed by checking if was 1023 and setting the return value to 1 [1]
[1] https://savannah.gnu.org/bugs/?func=detailitem&item_id=42489
|
Tue 31 Mar 2015 03:35:57 PM UTC, comment #3:
I'm pretty sure this is a recent regression. I believe as recently as a few weeks ago this was working. I'm adding jwe to the CC list since he was working on this code earlier.
|
Tue 31 Mar 2015 03:22:12 PM UTC, comment #2:
It looks like there may be a need for qt initialization like
at line 76 of ginput.m for fltk:
if (strcmp (toolkit, "fltk"))
_fltk_check_ ();
endif
for qt ? But, it almost works for gnuplot:
>> [x,y,button]=ginput(3)
x =
0.46300
0.37694
0.37694
y =
0.77482
0.67101
0.66835
button =
3
1063
2
>>
good, except button 1 shows as 1063
This is current devel on Fedora 21.
|
Tue 31 Mar 2015 02:51:29 PM UTC, comment #1:
Doesn't work for the qt toolkit - fltk and gnuplot work.
Also does the same on my fedora box for the empty button array.
|
Tue 31 Mar 2015 11:34:01 AM UTC, original submission:
[~, ~, b] = ginput () returns an empty value [](0x0) for b when a mouse button is clicked.
Expected is 1, 2, or 3, depending on which mouse button was pressed.
ginput() does return the ASCII value of pressed keyboard keys.
|