nanogui: nanox+flnx problem
Subject:
Re: [nanogui] nanox+flnx problem
From:
Florian Berger ####@####.####
Date:
16 Jul 2002 11:14:52 -0000
Message-Id: <200207161100.g6GB0aV01045@evil.aec.at>
On Monday 15 July 2002 11:28 pm, Jordan Crouse wrote:
> > but actually the popup menus even pop up in the
> > wrong position, when the window was previously moved.
>
> Yep - thats a bug all right. The menus are created based on the x() and
> y() position of the menubar / menubutton, which gives us a relative
> value. Unfortunately, the window is creating a toplevel window with
> those values which will stick it relative to (0,0) on the root window.
> And to make matters worse, we try to mangle the X and Y values by
> looking at the Fl::event_x_root() and Fl::event_y_root() variables which
> may or may not be correctly offset for the window (I suspect that they
> are not).
>
> The solution is to calculate the correct initial offset for the window,
> and *then* find the offset of the widget, and *then* find the offset to
> the relative X and Y button event.
>
> Lots of printf()s will be needed in and about Fl_Menu.cxx to debug this,
> but I assume that the problem lies somewhere between the start of
> Fl_Menu_Item::pulldown() on line 563 and the creating of the menuwindow
> on line 661 or 684. Watch the value of X and Y and see that they are
> correct based on your calculations.
>
were there once absolute values passed by such functions?
because i observed the same problem with the direct framebuffer mapping and
the offsets passed there.
and i consider, the programmer who coded this, would have noticed that.
however, an interesting fact is, that the offset to the next upper level
window is added (e.g. the offset of the window titlebar and the border when
using nanowm).
why not switch to absolute values anyway?
is there something relying on relative coordinates?
so what to do?
-floh
