octave-maintainers
[Top][All Lists]
Advanced

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

Re: Patches for escalated value setting in base_property and autopositio


From: Ben Abbott
Subject: Re: Patches for escalated value setting in base_property and autopositioning of labels in fltk
Date: Wed, 08 Dec 2010 19:39:20 -0500

On Dec 8, 2010, at 6:17 PM, logari81 wrote:

> On Wed, 2010-12-08 at 21:32 +0000, bpabbott wrote:
>> On Dec 08, 2010, at 12:05 PM, logari81 <address@hidden>
>> wrote:
>> 
>>> On Wed, 2010-12-08 at 16:13 +0000, bpabbott wrote:
>>>> On Dec 08, 2010, at 10:54 AM, logari81 <address@hidden>
>>>> wrote:
>>>> 
>>>>> Hi all,
>>>>> 
>>>>> I have recently started seeking ways for implementing the
>>>>> "tightinset"
>>>>> property in the fltk backend. Though, before I can do any
>>> progress
>>>>> on
>>>>> this issue, there is a bug with title and labels positioning
>>> which
>>>>> has
>>>>> to be fixed.
>>>>> 
>>>>> Currently running
>>>>> xlabel('x label', 'rotation', 90)
>>>>> with the fltk backend will have no effect on the orientation of
>>> the
>>>>> xlabel.
>>>>> 
>>>>> In order to fix this bug it is necessary to distinguish when the
>>>>> position/rotation of a text object is explicitly set by the
>>> user, so
>>>>> that the auto-positioning is correspondingly disabled.
>>>>> 
>>>>> I haven't found a way to mark a property as set by the user or
>>> set
>>>>> by
>>>>> octave, so I decided to extend the base_property object with a
>>> flag
>>>>> named "weak" which can be used to distinguish if a property is
>>> set
>>>>> "weakly", for example when its value is guessed by octave, or
>>>>> "strongly", for example when it is set explicitly by the user.
>>> The
>>>>> implementation of the corresponding infrastructure is included
>>> in
>>>>> the
>>>>> first changeset: "base_property_weak.changeset". Any other
>>>>> suggestions
>>>>> are more than welcome.
>>>>> 
>>>> 
>>>> Other properties have a "mode" which can take values of "auto" or
>>>> "manual". For consistency can the same nomenclature be used?
>>>> 
>>>> 
>>>> For reference, I did check Matlab's behavior. Matlab does appear
>>> to
>>>> have a hidden (AFAIK) method to track when the position/rotation
>>> is
>>>> set automatically or set manually by the user.
>>>> 
>>>> 
>>>> Ben
>>>> 
>>>> 
>>> 
>>> Maybe using additional properties like
>>> 
>>> rotationmode
>>> positionmode
>>> horizontalalignmentmode
>>> verticalalignmentmode
>>> 
>>> would be the simplest solution. Though I believe that these
>>> properties,
>>> if used, then they should be hidden, otherwise the user is
>>> overwhelmed
>>> with unnecessary information. Are there currently other hidden
>>> properties present in octave so that I can use them as an example in
>>> order to provide an alternative fix based on this idea?
>>> 
>>> BR
>>> 
>>> Kostas
>> 
>> 
>> My original thought was that "auto"/"manual" would be more consistent
>> with the current nomenclature than "weak"/"strong". I have no strong
>> opinion as to how this should be implemented ... provided the
>> implementation could be used for the gnuplot backend as well. I think
>> you're original approach or one which adds new properties would be ok.
>> 
>> 
>> My understanding is that the xlabel, ylabel, zlabel, and title objects
>> are all normal text objects. Using Matlab they can be set to other
>> text objects.
>> 
>> 
>> For example ...
>> 
>> 
>> plot (1:10)
>> hx = xlabel ('X Label');
>> ht = text (5, 5, 'Hello World');
>> set (gca, 'xlabel', ht);
>> 
>> 
>> Will result in the axes property xlabel being set equal to ht. Doing
>> this will delete the original hx object. An unexpected change is that
>> the position and rotation properties of the text object corresponding
>> to ht are set to the "auto" values.
>> 
>> 
>> Regarding the properties you suggested, my understanding is that
>> properties that are intended to be private are given names that with
>> leading and trailing "__" characters.
>> 
>> __rotationmode__
>> __positionmode__
>> __horizontalalignmentmode__
>> __verticalalignmentmode__
>> 
>> In case you're unfamiliar with it, you can use the "addproperty"
>> function to add to the text objects as they are assigned to the
>> xlabel, ylabel, zlabel, or title properties.
>> 
>> Ben
> hmm, in the attached file there is a second try to fix the issue
> mentioned in my previous email without modifying the available
> infrastructure. I think it is a more elegant solution than the previous
> one. Furthermore the new hidden properties
> 
> positionmode
> rotationmode
> horizontalalignment
> verticalalignment
> 
> can be accessed and reused in order to provide a corresponding
> functionality in the gnuplot backend. I haven't included the underscores
> in the names, since there are other hidden properties with normal names
> as well.
> 
> The attached patch doesn't depend on the previous two and seems to work
> quite well. Please test it.
> 
> Best regards
> 
> Kostas
> <disable_label_autoposition_standalone.changeset>


I tested it. Your changeset permits the position and rotation to be set.

I see a couple of small problems. When I type ...

        backend fltk
        close all
        hx = xlabel ("xlabel");
        px = get (hx, "position");
        ht = text (0.5, 0.5, "Hello World");
        set (gca, "xlabel", ht);

This correctly deletes the text object with handle, hx. It also correctly 
horizontally centers the text object with handle, ht (which I hadn't noticed 
earlier).  However, the position does not move to the auto position, as it is 
does in Matlab

Also, If I type ...

        set (ht, "position", px)

The label moves, but is isn't visible. Is it being cropped? 

Ben



reply via email to

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