nanogui: nanox+flnx problem
Subject:
Re: [nanogui] nanox+flnx problem
From:
Florian Berger ####@####.####
Date:
16 Jul 2002 18:34:52 -0000
Message-Id: <20020716202107.2fb05f16.harpin_floh@yahoo.de>
On 16 Jul 2002 08:42:33 -0600
"Jordan Crouse" ####@####.#### wrote:
> FLNX uses a very annoying mix of relative and absolute coordinates -
> looking at FLTK, most of it should be relative, except for dialog
> boxes and menus.
>
> However, the original person who ported this was unaware of that, and
> coded everything with absolute coordinates, which wasn't a problem
> because we didn't use window managers, so everything was based off of
> root (0,0) to begin with. It was only when we started moving windows
> around that we discovered the problems.
>
> So we fixed the problems the best we could, but we still had problems
> with the menu windows. At that point, we were using a 240x320
> screen, so we worried about offsetting for the titlebar, but since
> windows were not moving around, we didn't worry about fixing the menu
> windows completely.
>
> So, short story - there were problems when porting the original FLTK
> that continue to manifest themselves to this day. We have put on a
> few band aids, but please don't consider this a reasonable solution.
>
> What we need to do is to fix the menu windows completely - and account
> for the absolute position of the window by traversing the list of
> parent windows and adding the offsets - you can find out the position
> of any window N by using the following algorithm:
>
> int x = 0, y = 0;
>
> while(N) {
> GrGetWindowInfo(N, &info);
> x += info.x;
> y += info.y;
> N = info.parent;
> }
>
> This should be a good first step in determining the correct position
> for the menu windows.
>
> Jordan
i did this already for the clientside direct framebuffer access and
posted it to greg.
however, with flnx, it is quite more complicated, because one needs to
get back to the level of x.h or n_x.h for nanox.
bacause, as i saw, the positions of the rootlevel window are stored at
the beginning as instances of the Fl_Widget, but are never changed, when
the window is moved in nano-X, i dont even know if the initial placement
is correct (as passed in the constructor Fl_Window(...)).
so one would have to implement some rootlevel x(), y() func in x.h (or
n_x.h) which are called when the window is a toplevel window (otherwise
just the instances x_ and y_ are returned).
e.g. in Fl_Widget.h
FL_EXPORT int x() const {if (!parent()) return ???; else return x_;}
where ??? sould be some toplevel method x() of Fl_X
this would maybe solve the remaining problems, because i saw, that all
the parent window offsets are summed up correctly by the menu class, but
the offset of the rootwindow is in no relation to the momentary
placement in nano-X.
or is there any better solution?
regards,
floh
