Re: Patches for autopositioning of labels in fltk

[logari81]

On Wed, 2010-12-08 at 19:39 -0500, Ben Abbott wrote:
> 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
> 

The clipping property was the culprit for the disappearing labels.
Please merge the attached changeset with the previous one and you should
receive a behavior for the fltk backend which is quite compatible with
ML.

There are still some smaller issues:

1. When setting a label from a text handle, the fontsize of the text is
kept, like also in ML. The problem is that in Octave we have different
default sizes for {xyz}label and text. Default fontsize for labels is
12, while default fontsize for text is 10. This can cause a bit of
confusion.

2. It seems that there are some inconsistencies with the z position
coordinate of label and text objects but I haven't found a test case
yet, where this causes problems. Anyway I think one should go through
octave and just make sure that all default z coordinates for 2D objects
are consistent with ML, just to avoid trouble in the future.

BR
Kostas

disable_label_autoposition_standalone_part2.changeset
Description: Text document