bugGNU Octave - Bugs: bug #44426, ginput with Qt doesn't return...

 
 

bug #44426: ginput with Qt doesn't return values for clicks outside axes

Submitter:  Rik <rik5>
Submitted:  Wed 04 Mar 2015 06:19:26 PM UTC
   
 
Category:  Plotting with OpenGL Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sun 15 Mar 2015 04:52:49 PM UTC, comment #8: 

This is fixed with the following changesets:

http://hg.savannah.gnu.org/hgweb/octave/rev/4910b70d7328
http://hg.savannah.gnu.org/hgweb/octave/rev/6e5365ee200a

I get the same behavior between FLTK and Qt now, both inside and outside single or multiple axes.

Mike Miller <mtmiller>
Group Member
Fri 13 Mar 2015 01:59:23 PM UTC, comment #7: 

Answering myself, no that is not enough because I see some references to the child object buttondownfcn functions execute first. So the code needs some shuffling around to ensure the currentpoint property is set on both the figure and the child objects before the windowbuttondownfcn callback is called.

Mike Miller <mtmiller>
Group Member
Fri 13 Mar 2015 01:53:49 PM UTC, comment #6: 

In FLTK, the windowbuttondownfcn is called before the axes currentpoint property is updated, see the section of code starting here:

http://hg.savannah.gnu.org/hgweb/octave/file/29fe196d2ce0/libinterp/dldfcn/__init_fltk__.cc#l1451

I think it might be enough to move the windowbuttondownfcn call to the bottom of the case block, not yet tested but I will try later.

Mike Miller <mtmiller>
Group Member
Thu 12 Mar 2015 12:08:26 PM UTC, comment #5: 

The diff also fixes the ginput behavior relative to this statement from Mathworks:

> If you select points from multiple axes, the results returned
> are relative to the coordinate system of the axes they come from.


So the following:


figure; subplot (2, 1, 1); subplot (2, 1, 2); [x, y] = ginput (5)


should return clicks in both axes, but the first set is ignored currently.

Mike Miller <mtmiller>
Group Member
Thu 12 Mar 2015 12:02:32 PM UTC, comment #4: 

Thanks. So the attached diff works perfectly for me with Qt but not with FLTK. The currentpoint reported by each callback is the previous currentpoint, not the current currentpoint, if that makes any sense.

(file #33317)

Mike Miller <mtmiller>
Group Member
Thu 12 Mar 2015 05:16:29 AM UTC, comment #3: 

According to Matlab documentation, "You can click anywhere within the figure canvas to obtain coordinates. If you click outside the axes limits, ginput extrapolates coordinate values so they are still relative to the axes origin."

Rik <rik5>
Group administrator
Thu 12 Mar 2015 04:07:10 AM UTC, comment #2: 

This is due to differences in how the buttondownfcn callback works between Qt and FLTK. The ginput function is using buttondownfcn, but maybe it should be using windowbuttondownfcn instead to ensure that clicks anywhere in the figure are caught.

However, in FLTK when the windowbuttondownfcn callback is used, the mouse coordinates from the "currentpoint" property of the axes lag one click behind. But with the Qt toolkit the "currentpoint" property is correct when the windowbuttondownfcn callback is called.

Seems to me like the Qt behavior is better, but fixing this for Qt using windowbuttondownfcn would break ginput for FLTK.

Mike Miller <mtmiller>
Group Member
Wed 04 Mar 2015 06:28:20 PM UTC, comment #1: 

I've narrowed down the problem.  It seems that Qt is only accepting button clicks within the axes.  According to the documentation, ginput is supposed to extrapolate for values outside the axes.  This is what the FLTK toolkit does.

Simpler test:


./run-octave -f --no-gui
graphics_toolkit qt
plot (1:10, "o-")
x = ginput
# Click outside 2-D axes several times
# Type <RETURN> to end ginput
# result should be x = []


Rik <rik5>
Group administrator
Wed 04 Mar 2015 06:19:26 PM UTC, original submission:  

A good deal of the time using ginput() with the Qt toolkit returns 1 less button press than was actually made.  Sample code


./run-octave -f --no-gui
graphics_toolkit qt
sombrero
x = ginput
# Now click 3 times on various places on figure
# Type <RETURN> to stop ginput
# Check number of button inputs recorded in x


It "seems" that the first button click merely goes to making the figure window have the focus.  However, I have sometimes got it to the point where no click is ever return ([]) despite multiple clicks.

Rik <rik5>
Group administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #33317:  ginput.diff added by mtmiller (1KiB - text/x-patch)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by rik5 (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2015-03-15 mtmiller StatusNone Fixed
        Open/ClosedOpen Closed
    2015-03-12 mtmiller Attached File- Added ginput.diff, #33317
    2015-03-04 rik5 Summaryginput doesn\'t return correct number of button presses with Qt ginput with Qt doesn't return values for clicks outside axes

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code