nanogui: Thread: new_client_window(GR_WINDOW_ID wid)

Greg,Alex:

   In the fuction new_client_window(GR_WINDOW_ID wid),
I read these line:
 "/* remap the window without borders, call this routine again*/
		GrMapWindow(wid);"
   After we reparent the client with nanowm ,we should 
map the nanowm window and remap its children window
(the GrMapWindow can do so),do we need at this moment
to remap the client window?	can you explain this?
  
   And in the function too,at the comment it wrote:	
 /* reparent client to container window*/
	/* must map before reparent (nano-x bug)*/
	GrMapWindow(pid);/*make it visible*/
	GrReparentWindow(wid, pid, xoffset, yoffset);
now I also want to know your explanation.?	

   Thanks in advance>	

　　　　　　　　wang
####@####.####
　　　　　　　　　　2002-07-27

wang wrote:
>    In the fuction new_client_window(GR_WINDOW_ID wid),
> I read these line:
>  "/* remap the window without borders, call this routine again*/
> 		GrMapWindow(wid);"
>    After we reparent the client with nanowm ,we should 
> map the nanowm window and remap its children window
> (the GrMapWindow can do so),do we need at this moment
> to remap the client window?	can you explain this?

That comment is confusingly written isn't it? I had to try it out for
myself to find out what it meant... What it means is that when you unmap
the window and map it again to get rid of a border (bear in mind that
almost no applications do actually use borders and I'd say there's a
good argument for removing the feature altogether), an unmap event and
another map event are generated. The unmap event is ignored because
nanowm doesn't have a record of that window (we return from
new_client_window() before it's added to the window list), and the map
event causes new_client_window() to get called again but this time for a
window that doesn't have a border, so it carries on and creates the
container etc. If we were to do what seems like the more sensible thing
and unmap the window, get rid of the border, reparent it, remap it, then
 map the container, what actually happens is that the event from when
the client window was unmapped causes it to think the application closed
the window, which makes it unmap the container window. Think of it as a
slightly ugly hack to work around an obsolete feature that is almost
never used.

>    And in the function too,at the comment it wrote:	
>  /* reparent client to container window*/
> 	/* must map before reparent (nano-x bug)*/
> 	GrMapWindow(pid);/*make it visible*/
> 	GrReparentWindow(wid, pid, xoffset, yoffset);
> now I also want to know your explanation.?	

I don't know anything about the bug it refers to there. I just tried
swapping the two lines and it didn't seem to have any ill effect.

-- 
------------ Alex Holden - http://www.linuxhacker.org ------------
If it doesn't work, you're not hitting it with a big enough hammer

 >    And in the function too,at the comment it wrote: 
> >  /* reparent client to container window*/
> > /* must map before reparent (nano-x bug)*/
> > GrMapWindow(pid);/*make it visible*/
> > GrReparentWindow(wid, pid, xoffset, yoffset);
> > now I also want to know your explanation.? 
> 
> I don't know anything about the bug it refers to there. I just tried
> swapping the two lines and it didn't seem to have any ill effect.
>

The GrReparentWindow function is buggy
in all versions of Microwindows; I've just 
finally fixed this function.  The internal
reason for this bugginess was that Microwindows
previously kept an "unmapcount" value for
a window which as incremented fpr each
ancestor a window had, rather than just
keeping a boolean "visible" value.  Thus,
when a window was reparented to a new parent
that had a difference ancestry count, it
didn't work.  By forcing a window
to be mapped before reparented, the unmapcount
was 0, and the bug didn't apply.  In any case,
I've fixed all this now.

Regards,

Greg

** Proprietary **

Hi,
We are using a Embedix SDK2.0 in our project and also want to use Microwindows.When deploying through ch root method we are unable to open the microwindows application in Embedix.
We have included the Microwindows option in target wizard.We always get a error saying"Error opening /dev/FB0 No such device cannot  initialise screen. Check kernel config".

Please suggest

Regards
somshekhar umadi

Sounds like the path to /dev/fb0 isn't available from
your chroot'd filesystem root.  You'll probably need to
link in /dev/fb0 appropriately.  You will also need a
writeable /tmp as well, if you're running nano-X API.

Regards,

Greg


** Proprietary **

Hi,
We are using a Embedix SDK2.0 in our project and also want to use
Microwindows.When deploying through ch root method we are unable to open the
microwindows application in Embedix.
We have included the Microwindows option in target wizard.We always get a
error saying"Error opening /dev/FB0 No such device cannot  initialise
screen. Check kernel config".

Please suggest

Regards
somshekhar umadi