nanogui: Thread: window manager support in nano-X

I'm interested in hacking up some basic window manager support for
nano-X.  Is anyone else looking into this, or has someone thought much
about it in the past?

I'd use a model similar to the way X works.  Basically, when client A
tries to map window W, if client B is requesting SubStructureRedirect
on the parent of W, then instead of actually mapping W, the server
generates a MapRequest event and passes it to B.  (Unless A == B, in
which case it justs maps W.)  So assuming B is the window manager,
then it creates the frame window, and reparents W into the frame, then
maps both the window and the frame.

Pretty much all this stuff is currently unimplemented in nano-X,
including the ability to reparent.  But I don't think it sounds that
hard.  (famous last words)

Anyone have any thoughts?

-- 
1/2 tsp horseradish, 1/2 tsp Tabasco sauce, and a shot of tequila

Daniel Risacher                               ####@####.####

: I'm interested in hacking up some basic window manager support for
: nano-X.  Is anyone else looking into this, or has someone thought much
: about it in the past?
: 
If you've got the time, I suggest to go for it.  There's been some talk
but no coding in this area.



: I'd use a model similar to the way X works.  Basically, when client A
: tries to map window W, if client B is requesting SubStructureRedirect
: on the parent of W, then instead of actually mapping W, the server
: generates a MapRequest event and passes it to B.  (Unless A == B, in
: which case it justs maps W.)  So assuming B is the window manager,
: then it creates the frame window, and reparents W into the frame, then
: maps both the window and the frame.

Sounds good.  My request is that you try to keep it simple,
especially in the beginning.


: 
: Pretty much all this stuff is currently unimplemented in nano-X,
: including the ability to reparent.  But I don't think it sounds that
: hard.  (famous last words)

If you go after it in the manner described above, by adding a new maprequest
event, and then just have the server resend the request, it shouldn't
be much work.  Also, instead of the server drawing any borders, requests
get sent to another process for that draw code as well.

Are you planning on adding some cool-looking window draw code?

Greg

Dan,
	Actually, as I start to think about this, it also might be a good idea 
to think about having a very simple API that would allow the server draw
code to be "resent" to another set of procedures.  In this way, we wouldn't
require that the window manager be another process.  Microwindows currently
runs on single-tasking systems and it might be nice to not require a separate 
process to handle mere window dressings.

Perhaps we should start a discussion on exactly what a window manager
[process | api] would bring to Nano-X.  Certainly it would start with the following:

	o drawing window borders, title bars
	o managing mouse events in those areas for window moves and exits
	o handling mouse clicks on the root window

The draw code could be fairly easily moved out of the server now, and an
api developed that doesn't require client/server interaction to achieve the above.
If client/server interaction is desired, then the project could be further extended (and
enlarged) to accomodate these additional needs.

Greg


On Monday, November 22, 1999 12:50 PM, Greg Haerr ####@####.#### wrote:
: : I'm interested in hacking up some basic window manager support for
: : nano-X.  Is anyone else looking into this, or has someone thought much
: : about it in the past?
: 

>>>>> "Greg" == Greg Haerr ####@####.#### writes:

    Greg> Dan, Actually, as I start to think about this, it also might
    Greg> be a good idea to think about having a very simple API that
    Greg> would allow the server draw code to be "resent" to another
    Greg> set of procedures.  In this way, we wouldn't require that
    Greg> the window manager be another process.  Microwindows
    Greg> currently runs on single-tasking systems and it might be
    Greg> nice to not require a separate process to handle mere window
    Greg> dressings.

Well, I see Microwindows as being the right solution for very small
processors (single tasking), and nano-X as being the right solution
for slightly more capable systems.  X11R6 is the right solution for
desktop systems, and WinNT is the right solution for boat anchors.
(grin)

I'm not sure what you're envisioning in the paragraph above.  Care to
elaborate?

-- 
                       What color is green?

Daniel Risacher                                   ####@####.####

>I'd use a model similar to the way X works.  Basically, when client A
>tries to map window W, if client B is requesting SubStructureRedirect
>on the parent of W, then instead of actually mapping W, the server
>generates a MapRequest event and passes it to B.  (Unless A == B, in
>which case it justs maps W.)  So assuming B is the window manager,
>then it creates the frame window, and reparents W into the frame, then
>maps both the window and the frame.
>
>Pretty much all this stuff is currently unimplemented in nano-X,
>including the ability to reparent.  But I don't think it sounds that
>hard.  (famous last words)

Is it definitely necessary to reparent the window? I have a feeling this was
only done on the first X window managers because there was no way to draw a
non-rectangular frame window, so you had to reparent the client window into
the frame to get a border on all four sides. If you were willing to settle for
a titlebar, you might not have to reparent the window. I think. Maybe.

Michael Rogers

>>>>> "Michael" == Michael ROGERS ####@####.#### writes:

    >> Pretty much all this stuff is currently unimplemented in
    >> nano-X, including the ability to reparent.  But I don't think
    >> it sounds that hard.  (famous last words)

    Michael> Is it definitely necessary to reparent the window? I have
    Michael> a feeling this was only done on the first X window
    Michael> managers because there was no way to draw a
    Michael> non-rectangular frame window, so you had to reparent the
    Michael> client window into the frame to get a border on all four
    Michael> sides. If you were willing to settle for a titlebar, you
    Michael> might not have to reparent the window. I think. Maybe.

As far as I can tell, current windowmanagers reparent the window.
Certainly Enlightenment does.  I believe that this is the right
solution.  You don't want to drag the titlebar, you want to drag the
whole package.

You can demonstrate this for yourself with the command, 
	xwininfo -frame -tree
and then click on a window titlebar.

-- 
                       What color is green?

Daniel Risacher                                   ####@####.####