bugGNU Octave - Bugs: bug #52398, Qt toolkit plot loses track of...

 
 

bug #52398: Qt toolkit plot loses track of axes proportion when containing window is shrunk small

Submitter:  Dan Sebald <sebald>
Submitted:  Mon 13 Nov 2017 06:09:49 AM 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

Sat 16 Feb 2019 09:09:24 AM UTC, comment #7: 

Ok so I'll close this report.

Pantxo Diribarne <pantxo>
Group Member
Fri 15 Feb 2019 04:59:29 PM UTC, comment #6: 

The original problem was fixed for me as of December 2018 (comment #2).  I think this can be closed.

Rik <rik5>
Group administrator
Fri 15 Feb 2019 10:30:05 AM UTC, comment #5: 

I cannot reproduce the original bug anymore. Can someone confirm?

Pantxo Diribarne <pantxo>
Group Member
Tue 18 Dec 2018 07:58:58 PM UTC, comment #4: 

@Dan: I agree, the zoom function with the Qt toolkit is laggy when compared to the FLTK toolkit.

The second part of your response can definitely be improved.  There is a callback routine that handles mouse interactions and I think it would be a smallish change to grab the mouse coordinates and stick them in to the call to zoom.  This works pretty well for the FLTK toolkit where you can right-click-hold, select a region, and then it zooms on the region.  Similarly, when you do a left click zoom in Qt it should do a zoom centered around the point you are clicking.

Rik <rik5>
Group administrator
Sat 15 Dec 2018 04:24:00 PM UTC, comment #3: 

It doesn't seem to be a problem.  However, the fix (avoiding crashes and corrupted axis data by introducing a noticeable delay that makes manual scaling sort of slow and jumpy) isn't exactly an improvement.

Lately, I've been using Octave more as a user than a developer...on a Windows system.  As a result, I've used the FLTK and qt toolkits a bit more.  Neither of them is great.  The Qt plots are really limited by the inability to select a zoom region as opposed to "zoom in" and click on a point to zoom around.  Neither one seems real controllable in terms of set(gcf,prop) when it comes to legend/plot layout; or manual resizing of a window.

Dan Sebald <sebald>
Thu 13 Dec 2018 05:51:27 AM UTC, comment #2: 

@Dan: Could you check whether this is still a problem?

I used your sample code from comment #0 and then used the mouse to shrink the window as small as possible.  When I re-expanded it the plot was still normal.

Rik <rik5>
Group administrator
Mon 15 Oct 2018 01:32:39 PM UTC, comment #1: 

@Dan: I attached a patch that implement the fixed minimum size approach. As you say it is not perfect, and the size I chose only ensures single axes, with the default font size, won't get shrunk too much.

(file #45199)

Pantxo Diribarne <pantxo>
Group Member
Mon 13 Nov 2017 06:09:49 AM UTC, original submission:  

Testing the following example from https://savannah.gnu.org/bugs/?52389 :


graphics_toolkit qt
plot(randn(1,20))
legend('Normal')
title 'QT'


I've found that Qt has a bug in which shrinking the figure window height to very small then expanding messes up the plot boundaries so that the axes are magnified drastically. See the attached example screen capture.

It looks as though FLTK has its window size forced to a minimum that won't allow such a situation to arise. I recall gnuplot terminals having similar problems too (nothing to do with Octave). Rather than digging into the issue, programmers for gnuplot also have gone the route of ensuring a minimum window size, i.e., avoid the situation.  Programmers have probably put the minimum size constraint on FLTK because its not the easiest issue to deal with.  There is border space for axes titles and tick annotation to take into account when computing available space, etc.

It would be nice to have a most graceful solution, but this is a problem that doesn't arise often so the minimum window size seems fine.  Note that FLTK toolkit window will jump to the minimum size even if I syntactically supply plot size property values that are very small.  The Qt toolkit window should adjust in a similar way to user-input .  That is, something like this

set(gcf, 'outerposition', [135 521 511 40])

behaves as follows:


octave:5> graphics_toolkit fltk
octave:6> figure
octave:7> plot(randn(1,20))
octave:8> legend('Normal')
octave:9> title 'FLTK'
octave:10> set(gcf, 'outerposition', [135 521 511 40])
octave:11> get(gcf, 'outerposition')
ans =

   466   474   511   147


where I put in height 40 (too small) and Octave adjusted that to 147.

Dan Sebald <sebald>

 

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

Attach Files:
   
   
Comment:
   

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by pantxo (Updated the item)
  • -email is unavailable- added by sebald (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 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-02-16 pantxo StatusPatch Submitted Fixed
        Open/ClosedOpen Closed
    2018-10-15 pantxo Attached File- Added resize_minimum.patch, #45199
        StatusNone Patch Submitted
    2017-11-13 sebald Attached File- Added shrink_then_expand_qt_plot_Screenshot from 2017-11-10 23-56-56.png, #42382

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code