nanogui: Suggestion for adding nanowm into graphic server!
Subject:
Re: [nanogui] Suggestion for adding nanowm into graphic server!
From:
"Greg Haerr" ####@####.####
Date:
4 Aug 2002 19:46:56 -0000
Message-Id: <034101c23bed$a1a02470$6401a8c0@gregnewport>
With regards to how to build a linked-in
window manager for nano-X:
1) I don't think it would be a good idea to
add special "container" window types
and another linked list etc into the
server. I will shortly have the X11-style
override-redirect window attribute working
in nano-X, which will make all the existing
attempts at preventing the app window
from displaying twice to be unnecessary.
2) I think it could be a good idea to
be able to include a WM linked with nano-X.
However, it's important that _any_ WM be
able to be linked into the server. In addition,
arbitrary GrXXX paint function calls will
be necessary to allow different window
painting schemes. Also, the scheme that allows
the WM to receive any requested events should
remain exactly as it is now. Instead,
a small internal WM* api could be created,
which uses a callout mechanism to send
events to a linked-in portion of the program.
Vis:
WMIRegister(cbproc) - register internal window manager
WMISelectEvent(event_masks) - register events
Then, in each of the GrDeliverXXXEvent routines,
call cbproc(event) to notify the internal window
manager of the events it's requested.
An issue here will be to ensure that the GrDeliverEvent
routines are called as the last part of each
GrXXX function, so that arbitrary Gr* functions can
be called by the built-in WM.
Comments?
Regards,
Greg
In the former mails,I have mentioned that
I want to add the nanowm into server,but I'm
not sure about it untill now.
Just as Alex has said may be it can't
contribute too much to the speed .but I think
it can do .
For the sake of keeping consistency ,I do
not want to change data structures and basic
fuction of every API .I find that acturally the
nanowm just include two parts.first it should
creat a container window as the parent of the
new client window ,second wait for the event and
deal with the event .
So if we add nanowm to the graphic server ,
we should make sure where should we implement these
two parts .for the first part ,I wanna modify the
code of Grnewwindow()[newwindow()] ,so we needn't do
it when a the client window be mapped ,at this
moment we first creat a container window structure
and then creat the client window with the container
as its parent,acturally I want to add a new parameter
to determine if we should creat a container and what
style of container we should creat ,but I'm afraid
it will do harm to the capability .and this moment
we also should creat win structure for the WM ,
calculate there position,in fact I want it complete
the work that new_client_window() does in nanowm,so
this is the first part.
For the second part .I wanna put the disposal at
the very end of the server loop .And wrap the disposal
as a fuction .so we can compile or not compile it.this
fuction should search the Gr_window structure list to
find the containner window and deal with its event .And
for speed reason we also can relink container windows
in another list.
These are my opinion ,and need any suggestion .
****************************************************************************
all my effort is to make our new graphic system faster and more stable.
wang
####@####.####
2002-08-04
---------------------------------------------------------------------
To unsubscribe, e-mail: ####@####.####
For additional commands, e-mail: ####@####.####
