Re: Outerposition Patch

[logari81]

On Wed, 2011-02-16 at 19:37 -0500, Ben Abbott wrote:
> On Feb 13, 2011, at 12:05 PM, logari81 wrote:
> 
> > On Thu, 2011-02-10 at 20:00 +0100, Konstantinos Poulios wrote:
> >> On Thu, Feb 10, 2011 at 1:59 PM, Konstantinos Poulios
> >> <address@hidden> wrote:
> >>> On Thu, Feb 10, 2011 at 9:25 AM, David Bateman <address@hidden> wrote:
> >>>> 
> >>>> Le 10 févr. 2011 à 00:25, logari81 <address@hidden> a écrit :
> >>>> 
> >>>>>> 
> >>>>> thank you for this information.
> >>>>> 
> >>>>> It seems that the previously attached patch causes problems only with
> >>>>> legends. However, in order to treat legends correctly I need to
> >>>>> understand their logic. How do legends exploit the outerposition and
> >>>>> position properties? Is anyone familiar with legend.m to give me a short
> >>>>> introduction?
> >>>>> 
> >>>>> Best regards
> >>>>> 
> >>>> You shouldn't try to understand the logic of legend's use of the 
> >>>> position and outerposition properties. It's just a hack that worked with 
> >>>> the existing behavior. If your patch doesn't work well with legend it is 
> >>>> probably legend that needs to be fixed
> >>>> 
> >>>> D.
> >>> 
> >>> The attached patch replaces the previous one and implements the
> >>> calculation of both position and outerposition depending on the value
> >>> of activepositionproperty.
> >>> 
> >>> It is not very well tested yet, so there will probably be some issues,
> >>> e.g. legends will not work, but it brings a feature that maybe is
> >>> awesome. It is something that Matlab cannot do and maybe you like it.
> >>> See the following video:
> >>> 
> >>> http://ubuntuone.com/p/cYM/
> >>> 
> >>> The position property is calculated dynamically while you rotate the
> >>> view, so that all labels fit in outerposition. I think it works quite
> >>> well in order to keep it. What do you think?
> >>> 
> >>> As this operation involves certain computational overhead, it would be
> >>> interesting to get some tests on older machines. Unfortunately all
> >>> pc's that I have access to, are too fast.
> >>> 
> >>> This patch also fixes http://savannah.gnu.org/bugs/?31610 for the fltk 
> >>> toolkit.
> >>> 
> >>> Finally, if we adopt the attached patch we have to adapt legend.m also.
> >>> 
> >>> BR
> >>> 
> >>> Kostas
> >> 
> >> After some more testing and fixes I think the patch is quite mature in
> >> the form you find in the attachment. I think it could be checked in.
> >> 
> > I have just checked in this changeset along with some further
> > fixes/improvements. Now, I would like to provide some additional
> > information and ask for some help with regard to the open issues that I
> > had listed.
> > 
> >> There are still some general issues with fltk that I will try to sum up:
> >> 
> >> 1. In some demo plots axes labels seem to be too close to the axes
> >> (e.g. demo legend 9). Probably in some of the previous changes there
> >> is something that I have overseen.
> >> 
> > Actually after testing older revisions of octave I realized that the
> > problem is not new. The reason that I hadn't noticed it before is
> > because the problem appears only in the print output and not in the plot
> > window. It seems that gl-render and gl2ps position strings differently
> > considering either the bottom line or the baseline of the string
> > respectively. It is not difficult to fix, we just have to decide which
> > of gl-render and gl2ps are we going to fix in order to make both
> > consistent.
> > 
> >> 2. Legends for barplots don't show colors (this is an old problem).
> >> 
> >> 3. Some small y axes interference for plotyy (also not new).
> >> 
> >> 4. Now there is no labels-titles interference in demo subplot 1, so
> >> there is no need for extra space between the subplots, we can reduce a
> >> bit the padding (someone which is familiar with subplot.m I suppose).
> >> 
> > Waiting for someone familiar with subplot.m
> 
> I"ve just pushed a changeset that improves the layout of the subplots.
> 
>       http://hg.savannah.gnu.org/hgweb/octave/rev/7b67bbf9dbbb
> 
> I'm also attaching a test script that runs under Octave and Matlab. Results 
> for both are attached.
> 
This script is cool, I was thinking of doing something like that but I
didn't realize that it can be done so easily.

> The test script places dashed blue lines around the position of each axis, 
> and dashed red around the outerposition.
> 
You mean blue lines around the original axes position before adding
labels and titles. The version of the script that I have attached in
this email visualizes the updated positions which correctly coincide
with the axes.

> When subplot (3,3,1:3) is used to replace the first row of subplots, a green 
> dashed box is used to encompass the new position, and a dashed magenta for 
> the outerposition.
> 
> The problems I see are ...
> 
> 1) The activeposition property is still "outerposition".
> 
why is this a problem? Maybe we prefer this, maybe not, see my comment
on (2). ML sets it to "position" but we do not have necessarily to do
the same.

> 2) The width of subplot (3,3,1:3) has been improperly modified on the c++ 
> side.
> 
Actually this is not really "improperly". It is doing what it was
expected to do. What we programmed in c++ is a minimum left margin of
13% of outerposition(3). For the upper subplot the total width is 3
times the width of the other subplots so the minimum left margin is also
3 times higher. It is ugly.
This would be a reason for switching to activepositionproperty=position.
This way, we wouldn't let sync_position do its job but we would do it
manually in the frontend. Now we are able to, before we couldn't because
we couldn't get any tightinset values.

> 3) The positions have been shifted to the left relative to what was specified 
> by subplot.m. Originally, their left edges were very close to the left edge 
> of the outerpositon.
> 
What do you mean by "left edges" I don't get this point.

> 4) The xticklabels and yticklabels should be tigher to the axes.
> 
This is adjustable I think. Maybe it makes sense to calculate the
distance of ticklabels from axes as percentage of axes sizes.

> Regarding (1), this can easily be changed, but before doing that some manner 
> to ensure
> 
> Ben
> 

Kostas

test_subplot_a.m
Description: Text Data