Re: GNUstep Window Manager (was RE: Idea)

[Sungjin Chun]

Hi,

I do think that the real problem except NSText things are
gnustep-xdps/xgps, not gnustep-gui. Incorrect?

----- Original Message -----
From: "Richard Frith-Macdonald" <richard@brainstorm.co.uk>
To: "Philippe C.D.Robert" <phr@projectcenter.ch>
Cc: <discuss-gnustep@gnu.org>; <n.pero@mi.flashnet.it>
Sent: Monday, January 08, 2001 2:54 PM
Subject: Re: GNUstep Window Manager (was RE: Idea)


>
> 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?
>
> _______________________________________________
> Discuss-gnustep mailing list
> Discuss-gnustep@gnu.org
> http://mail.gnu.org/mailman/listinfo/discuss-gnustep
>
>