Re: units updater for figures is broken when using fltk

[Michael Goffioul]

On Sun, Feb 5, 2012 at 12:35 AM, Ben Abbott <address@hidden> wrote:
> This diff below worked for me, but I liked your suggestion of using the 
> get_boundingbox better.
>
> ----------------------
> diff --git a/src/DLD-FUNCTIONS/__init_fltk__.cc 
> b/src/DLD-FUNCTIONS/__init_fltk__.cc
> --- a/src/DLD-FUNCTIONS/__init_fltk__.cc
> +++ b/src/DLD-FUNCTIONS/__init_fltk__.cc
> @@ -1173,7 +1173,10 @@
>
>   void draw (void)
>   {
> +    octave_value funits = fp.get_units ();
> +    fp.set_units (octave_value ("pixels"));
>     Matrix pos = fp.get_position ().matrix_value ();
> +    fp.set_units (funits);
>     Fl_Window::resize (pos(0), pos(1), pos(2), pos(3) + status_h + menu_h);
>
>     return Fl_Window::draw ();
> ----------------------

It might solve your problem, but this is not a good solution imo. What
if the user attached a listener to the units property?

> Unfortunately, it looks to me as if get_boundingbox returns the wrong result. 
>  I tried the change below ...
>
> ----------------------
> --- a/src/DLD-FUNCTIONS/__init_fltk__.cc
> +++ b/src/DLD-FUNCTIONS/__init_fltk__.cc
> @@ -1173,7 +1173,7 @@
>
>   void draw (void)
>   {
> -    Matrix pos = fp.get_position ().matrix_value ();
> +    Matrix pos = fp.get_boundingbox (true);
>     Fl_Window::resize (pos(0), pos(1), pos(2), pos(3) + status_h + menu_h);
>
>     return Fl_Window::draw ();
> ----------------------
>
> The result was what appeared to be an infinite loop, that produced a very 
> large figure that rendered mostly to the right of my screen.
>
> Am I missing something, or is the get_boundingbox result due to your comment 
> regarding Matlab world above [1].

I think the problem is not in get_boundingbox, but in the incorrect
interpretation of the position property in the FLTK code. Moreover,
the code is probably not robust against feedback loops when changing
properties, like:
1) the user change figure position
2) the backend is notified and move/resize the figure window
3) as in any toolkit, moving/resizing the window triggers corresponding events
4) the backend receives events and propagates the changes back to the
figure position (this is needed as the move/resize could be the result
of a user action with the mouse)
5) if the newly computed position does not match the previous one, goto 1)

Step 4) above should not happen when the position change is coming
from octave, but I suspect it does, which can explain the infinite
loop you're seeing.

Michael.