nanogui: nanox+flnx problem


Previous by date: 16 Jul 2002 14:57:48 -0000 Re: nanox+flnx problem, Florian Berger
Next by date: 16 Jul 2002 14:57:48 -0000 Re: nanox+flnx problem, Florian Berger
Previous in thread: 16 Jul 2002 14:57:48 -0000 Re: nanox+flnx problem, Florian Berger
Next in thread: 16 Jul 2002 14:57:48 -0000 Re: nanox+flnx problem, Florian Berger

Subject: Re: [nanogui] nanox+flnx problem
From: Jordan Crouse ####@####.####
Date: 16 Jul 2002 14:57:48 -0000
Message-Id: <1026830553.17785.1530.camel@cosmic>

> 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?

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



Previous by date: 16 Jul 2002 14:57:48 -0000 Re: nanox+flnx problem, Florian Berger
Next by date: 16 Jul 2002 14:57:48 -0000 Re: nanox+flnx problem, Florian Berger
Previous in thread: 16 Jul 2002 14:57:48 -0000 Re: nanox+flnx problem, Florian Berger
Next in thread: 16 Jul 2002 14:57:48 -0000 Re: nanox+flnx problem, Florian Berger


Powered by ezmlm-browse 0.20.