[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Outerposition Patch
From: |
Ben Abbott |
Subject: |
Re: Outerposition Patch |
Date: |
Mon, 21 Feb 2011 22:03:57 -0500 |
On Feb 19, 2011, at 9:42 AM, Ben Abbott wrote:
> On Feb 19, 2011, at 2:21 AM, logari81 wrote:
>
>> On Fri, 2011-02-18 at 19:06 -0500, Ben Abbott wrote:
>>
>>> On Feb 18, 2011, at 6:35 PM, logari81 wrote:
>>>
>>>> On Fri, 2011-02-18 at 22:40 +0100, Konstantinos Poulios wrote:
>>>>
>>>>> On Fri, Feb 18, 2011 at 6:07 PM, bpabbott <address@hidden> wrote:
>>>>>
>>>>>> On Feb 18, 2011, at 12:02 PM, bpabbott <address@hidden> wrote:
>>>>>>
>>>>>> On Feb 18, 2011, at 11:04 AM, Konstantinos Poulios <address@hidden>
>>>>>> wrote:
>>>>>>
>>>>>> On Fri, Feb 18, 2011 at 2:36 PM, Ben Abbott <address@hidden> wrote:
>>>>>>> On Feb 18, 2011, at 2:37 AM, logari81 wrote:
>>>>>>>
>>>>>>>> On Thu, 2011-02-17 at 21:09 -0500, Ben Abbott wrote:
>>>>>>>>
>>>>>>>>> On Feb 17, 2011, at 4:32 PM, logari81 wrote:
>>>>>>>>>
>>>>>>>>>> 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 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.
>>>>>>>>>
>>>>>>>>> Ok. I see your point. I'll have to do some experimenting with the
>>>>>>>>> corrected version.
>>>>>>>>>
>>>>>>>>>>> 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.
>>>>>>>>>
>>>>>>>>> We may decide to deviate from compatibility with Matlab, but before
>>>>>>>>> doing so we should discuss it on the list. The list has already
>>>>>>>>> discussed
>>>>>>>>> and agreed to Matlab compatibility (before my time here), it would be
>>>>>>>>> improper to deviate from that agreed upon approach without discussion
>>>>>>>>> first.
>>>>>>>>>
>>>>>>>>> Can we abide by Matlab's example for now and discuss changes later. If
>>>>>>>>> nothing else, that would make it easier (for me) to review the state
>>>>>>>>> of
>>>>>>>>> graphics for Octave (via dump_demos and such).
>>>>>>>>>
>>>>>>>>>>> 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.
>>>>>>>>>
>>>>>>>>> If consistent with Matlab, the subplot(3,3,1:3) would produce an axes
>>>>>>>>> with a position property that encompasses the original 3 axes (Matlab
>>>>>>>>> documents this, but I've noticed some minor "bugs" on their part).
>>>>>>>>>
>>>>>>>>> For now, can the position/outerposition synchronization be implemented
>>>>>>>>> in the manner that is consistent with Matlab's documentation?
>>>>>>>>>
>>>>>>>>> Meaning that when outerposition is active …
>>>>>>>>>
>>>>>>>>> I) position(1) is adjusted to the right (never to the left), to ensure
>>>>>>>>> no object extends to the left of outerposition(1).
>>>>>>>>>
>>>>>>>> Right now, no objects should extend left of outerposition(1). If there
>>>>>>>> is a test case not respecting this rule, please let me know (only
>>>>>>>> exception is if you make the plot window tiny).
>>>>>>>
>>>>>>> I don't see any cases of that. What I do see is that you're requiring a
>>>>>>> minimum of space between the outerposition and position boxes. So you're
>>>>>>> adding features, correct?
>>>>>>>
>>>>>>>>> II) position(2) is adjusted upward (never downward), to ensure no
>>>>>>>>> object
>>>>>>>>> extends below the outerposition(2)
>>>>>>>>>
>>>>>>>>
>>>>>>>> likewise
>>>>>>>
>>>>>>> Your approach is not consistent with the "never downward" part, Correct?
>>>>>>>
>>>>>>>>> III) position(3) is decreased (never increased) to ensure no object
>>>>>>>>> extends beyond the outerposition(1)+outerposition(3).
>>>>>>>>>
>>>>>>>>
>>>>>>>> likewise
>>>>>>>
>>>>>>> Same.
>>>>>>>
>>>>>>>>> IV) position(4) is decreased (never increased) to ensure no object
>>>>>>>>> extends beyond the outerposition(2)+outerposition(4).
>>>>>>>>>
>>>>>>>>
>>>>>>>> likewise
>>>>>>>
>>>>>>> Same again.
>>>>>>>
>>>>>>>>> When the position property is active the relationship is reversed. Its
>>>>>>>>> been a couple of years since I looked that this in detail. Is my
>>>>>>>>> understanding of how Matlab works consistent with yours?
>>>>>>>>>
>>>>>>>>>>> 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.
>>>>>>>>>
>>>>>>>>> Opps ... not "left", but "right"!
>>>>>>>>>
>>>>>>>>> My observation was that the right edge of the "position" has been
>>>>>>>>> shifted to the left even though no object impinged upon the right
>>>>>>>>> edge of
>>>>>>>>> the outerposition.
>>>>>>>>>
>>>>>>>>
>>>>>>>> This is 9.5%. The problem is that we consider these minimum margins 13%
>>>>>>>> to the left, 9.5% to the right, 11% to the bottom, 7.5 %to the top.
>>>>>>>> This
>>>>>>>> is compatible with ML for normal plots, but for subplots ML reduces
>>>>>>>> this
>>>>>>>> limits. Actually subplot in ML is quite a hack. We have different
>>>>>>>> possibilities of achieving the same behavior. I make a proposal at the
>>>>>>>> end.
>>>>>>>
>>>>>>> Actually Matlab does not have "minimum margins". Those margins are set
>>>>>>> by
>>>>>>> the "defaultaxisposition" and "defaultaxisouterposition" properties
>>>>>>> (present
>>>>>>> in the root, figure and axes objects). Thus, they are controlled on by
>>>>>>> m-file side by the user. So I think the current synchronization isn't
>>>>>>> compatible with Matlab, even for normal plots.
>>>>>>>
>>>>>>>>>>> 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.
>>>>>>>>>
>>>>>>>>> This isn't a documented by MathWorks. However, I did some
>>>>>>>>> experimenting
>>>>>>>>> and found that ...
>>>>>>>>>
>>>>>>>>> a) xlabel baseline is (2*fontsize + 7) points below the axis position
>>>>>>>>>
>>>>>>>>> b) x-axis ticklabels are (fontsize + 1.5) points below the axis
>>>>>>>>> position
>>>>>>>>>
>>>>>>>>
>>>>>>>> the bigger the font, the higher the distance from the axis
>>>>>>>
>>>>>>> Yes.
>>>>>>>
>>>>>>>>> c) the right extent of the y-axis ticklabels is (20/fontsize + 1)
>>>>>>>>> points to the left of the axis position.
>>>>>>>>>
>>>>>>>>
>>>>>>>> so, the bigger the font, the closer to the axis? Interesting.
>>>>>>>
>>>>>>> Keep in mind that the extent property is designed for type-settting, so
>>>>>>> there is some white space included. Thus, the visual result does not
>>>>>>> give
>>>>>>> the impression the characters are closer to the axis box. Matlab and
>>>>>>> Octave's extents aren't yet consistent, so there is good reason not to
>>>>>>> blindly copy this feature. However, I do think the spacing should rely
>>>>>>> upon
>>>>>>> the font and not the axis.
>>>>>>>
>>>>>>>> Do you believe these 3 approximations a,b and c are fixed or they could
>>>>>>>> change proportionally to the axes width/height.
>>>>>>>
>>>>>>> No they do not. This is easily seen my resized the figure with the
>>>>>>> mouse.
>>>>>>>
>>>>>>>>> As this isn't documented by MathWorks, they could change it. So there
>>>>>>>>> is
>>>>>>>>> no compelling reason to copy the specifics.
>>>>>>>>>
>>>>>>>>> However, if there are multiple axes in the same figure, I think the
>>>>>>>>> spacing between axes, ticklabels, and labels should be consistent
>>>>>>>>> (assuming
>>>>>>>>> the fontsize is consistent). Does that make sense? Other thoughts /
>>>>>>>>> concerns?
>>>>>>>>>
>>>>>>>>> Ben
>>>>>>>>
>>>>>>>> SUGGESTION:
>>>>>>>>
>>>>>>>> 1st step: Add a new property (hidden?) to the axes object:
>>>>>>>> minmargins = [l b rt]
>>>>>>>> with default value derived from defaultaxesposition:
>>>>>>>> l=defaultaxesposition(0)
>>>>>>>> b=defaultaxesposition(1)
>>>>>>>> r=1-defaultaxesposition(0)-defaultaxesposition(2)
>>>>>>>> t=1-defaultaxesposition(1)-defaultaxesposition(3)
>>>>>>>
>>>>>>> I rather not see this done. The margins are currently defined by the
>>>>>>> user
>>>>>>> on the m-file side by changing the position/outerposition of the axes.
>>>>>>> This
>>>>>>> just looks more complicated to me with no added capability.
>>>>>>>
>>>>>>>> 2nd step: Modify sync_positions so that it takes into account
>>>>>>>> minmargins
>>>>>>>> instead of defaultaxesposition. This would mean no change for all other
>>>>>>>> plots, but for subplots it gives as the possibility to reduce the
>>>>>>>> minimum margins from the frontend (e.g. reduce the ugly 9.5% to the
>>>>>>>> right).
>>>>>>>
>>>>>>> I'd prefer that the synchronization limit itself to the compatible
>>>>>>> behavior. For activepositionproperty = "outerposition"
>>>>>>>
>>>>>>> I) position(1) is adjusted to the right (never to the left), to ensure
>>>>>>> no
>>>>>>> object extends to the left of outerposition(1).
>>>>>>>
>>>>>>> II) position(2) is adjusted upward (never downward), to ensure no object
>>>>>>> extends below the outerposition(2).
>>>>>>>
>>>>>>> III) position(3) is decreased (never increased) to ensure no object
>>>>>>> extends beyond the outerposition(1)+outerposition(3).
>>>>>>>
>>>>>>> IV) position(4) is decreased (never increased) to ensure no object
>>>>>>> extends
>>>>>>> beyond the outerposition(2)+outerposition(4).
>>>>>>>
>>>>>>> In short the position property never expands, but retracts to keep
>>>>>>> itself
>>>>>>> and its children inside the outerposition.
>>>>>>>
>>>>>>> Conversely, when the activepositionproperty == "position", the
>>>>>>> outerposition never contracts, but expands so as to encompass the axis
>>>>>>> and
>>>>>>> its children.
>>>>>>>
>>>>>>> One of the difficulties I'm having with subplot is that the
>>>>>>> synchonization
>>>>>>> second guesses the specified position. In addition, the current solution
>>>>>>> will be difficult to document.
>>>>>>>
>>>>>>>> 3rd step: Optimize subplot.m making use of the new property minmargins
>>>>>>>>
>>>>>>>> Only by setting minmargins to zero would eliminate most problems that
>>>>>>>> we
>>>>>>>> observe now with subplot. More sophisticated use of minmargins would
>>>>>>>> even allow us to synchronize the insets in rows and columns of the
>>>>>>>> subplot grid (AFAIK is what ML does, can you confirm this?).
>>>>>>>>
>>>>>>>> What do you think? Should I add the a property minmargins or something
>>>>>>>> similar?
>>>>>>>
>>>>>>>
>>>>>>> Ok, Please propose a changeset with the default for minmargins set to
>>>>>>> zero so that we'll have a compatible solution.
>>>>>>>
>>>>>>> Ben
>>>>>>>
>>>>>>
>>>>>> Hmm, I have a suggestion. Since I thought that the implementation of
>>>>>> sync_position for single plots (not subplots) is compatible with ML,
>>>>>> and you are saying that it isn't, this should be the first issue to
>>>>>> fix. Could you provide me with an example of a single plot that
>>>>>> demonstrates the difference between ML and Octave?
>>>>>>
>>>>>> As soon as I fix this we can come back to subplot again and continue
>>>>>> our discussion.
>>>>>>
>>>>>> BR
>>>>>>
>>>>>> Kostas
>>>>>>
>>>>>> First example is for activeposition == "position"
>>>>>> figure (1)
>>>>>> clf
>>>>>> set (gca, 'position', [0 0 1 1], 'activepositionproperty',
>>>>>> 'outerposition')
>>>>>> plot (0:1,0:1)
>>>>>> axis ([0 1 0 1])
>>>>>> outerposition = get (gca, 'outerposition')
>>>>>> I've attached the result from Matlab. The outerposition from Matlab is
>>>>>> outerposition = -0.1677 -0.1350 1.2903 1.2270
>>>>>> Octave's result does not grow the outerposition.
>>>>>> outerposition = 0 0 1 1
>>>>>
>>>>> ouuuuups!!! I introduced this bug in 98772e4e8a2a. It used to work
>>>>> correctly before. I have just pushed the fix, so it should be ok
>>>>> again.
>>>>>
>>>>>> If this example so that activeposition == "outerposition" ...
>>>>>> figure (1)
>>>>>> clf
>>>>>> set (gca, 'position', [0 0 1 1], 'activepositionproperty',
>>>>>> 'outerposition')
>>>>>> set (gca, 'outerposition', [0 0 1 1])
>>>>>> plot (0:1,0:1)
>>>>>> axis ([0 1 0 1])
>>>>>> … then I see that the default axis position is restored. This does
>>>>>> behave in
>>>>>> the manner you're suggesting, but it is not described by the
>>>>>> documentation.
>>>>>> http://www.mathworks.com/help/techdoc/creating_plots/f1-32495.html
>>>>>> This behavior is new to me (wasn't there when I examined this a few years
>>>>>> back). So it appears I owe you an apology for the back-n-forth.
>>>>>> I did a quick google, and found that someone else named "Ben" had figured
>>>>>> out what is happening.
>>>>>> http://undocumentedmatlab.com/blog/tag/outerposition/
>>>>>> Rather than minmargins, may I suggest you use "looseinset" as Matlab
>>>>>> does?
>>>>>> For the subplots, the looseinset may be set to some reasonable value by
>>>>>> the
>>>>>> subplot.m function.
>>>>>> Ben
>>>>>>
>>>>>>
>>>>>> Same article, but this time a direct link
>>>>>> http://undocumentedmatlab.com/blog/axes-looseinset-property/
>>>>>> Ben
>>>>>
>>>>> I am working on looseinset now. It shouldn't take long to implement.
>>>>>
>>>>> BR
>>>>>
>>>>> Kostas
>>>>
>>>> Hi Ben,
>>>>
>>>> in the attached changeset you can find a first implementation of
>>>> looseinset. The sync_position function relies now on looseinset instead
>>>> of default_axes_position.
>>>>
>>>> Known limitations: looseinset remains always in normalized units (since
>>>> it is a hidden property I see no need to support other kinds of units)
>>>>
>>>> Please test this patch and send me any comments.
>>>>
>>>> BR
>>>>
>>>> Kostas
>>>> <looseinset-1a.changeset>
>>>
>>> For consistency, how difficult is it to implement the units conversion? ...
>>> or maybe a more proper question is; Is there a reason that units conversion
>>> is prohibitive?
>>
>> the units conversion itself is not a problem, but how different units
>> for looseinset will be interpreted in sync_positions is not very
>> straightforward. My main concern however is that by adding further
>> checks and conversions to sync_positions it becomes heavier and heavier.
>> Since looseinset is not supposed to be accessed by users maybe it makes
>> sense to support only normalized units. This should be sufficient for
>> achieving a decent subplot behavior. What do you think?
>
> I'd thought the axes properties were always stored normalized, and that
> conversion only occurred when the user did a set/get from the m-file side.
> Meaning that accessing the axes properties on the c++ side would return
> values in the default units, and that units conversion had to be done
> explicitly.
>
> How does the conversion work on the c++ side? Can you not directly access the
> properties without triggering a conversion? ... if conversion always happens,
> then why isn't setting units="normalized" sufficient to fix the conversion in
> all cases (i.e. position, outerposition, tightinset, looseinset)? In either
> event, if units=="normalized" no conversion needs to be done, so I'm confused
> as why this is a problem. Am I making sense?
>
> Ben
I studied the code over the last few days. I now understand why leaving
looseinset in normalized units is preferred.
I think understand your point regarding the subplot behavior is correct as
well. For subplot the units won't matter since the looseinset would be set to
[0 0 0 0], is correct?
Please push the change. When that is done, I'll push a change for subplots and
run dump_demo to produce an updated page.
Ben
- Re: Outerposition Patch, (continued)
- Re: Outerposition Patch, logari81, 2011/02/18
- Re: Outerposition Patch, Ben Abbott, 2011/02/18
- Re: Outerposition Patch, Konstantinos Poulios, 2011/02/18
- Re: Outerposition Patch, bpabbott, 2011/02/18
- Re: Outerposition Patch, bpabbott, 2011/02/18
- Re: Outerposition Patch, Konstantinos Poulios, 2011/02/18
- Re: Outerposition Patch, logari81, 2011/02/18
- Re: Outerposition Patch, Ben Abbott, 2011/02/18
- Re: Outerposition Patch, logari81, 2011/02/19
- Re: Outerposition Patch, Ben Abbott, 2011/02/19
- Re: Outerposition Patch,
Ben Abbott <=
- Re: Outerposition Patch, Ben Abbott, 2011/02/22
- Re: Outerposition Patch, logari81, 2011/02/23
- Re: Outerposition Patch, Ben Abbott, 2011/02/23
- Re: Outerposition Patch, Ben Abbott, 2011/02/23
- Re: Outerposition Patch, logari81, 2011/02/23