On 5/18/06, Nicolas Roard <[EMAIL PROTECTED]> wrote:
On 5/18/06, Yen-Ju Chen <[EMAIL PROTECTED]> wrote:
> A single class is fine. It is just a C-to-ObjC translation of x
> window functions.
> But why not to be more object-oriented ?
oh well it's just that most of the things are operations on a
"workspace" (eg we ask the workspace to do something for us), so I was
thinking it would be easier for developers
to have just one "public" class to do that. Doesn't prevent us to have
more behind-the-scene classes to implement that neatly in proper OO
fashion.
> And GNUstep is abstract from backend already.
> That's why we need a WindowManagerKit to access x window now. :)
> If we add another layer of abstract, it is just redundant in my own
opinions.
Not really -- GNUstep is indeed abstracted from X, but here we're not
using GNUstep methods : we want to ask for specific actions at the
workspace level.. And those actions are not in gnustep, hence
WindowManagerKit. As they are not in GNUstep, well, they obviously are
not abstracted. So that's why we need to abstract them, so eg if you
use WindowManagerKit, it will work the same from the application
developer's point of view if it runs on X11 or on another display
system such as DirectFB.
I don't think it's redundant, but I'm perhaps missing something.
Well, x window doesn't always act on workspace.
Actually, most of them are on windows, but GNUstep take care most of them,
say [NSWindow -setFrame:] or [NSWindow -orderFront:].
X window provides these objects:
Display (GSDisplayServer)
Screen (NSScreen)
Window (NSWindow).
A display can have many screens and a screen can have many windows.
There is no workspace by default in x window.
Workspace is faked by window manager and accepted by most of people.
So now, a screen can have many workspaces, and a workspace can have
many windows.
In order to have the discussion more pratical,
here are the headers in my mind:
@interface WMServer: NSObject
/* All the low-level methods talking directly to x window */
@end
@interface NSScreen (WMScreen)
- (int) numberOfWorkspaces;
- (NSArray *) workspaces; /* return names of all workspaces in order */
- (void) setNumberOfWorkspaces: (int) number;
- (void) setWorkspaces: (NSArray *) workspaces /* names of all
workspaces in order */
- (NSArray *) allClients; /* Get all clients on this screen */
- (NSArray *) allClientsOnWorkspace: (int) workspace; /* All clients
on workspace */
@end
#define ALL_DESKTOP 0xFFFFFFFF
@interface WMWindow: NSWindow
/* Move window to workspace or ALL_DESKTOP for all desktops */
- (void) setWorkspace: (int) workspace;
/* Do not show up in taskbar and pager */
- (void) skipTaskbarAndPager: (BOOL) boolean;
/* Reserve a space which will not be covered by any window,
mostly for menu bar or dock */
- (void) setStrut: (Strut) strut;
@end
You can have [WMServer moveWindow: toWorkspace:].
However, it does not make much sense to me that you can have [NSWindow
-setFrame:] to change the position and size of NSWindow,
but have to use WMServer to change the screen (workspace) of a window.
Yen-Ju
--
Nicolas Roard
"I love deadlines. I like the whooshing sound they make as they fly
by." -- Douglas Adams
_______________________________________________
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
