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.