On 3/23/06, Yen-Ju Chen <[EMAIL PROTECTED]> wrote:
[...]
The wm just create a traditional X11 window, then reparent a few
NSWindows into it. These NSWindows are titlebar, resizebar, side borders, etc and including the tool bar which I think shouldn't be tied
to NSWindow but let the WM to manage it if supported since I
want to move toolbar of a focusable window to the top like this.
http://static.flickr.com/39/116692639_5934c648eb_o.png
(tool bars can be sliding down for the configurable toolbars)
So I think it's better if GNUstep implement toolbar at the backends, ie.
may be the code for display server should be more generic.
That's a good plan I think. Everybody else are also doing that already.
I guess I need more time to sit down and read wm-specs.
The only reason I want it to depend on NSWindow is to use some
AppKit features like DnD (eg. from the icon in title bar)
through existing code. That's what my 3rd layer would do.
[...]
What I was thinking is, may be etoile don't want a WM at all. Just
make a special thread to handle X events so we can move the
windows around when the app part is frozen. Then let the app
to decorate themselves. It is nothing to do with my plan either,
since at a certain point I'll finish WOOM. And so I won't need a WM
because WOOM will do all the window management jobs.
[...]
> AppKit and 3rd, AppKit layer which will use many
> NSWindows to do decoration so that you don't need to waste the
> memory in the middle area of each window. It will base on the current
> implementation of WMCore
I am not quite understand your 3-layers approaches.
The wm just create a traditional X11 window, then reparent a few
NSWindows into it. These NSWindows are titlebar, resizebar, side borders, etc and including the tool bar which I think shouldn't be tied
to NSWindow but let the WM to manage it if supported since I
want to move toolbar of a focusable window to the top like this.
http://static.flickr.com/39/116692639_5934c648eb_o.png
(tool bars can be sliding down for the configurable toolbars)
may be the code for display server should be more generic.
My approach is trying to decompose a regular window manager
into several small components, like taskbar, pager, etc.
That's a good plan I think. Everybody else are also doing that already.
I guess I need more time to sit down and read wm-specs.
Most of them can be GNUstep applications.
They all listen to the root window in XWindow system.
The real window manager is only responsible for window mapping and decoration.
Although I don't know how far I can go,
but if it can work out, the real window manager can be small,
may not depending on GNUstep NSWindow, but easier to maintain.
The only reason I want it to depend on NSWindow is to use some
AppKit features like DnD (eg. from the icon in title bar)
through existing code. That's what my 3rd layer would do.
> Didn't Quentin say that etoile doesn't need an X11 window manager?
Well, I would say it is not in the near future. :D
Yen-Ju
What I was thinking is, may be etoile don't want a WM at all. Just
make a special thread to handle X events so we can move the
windows around when the app part is frozen. Then let the app
to decorate themselves. It is nothing to do with my plan either,
since at a certain point I'll finish WOOM. And so I won't need a WM
because WOOM will do all the window management jobs.
_______________________________________________ Etoile-discuss mailing list [email protected] https://mail.gna.org/listinfo/etoile-discuss
