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

Submitted by:  Dan Sebald <sebald>
Submitted on:  Mon 13 Nov 2017 06:09:49 AM UTC  
Category:  Plotting with OpenGL Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Patch Submitted Assigned to:  None
Originator Name:  Open/Closed:  Open
Release:  dev Operating System:  GNU/Linux

Add a New Comment(Rich Markup)

You are not logged in

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


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>
Project 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>
Project Member
Mon 13 Nov 2017 06:09:49 AM UTC, original submission:

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

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:

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:


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)

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

    Only project members can vote.




    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    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.3