Re: Reasons for a GStep windowmanager

[Philippe C . D . Robert]

Richard Frith-Macdonald <richard@brainstorm.co.uk> wrote (Sat, 6 Jan 2001 
19:20:26 +0000):
> > it provides the unique feel of NEXTSTEP. WindowMaker isn't IMHO of great 
> > use for that w/o 
> > major changes and additions.
> 
> But certainly no more changes/additions than would be required for any other 
> wm.
> 
> > The argument that one can disable a lot of functions (clip, 
> > dock etc.) is a no-go to me, since the default RPMs found and used in most 
> > distros are not 
> > compiled like that and never will be.
> 
> Should be easy enough to make them runtime rather than compile time options 
> and have
> them automatically de-activated on systems where GNUstep equivalents are 
> available.
> 
> The actual design/architecture of Window Maker is IMO pretty good for a 
> C-based
> application.  While as a GNUstep/ObjC programmer I think there are some 
> fairly obvious
> ways elements of the code and modularity could be improved easily using OO 
> design
> and things like bundles, the code is in pretty good shape, and the mere 
> existence
> of things like the dock in Window Maker has not compromised the program as a 
> whole.
> 
> At least with Window Maker the basic look is right, an initial userbase is 
> there,
> and there is a willingness by the maintainers of the project to incorporate 
> changes
> needed by GNUstep (even if they aren't going to code them themselves).

Don't get me wrong, I very appreciate WM and I believe it is a very good 
application. I also think that the required changes could be done in the WM 
code base, with some caveats:

- Everything should be done in the main code tree, that is splitting has to be 
avoided! But then again, who would like to install the gnustep makefiles just 
for compiling WM for example?

- Compile time options vs. runtime options... I don't know what would be 
required to change that, it would be interesting to hear that from an 
experienced WM developer. Anyway, if the WM developers are interested in doing 
it, it would be perfect, if not, I don't see how we could do it w/o splitting 
the code base.

- Additional stuff like the WM dock and so on should IMHO be disabled by 
default, or one should be able to disable them using runtime/startup options. 
If this is not the case, GS will have problems in providing its enhanced, more 
integrated versions.

- Global menu changes should be a top priority. IMHO WM should not have its own 
global menu. This is not the NEXTSTEP way to do things, instead every app 
should have exactly one menu and only the active app's menu should be visible. 
I don't know how this can be handled in WM. Of course non-GS apps should then 
get a 'default global ' menu or sth like that, perhaps served by the window 
manager or GWorkspace itself?

- The usual icon drawing problem should really be fixed ASAP.

There are many other issues, I believe... the question is, will the WM 
developers help and give us a hand, or isn't it easier to write a clean, small 
and fast window manager that solves those problems w/o affecting WM?

I just don't know (yet), that's why I ask...;-)

cheers, Phil
--
Philippe C.D. Robert | http://www.nice.ch/~phip/