octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [changeset] colorbar bug


From: Ben Abbott
Subject: Re: [changeset] colorbar bug
Date: Sun, 01 Mar 2009 22:04:42 -0500


On Mar 1, 2009, at 7:57 PM, Ben Abbott wrote:


On Mar 1, 2009, at 1:52 PM, dbateman wrote:


Ben Abbott wrote:

This changeset addresses two bugs I encountered.

(1) Two colorbar commands produced two colorbars.

(2) colorbar ("off") did not turn off the colorbar.

Demos are included which verify the intended behavior.

This fix was trivial, and has been pushed to savannah.

Ben


I'm not sure (1) is a bug. Yes I noticed this behavior when I reimplement colorbar in 3.2, but kept it as that is similar behavior to matlab when I
tested it. However, I think its probably better to only have a single
colorbar so the fix is fine.

D.

I should have checked what Matlab does.

>> clf
>> set(0,'handleVisibility','on')
>> plot(1:10)
>> hc1 = colorbar

hc1 =          173

>> hc2 = colorbar

hc2 =          173

Thus Octave's present implementation shoud not delete colorbar replace it with a new one, but should update it.

When given a new location, a second colorbar is created.

>> hc3 = colorbar('westoutside')

hc3 =          203

I did not expect this behavior. The fix should be trivial. I'll look at it.

Ben

David, the job is a bit more complicated than I'd expected. It appears to me that a rewrite of update_colorbar is needed.

        addlistener (ax, "dataaspectratio", address@hidden, cax})
        addlistener (ax, "position", address@hidden, cax})

Updating a colorbar axis when other colorbars are present will require a significant change to how this presently works. I'd (1) add the listener to the data axis, (2) pass the original data axis position through the listener, (3) have the data axis updater find all associated colorbars and set the position and size of data axis and all associated colorbar axes, (4) preserved the original data axis position value, by taking care that the listener is not modified as subsequent colorbars are added.

I'm still studying how your present implementation is working. Does my approach sound proper, or can you recommend a something better?

If not, I'm not sure that respecting compatible behavior in this instance is important enough at the moment (there are some more important backend issues that need attention for the 3.2 release), so I'm likely to delay working further on this.

In any event, a partial changeset is attached below. It preserves the handle when colorbar is called multiple times for the same location, but only allow one colorbar per axes (a demo has been added to illustrate this behavior). I've also attempted to ensure that non- gnuplot backends will work.

Can you take a quick look?

Ben


Attachment: changeset-colorbar.patch
Description: Binary data







reply via email to

[Prev in Thread] Current Thread [Next in Thread]