Re: units updater for figures is broken when using fltk

[Ben Abbott]

On Feb 12, 2012, at 2:38 PM, Michael Goffioul wrote:

> On Sun, Feb 12, 2012 at 5:14 PM, Ben Abbott <address@hidden> wrote:
> 
>>>>> If there is no objection, I'll push the change later today. First I want 
>>>>> to look at the impact on a few other bugs and run the dump demos script.
>>>> 
>>>> I don't have an objection, but I find the patch too complicated. The
>>>> FLTK backend should simply use get_boundingbox and set_boundingbox
>>>> functions.
>>>> 
>>>> Michael.
>>> 
>>> Michael,
>>> 
>>> To simplify things, the get_boundingbox and set_boudingbox methods for 
>>> figure objects can be modified to set the origin in the UL corner.
> 
> They already do. That's (partially) why they're made for.

Currently the position property for objects has its origin at the UL, and the 
boundingbox methods shift this to the LL (same a postscript).

>>> Do you think this is an appropriate approach?
>>> 
>>> Or, might a 3rd boolean input be added get_boundingbox to allow the origin 
>>> to be selected as LL or UL ?
> 
> Possibly, but I don't see the usefulness at the moment. Any windowing
> toolkit I know always uses the UL corner as origin. Only Matlab
> doesn't use that reference, god only knows why... ;)

ah-ha ... I see why I've been confused by your comments.

You are correct, Matlab does use the LL as its reference for the figure's 
position property, but Octave's fltk toolkit is using the UL.

I ran the code below with 3.6.1-rc1and the default branch. Both give the same 
result.

        close all
        graphics_toolkit gnuplot
        figure (1, "position", [50 50 400 300])
        graphics_toolkit fltk
        figure (2, "position", [50 50 400 300])

Figure 1 is in the LL corner of the screen, and figure 2 is in the UL corner.

Octave's backends are not behaving the same for me on MacOS X or Ubuntu. Looks 
like a bug.

Ben