Re: GNUstep Window Manager (was RE: Idea)

[Richard Frith-Macdonald]

On Monday, January 8, 2001, at 02:25 AM, Philippe C.D.Robert wrote:

> OK, so I write it again...*sigh* 
>  
> A) I said we should have a GNUstep Window Manager which offers better 
> integration than 
> WindowMaker does today. I stated several times that this can probably be done 
> *either* by 
> adding code to an existing solution *or* to write another window manager 
> *based on an 
> existing solution* (eg blackbox, WindowMaker or whatever else). I never cared 
> about WiNG 
> or whatever, I am talking about *integration* here, that is the use of DO 
> perhaps, ObjC 
> interfaces to important 'classes' and so forth. I also think that stuff like 
> the dock and 
> clip are not needed in a window manager being 'part of the GNUstep project', 
> as is 
> WindowMaker (but I never told anyone: please remove those from the 
> codebase!!!). Such a 
> tight integration could help to reproduce the NEXTSTEP experience we all like 
> that much, I 
> think. 
>   
> B) I further said that GNUstep should reproduce the full NEXTSTEP experience 
> (that is 
> mainly the feel), this is one of the major goals of the project (the look is 
> IMHO less 
> important for now, you get used to rounded buttones, you know...). Since we 
> do not have the 
> support of hundreds of volunteers, I suggested to share some foundations with 
> other 
> projects *if it makes sense* (such as of GNOME or gtk+). Since we lack 
> experienced X 
> developers and since DGS is just 'whisful thinking', it could be wise to 
> adopt existing, 
> stable technologies in that area which could help us complete the GNUstep 
> experience. 
> Therefore I suggested to have a look into GDK, libart and such which could be 
> used to write 
> sth which serves the needs of a NEXTSTEP like experience better than xgps or 
> xdps/DGS. I 
> apologise for typing 'gtk' sometimes when I mean 'a subset of gtk+, mainly 
> glib and gdk'. 

Thanks for the restatement ... it's what I thought you meant anyway, but it's 
probably
impossible to overestimate the room for misunderstanding in emails.

I'll try to reciprocate in kind ...

A) I believe that Window Maker is the best option for tighter integration, 
because
it is decent code already, and its maintainers are willing to advise etc.   But
someone needs to do the work, and specification of the integration is 
non-trivial.
I don't have time (or X skills) to do this (though I did do some of it a year or
so back).

B) I don't believe it's technically realistic to adopt other technologies 
except in
relatively small, well defined areas.  I see no possibility of this for
gstep-gui, but alternative/enhanced backends are quite possible (again, if
someone would do the work).  It might also be possible to operate some other
toolkit widgets inside a GNUstep window or (less likely) a view, but I don't see
that as really contributing to the gui development overall.


> > In general, as tradition in this mailing list, I see two main extreme 
> > (and contradicting) positions repeating themselves in your posts:  
> >  
> >  * <integralist> gnustep should clone nextstep totally.  Whatever is 
> >    slightly different from the holy nextstep 3.3 interface or 
> >    environment is shit.  No compromises, never: rewrite the entire  
> >    system from scratch in Objective-C and Postscript. 
>  
> Sorry, I never stated anything to be shit, holy or whatever nor did I suggest 
> to write 
> everything from scratch, be it ObjC or whatever language. Have a closer look 
> before 
> writing such sentences, please. 

He's presenting an extreme/simplified view of the general impression - I don't 
think
intended  to be taken literally.

> >  * <destructivist> gnustep is basically useless.  Since most people in 
> >    the real world are using gtk or qt, we should as well turn gnustep  
> >    into an objective-c wrapper for gtk <or qt>. 
>  
> GNUstep *is* basically useless as of today if you want to write good, fast, 
> stable UI based 
> solutions! 

I guess that depends on what you are trying to do - I think it's plenty good 
enough for
many small applications, and better than (say) gnome was two years ago.  The 
gui libraries
need developers working on them - if we don't get them then progress will 
continue to be
fairly slow.
   
> > And precisely because Objective-C is such a nice and flexible language 
> > and gnustep such a nice environment, we can play to interface them 
> > with whatever is on the market.  I worked on a java interface, and 
> > played with writing apache modules in objective-c using the gnustep 
> > base library.  In both cases, I found Objective-C and gnustep enough 
> > flexible and well designed to allow us to interface with alien stuff 
> > quite well. 
>  
> See, this is only 'non-UI' stuff. But there are persons out there who like 
> *STEP because of 
> the interface part, the part of GNUstep that is sadly not as mature and 
> usable as 
> gnustep-base. The design and elegance itself is worthless if the 
> implementation is not 
> yet ready! So my question is and always was: how can we improve the quality 
> of the 
> gnustep-gui code. Like Helge already mentioned, the remaining 10% will take 
> 90% of the 
> time to get to the point, this I think we should really think carefully about 
> future steps! 

Not really from a technical point of view though - all we need are developers,
not technologies.  If we get developers they will bring with them whatever
technologies they find best, but attempting to use alternative technologies to
attract developers just won't work.

> The gnustep gui library is simply not perfectly usable. If you don't believe 
> me, try to 
> write a good text editor...

Actually, that's about as hard as in most gui toolkits - all you need to do is 
*not*
use the NSText related classes - in which case you are not much worse off than 
with the
limited functionality other toolkits give you :-)

The right way to view it is that when NSText etc is fully working, things will 
be much
easier in GNUstgep than in other kits.

> Besides, the integration with X is also just not as good as it 
> should be - I know you know the nasty focus problem for example. 

Which one?