bugGNU Octave - Bugs: bug #46494, Incorrect behavior of setting...

 
 

bug #46494: Incorrect behavior of setting handle children.

Submitted by:  None
Submitted on:  Sat 21 Nov 2015 11:37:03 PM UTC  
 
Category: PlottingSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Incorrect Result
Status: FixedAssigned to: None
Originator Name: Originator Email: -unavailable-
Open/Closed: ClosedRelease: 3.8.1
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.

 

Sun 22 Nov 2015 11:56:06 AM UTC, comment #3:

Hi,

Thanks for your bug report. This bug has been fixed (http://hg.savannah.gnu.org/hgweb/octave/rev/c17e1cefdbd3) and all works as expected (red patch covers the blue one) in Octave 4.0.

Closing report as fixed.

Pantxo Diribarne <pantxo>
Project Member
Sun 22 Nov 2015 01:59:40 AM UTC, comment #2:

Afterwards, I got a workaround, where I can grab all hidden handle indices, set them visible, turn off the ShowHiddenHandles flag, reorder the children, then set those handles back to being hidden.

Thus, I can replace this:

kk_h = get(gca,'children');
set(gca,'children',[kk_h(2);kk_h(3:length(kk_h));kk_h(1)]);

with:

kk_h = get(gca,'children');
kk_inv = strcmp('off', get(kk_h, 'HandleVisibility'));
set(kk_h(kk_inv), 'HandleVisibility', 'on');
tmp_show=get(0, 'ShowHiddenHandles');
set(0, 'ShowHiddenHandles', 'off');
set(gca,'children',[kk_h(2);kk_h(3:length(kk_h));kk_h(1)]);
set(kk_h(kk_inv), 'HandleVisibility', 'off');
set(0, 'ShowHiddenHandles', tmp_show);

And then the first handle will be set even below those invisible ones.

Anonymous
Sun 22 Nov 2015 01:28:23 AM UTC, comment #1:

BTW, this is somewhat important because delete() doesn't work properly with this. It screws up everything because of duplicate handles.

Anonymous
Sat 21 Nov 2015 11:37:03 PM UTC, original submission:

There's a particular weird behavior from using set() with the 'ShowHiddenHandles' option:

graphics_toolkit('gnuplot');
flag = logical(1);
patch([0,0,1,1],[0,1,1,0], 'r');
patch([0,0,2,2],[0,0.5,0.5,0], 'b');
kk = get(gca,'children')
if flag,
show=get(0, 'ShowHiddenHandles');
set(0, 'ShowHiddenHandles', 'on');
end;
kk_h = get(gca,'children')
set(gca,'children',[kk_h(2);kk_h(3:length(kk_h));kk_h(1)]);
kk_h = get(gca,'children')
if flag,
set(0, 'ShowHiddenHandles', show);
end
kk = get(gca,'children')

Using the above code to test, one will notice that if 'ShowHiddenHandles' is set to 'on', setting gca's children will actually double the number of children instead of replacing it, where the new permutation is inserted before the old one. This does not occur when 'ShowHiddenHandles' is set to 'off'.

The intended behavior is that the red patch should now be covering over the blue patch instead of the other way around. While this does not affect fltk as much due to still drawing the final red patch after the final blue patch, gnuplot will have problems due to only caring about the first copy of the draw. Either way, the behavior is incorrect (also according to Matlab) because the number of gca's children should remain constant unless a new handle is created.

Anonymous

 

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

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by pantxo (Posted a comment)
  • -unavailable- added by None (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 2 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sun 22 Nov 2015 11:56:06 AM UTCpantxoStatusNone=>Fixed
      Open/ClosedOpen=>Closed

    Back to the top


    Powered by Savane 3.1-cleanup1