On 5/18/06, Quentin Mathé <[EMAIL PROTECTED]> wrote:
Le 18 mai 06 à 06:46, Yen-Ju Chen a écrit :
> I looked at the code, and it is pretty much what we can have.
> I have something at lower-level from Azalea,
> like setting and getting properties from xwindow.
> We can put them together, probably called WindowManagerKit with WM
> prefix.
WindowServerKit (then WS prefix) could be better since we are going
to talk with X11 server and not only the WM (at first sight).
Moreover we may other window servers later (in case we are running on
Windows or without X11). For the last point, I'm not sure it makes
sense, depends whether the code is going to be too closely related to
X11 or not.
WindowServerKit is good, or XWindowServerKit (see below).
> There are two ways to implement WindowManagerKit in my mind.
> One is to extend NSWindow, NSScreen and GSDIsplayServer.
> For example, [NSScreen -numberOfWorkspaces] or [NSWindow -
> setDesktop:].
I'm not really convinced by both examples. To me, it doesn't make
sense to associate Workspaces to NSScreen and Desktop to NSWindow.
I think we have two different approaches for this WindowServerKit.
To me, GNUstep already use x window system with x11 backend.
What I want is to fill the gap between GNUstep and xwindow.
I am not going to write a whole new backend on xwindow.
It doesn't make much sense. GNUstep already did that.
That's why I prefer to subclss from NSWindow.
It is simply because NSWindow already wrap the xwindow on x11 backend.
So does NSScreen and GSDisplayServer.
I just want to expose more functions from xwindow.
In the other word, everything use this WindowServerKit will depend on xwindow.
Maybe we should just call it XWindowServerKit. :D
If people want to have another WinderServerKit which will potentially work for
any other platform/backend,
it is a huge task and I don't see it coming in the near future.
And it is actually a task of backend.
[snip]
> I am still thinking about how to put everything in together.
> Probably an WMServer talks to x window directly and provide all the
> low-level methods.
> WMScreen and WMWindow use this WMServer to access x window.
> WMServer and WMScreen are subclasses of NSObject
> and WMWindow is subclass of NSWindow.
What is the interest of making WMWindow a subclass of NSWindow ?
As mentioned above, it allows NSWindow use more xwindow functions
since NSWindow is a xwindow underneath.
Here is my proposal. Well I'm ignoring most of the implementation
details right now, so I'm perhaps missing the point :-)
I would use a main Server class with utility methods, a class like
DisplayArea unifying/abstracting both Workspace and Screen
representations. In other words, when a DisplayArea (by default
representing just a Workspace) is mapped to a screen, you can
manipulate it as a Screen.
While you are trying to abstract the x window system here,
I am trying to be more tied with x window system.
That's more practical and can be done in the near future
and provide users something concrete instead of a vaporware.
With this XWindowServerKit,
we can make EtoileMenuServer show up in every workspace through WMWindow
and it will not be blocked by any other windows.
We can have a menulet to switch workspace.
We can have a dock application which can not only manage GNUstep applications,
but also any other xwindow applications including dock app.
We can also have a preference to set the background of x window desktop.
All of these applications are tied with xwindow.
People can still use all the functions from NSWindow since WMWindow
is a subclass of NSWindow.
WMWindow simply provide something existing on xwindow system,
but missing in NSWindow.
Same things apply to NSScreen and GSDisplayServer.
I have my proposal of interface in another mail in this thread.
It basically explains the extension of NSWindow and other classes.
Yen-Ju
Server
- numberOfDisplayAreas
- displayAreaAtIndex:
etc.
/* Various Window Server specific utility methods */
- setWindowFrame: withTransition:
- clients
etc.
/* Various X11 Window Server specific utility methods (in a category
probably) */
- setAtom: forName:
- atomForName:
etc.
/* We can put most of Windows related interactions in the Server
class, I'm not sure a separate class is really needed since NSWindow
provide most of the things we need. Then another way could be to use
the first proposal based on categories, but only for Window by
extendings NSWindow. */
DisplayArea
- setDesktop:
- desktop
- isVirtual
YES would mean the displayArea is a Workspace but not mapped to a
screen currently.
NO would mean the displayArea is a Workspace currently visible.
- screenNumber
Would an invalid number when -isVirtual returns YES
- mapToScreen:
- unmapFromScreen
etc.
Cheers,
Quentin.
--
Quentin Mathé
[EMAIL PROTECTED]
_______________________________________________
Etoile-dev mailing list
[email protected]
https://mail.gna.org/listinfo/etoile-dev
_______________________________________________
Etoile-dev mailing list
[email protected]
https://mail.gna.org/listinfo/etoile-dev
