discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GNUstep Window Manager (was RE: Idea)


From: Nicola Pero
Subject: Re: GNUstep Window Manager (was RE: Idea)
Date: Sun, 7 Jan 2001 04:48:39 +0100 (CET)

> > After years on work concentrated on the framework, we really need to stop
> > (for a while only :-) dreaming about rewriting all the system in
> > Objective-C :-) and face the task of using our marvellous libraries to
> > write end-user products running now on what is available now. 
> 
> IMHO it is not about having a 100% pure ObjC window manager, 
> it is about having a '100% GNUstep aware' window manager!

Then, I think Window Maker is an excellent choice.  AFAIK the window maker
people have always been very open to support gnustep.  I also tend to
sympathize with them on this subject because if we don't have clear what
kind of cooperation for our workspace manager we want from the window
manager in the first place, how could they implement it ? 

So, we first need to decide exactly what we need :-) we might have then to
implement part if not most of the interaction code ourselves but it's
still nothing in comparison with the effort of writing a full window
manager from scratch.

--

on the subject of window manager interaction

I also think that the support for gnustep interaction will in general
improve in all window managers when there are more gnustep applications on
the market to interact with :-)

Because, this simple problem - having a simple gnustep application run
correctly under gnome or kde or a window manager - with icons in a
reasonable place etc - is still partially open and is quite a first rate
problem IMHO. 

Just to make sure everyone knows the terms of the problem - we already
have code in core/xgps/Source/SharedX/XGContextWindow.m which can
correctly detect window maker as opposed to a generic window manager, and
modify the behaviour of a gnustep application to fit into the context. The
idea is that some nextish features (high control of miniwindows etc) are
available under window maker but are disabled and replaced by a standard
and simple mechanism (more similar to the behaviuor of a traditional X
app) under other window managers where these features can't be fit in the
context.  The idea is the result of long discussions, and a detailed paper
describing what's needed to make it work well with window maker was
prepared.  But the X behaviours of our apps and the interaction both with
window maker and with a generic window manager is still to be refined to
be completely satisfactory.  It works much better than it used to, but it
still needs some work.  I'm not sure - I don't remember - how much of the
paper has been fully implemented - but I'm quite sure under gnome or kde
it's not yet as good as it could be (but this part was not covered by the
paper I think).  This problem is difficult because it also requires to
decide how a gnustep app should behave say, in a gnome desktop - and still
making sure it reasonably conforms to the API and that can behave 100%
nextish way when under window maker; and the nextish behaviour usually
conflicts with the expected X behaviour.  Just to make things worst, we
are not X experts. :-)

In general my hope is also that if more gnustep apps are available, we
might get more suggestions, bug reports, code submitted to improve
interaction of our own libraries with window managers and X in general.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]