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.
For the name, I'm fine with AzaleaKit too (even if it's not strictly
bound to Azalea).
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.
We can either subclass or extend NS-class with category.
But mixing NS-class and xwindow stuff may have some side effect.
The other way is to have an independent WM-class from NS-class.
I think independent classes are a better way to take.
Since NSWindow is the most used one and has a xwindow inside,
the first approach should be fine.
GSDisplayServer and NSScreen is usually called from GSCurrentServer()
and [NSScreen mainScreen].
Therefore, we can only use category to override some methods,
which make things messy.
And not many people use them directly.
So the second approach might be better.
We can call the selectors shadowed by the ones in the categories,
that would allow us to keep GNUstep methods consistent, but well the
second approach remains better imo.
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 ?
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.
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
