bugGNU Octave - Bugs: bug #44405, colorbar is attached to figure...

 
 

bug #44405: colorbar is attached to figure instead of axes parent

Submitter:  -X- <jsh>
Submitted:  Mon 02 Mar 2015 05:28:28 AM UTC
   
 
Category:  GUI Severity:  3 - Normal
Priority:  5 - Normal Item Group:  None
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Tue 14 Aug 2018 07:03:21 PM UTC, comment #11: 

Apparently progress has been made.  I just tried the original code and the colorbar is now correctly a child of the uipanel.  Marking as fixed and closing report.

Rik <rik5>
Group administrator
Fri 23 Dec 2016 07:27:22 PM UTC, comment #10: 

This behavior seems to be still present in Octave 4.2.0.

When running the first code line from comment #0 I still get a figure windows without any visible colorbar.

Hartmut <hardy>
Sat 07 Mar 2015 02:38:44 PM UTC, comment #9: 

Yes, it's probably better to wait until 4.0.1, there are probably quite a few places that assumes uiobjects are direct children of the figures. Hope I can help out with some proper fixes/patches when I get more time available.

-X- <jsh>
Fri 06 Mar 2015 06:57:38 PM UTC, comment #8: 

All that Panxto says is true--the uiXXX functions have not received a lot of testing and won't get enough before the 4.0 release.  I think pushing this off until 4.0.1 is fine.

Rik <rik5>
Group administrator
Fri 06 Mar 2015 05:30:09 PM UTC, comment #7: 

Thanks for your patch. I will take time to review it next week.

There are many places where figure is assumed to be the only expected parent for an axes (subplot, legend, axes at least for the most commonly used).
More generally, uixx features haven't been really tested (before you arrive :-)) and still have to be documented so I propose to start a careful work of integration of all those features once 4.0 is out.
We will then decide (depending on the degree of complexity/ABI compatibility) if those changes go to stable (for 4.0.1 release) or to default branch. Does it sound reasonable?

Pantxo Diribarne <pantxo>
Group Member
Fri 06 Mar 2015 04:49:58 PM UTC, comment #6: 

I've attached a patch with my changes but I think they're not really a proper solution, just a temporary fix.

(file #33262)

-X- <jsh>
Mon 02 Mar 2015 08:35:15 PM UTC, comment #5: 

Yes trying to fix the previous bug with such an automatic trick was not a good idea (consideraing also that I had never dealt with uipanel before). I ran the colorbar demos and was content with the fact that they worked ...

Legends and colorbars both don't behave well when their corresponding axes is not children of the figure.
I'll try to provide a robust fix for those unless jsh wants to submit a patch that I can review.


Pantxo Diribarne <pantxo>
Group Member
Mon 02 Mar 2015 04:12:35 PM UTC, comment #4: 

I'm adding Panxto to the CC list since he just implemented the change that uses ancestor in the graphics code.

Rik <rik5>
Group administrator
Mon 02 Mar 2015 04:10:11 PM UTC, comment #3: 

Regarding comment #2, each figure can use a different graphics toolkit for rendering and so it does need to be checked on a per figure basis.

Rik <rik5>
Group administrator
Mon 02 Mar 2015 06:53:44 AM UTC, comment #2: 

Actually, shouldn't the graphics_toolkit check be implemented differently, sort of like a global, becuase I assume you can only run one graphivs toolkit at a time, and then checking against each figure seems kind of wasteful?

-X- <jsh>
Mon 02 Mar 2015 06:48:08 AM UTC, comment #1: 

Missed some things:

Line 383 in colorbar.m should be changed to


if (strcmp (get ( ancestor( cf, "figure"), "__graphics_toolkit__"), "gnuplot")

   
and lines 47 and 79 in _actual_axis_position_.m


if/elseif (strcmp (get (axis_obj.parent, "__graphics_toolkit__"), "gnuplot")


should be changed to


if/elseif (strcmp (get ( ancestor( axis_obj.parent, "figure"), "__graphics_toolkit__"), "gnuplot")




-X- <jsh>
Mon 02 Mar 2015 05:28:28 AM UTC, original submission:  

The colorbar is always attached to the root figure instead of the axis parent. This is incorrect f for example the axes is a child of an uipanel.


f=figure;, h=uipanel('parent',f); axes('parent',h), colorbar


I get the correct behavior if I in colorbar.m change the lines 191-195 from


[pos, cpos, vertical, mirror] = ...
   __position_colorbox__ (loc, obj, ancestor (ax, "figure"));
set (ax, "position", pos);

cax = __go_axes__ (hpar, "tag", "colorbar",


to


hcpar = get( ax, "parent" );
[pos, cpos, vertical, mirror] = ...
   __position_colorbox__ (loc, obj, hcpar );
set (ax, "position", pos);

cax = __go_axes__ (hcpar, "tag", "colorbar",


This does not seem to be a proper fix though, and there might be configurations where it fails but normal axis in figure and axis in uipanel works.

-X- <jsh>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #33262:  colorbar.diff added by jsh (3KiB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by hardy (Posted a comment)
  • -email is unavailable- added by pantxo (Posted a comment)
  • -email is unavailable- added by rik5
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by jsh (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
    2018-08-14 rik5 StatusNone Fixed
        Open/ClosedOpen Closed
    2015-03-06 jsh Attached File- Added colorbar.diff, #33262
    2015-03-02 rik5 Carbon-Copy- Added pantxo

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code