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

 
 

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

Submitted by:  Rik <rik5>
Submitted on:  Wed 04 Mar 2015 06:19:26 PM UTC  
 
Category: Plotting with OpenGLSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Incorrect Result
Status: FixedAssigned to: None
Originator Name: Open/Closed: Closed
Release: devOperating System: GNU/Linux

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission 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>
Project Administrator
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>
Project Administrator
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>
Project Administrator
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:

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

Mike Miller <mtmiller>
Project Administrator
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>
Project Administrator
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>
Project 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>
Project Administrator
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:

Rik <rik5>
Project 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

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>
Project Administrator

 

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

Attach File(s):
   
   
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
  • -unavailable- added by mtmiller (Posted a comment)
  • -unavailable- added by rik5 (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 4 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sun 15 Mar 2015 04:52:49 PM UTCmtmillerStatusNone=>Fixed
      Open/ClosedOpen=>Closed
    Thu 12 Mar 2015 12:02:32 PM UTCmtmillerAttached File-=>Added ginput.diff, #33317
    Wed 04 Mar 2015 06:28:20 PM UTCrik5Summaryginput 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.1-cleanup1