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: Thu, 14 Dec 2000 10:39:10 +0000 (GMT)

>>>>> "Philippe" == Philippe C D Robert <address@hidden> writes:

    Philippe> Richard Frith-Macdonald <address@hidden> wrote
    Philippe> (Sun, 7 Jan 2001 11:49:47 +0000):
    >> > Well, that was exactly my idea when I started this
    >> thread...;-) Since nobody seemed to like > the idea to share
    >> foundations with other projects due to the superiority of GS,
    >> i.e. gtk+, I > thought it would be logic that the window
    >> manager - an important part in the X world - should > be based
    >> on that 'superior' tecyhnology as well, or at least make use of
    >> it - even if this > takes some more time to get to the point...
    >> 
    >> I don't think there is any problem with the notion of sharing
    >> with other projects in principle, it's just not technically
    >> realistic due to basic architectural differences...

    Philippe> So it is not possible to use GDK and Libart instead
    Philippe> of/in xgps, for example?

Ahm - I must say I fail to follow your reasoning.

I find the proposals quite contradicting and confused.

You argued that to be succesful, gnustep must reproduce in full the
nextstep experience.  You even propose to rewrite from scratch the
window manager because in your opinion, being written in C, using its
own little widget set, supporting well gnome/kde/X apps, it's not
suitable for gnustep.

Then, you are now proposing that we rewrite all the gnustep gui stuff
basing it on gtk.  How can you think we can reproduce the nextstep
experience in that way ?  We can't.  Not a bit.  Unless by the
nextstep experience you mean a nextstep/openstep theme for gtk, in
which case you may just simply use gtk with that theme and you are
done.  But then, I don't understand all your integralist threading
about rewriting window maker in objective-C.

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.

 * <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>.

The first one is probably an impulsive reaction to the desire of
having a very good environment.  Following the first one seriously
means the task will never be completed.

The second one is an impulsive reaction to the desire of having it
finished.  Following the second one seriously means the task is
completed immediately, by simply destroying all the work done and
switching to another project.

I think we should try to find a good balance.  Which begins by
answering to the magic question - why do we want gnustep in the first
place ?

And - do we still want gnustep even if we know that it will not be the
predominant environment on gnu/linux in the next years ?

I still do.

And please note - we are not talking about isolating ourselves !  Not
at all.  Precisely because Window Maker supports so well gnome or kde
applications, we can still run any gnome or kde stuff we want.
Precisely because we are trying to make sure our applications can run
in gnome or kde, they can be used by users and people who are actually
run gnome or kde on their desktops.

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.

We want to be open, we need to be open, this is not a competition,
everything is free software.

About the gnustep gui library, the library is perfectly usable, we
only have few developers writing apps using it.  Which is a pity in my
opinion, because the gnustep gui library is very nice.  And it's very
easy to extend and interface it with other libraries or environments.
It doesn't make any sense to drop it at this point, when it works.

If people are using gtk or qt and not moving en masse to gnustep-gui
now that you can use it is not because gtk and qt are better.  It's
because they are used to them.  They know them well, possibly they
like them, and they like to use C and C++ and don't want to learn
objective-c.  They probably are in love with their projects as much as
we are with ours.  Most of them very likely don't care that gnustep
gui is finished or not.  Or if they care, it's because they think we
are competitors to the projects they love, and so they'd prefer
gnustep gui to be never finished.  They already have tools to write
gui apps, and don't want to spend time learning new stuff, and don't
want to leave their beloved projects.

But this doesn't mean we should throw away all our work and gnustep
gui, or attempt at rewriting the gui basing it on gtk.  This would
make most of us unhappy, and reduce the project to something nearly of
no interest.  And it wouldn't attract developers - why learning a new
language - Objective-C - to use a wrapper around your own widget set
if you can already program your widget set directly in your own
language (C or C++).  The project looses any sense then.

We can attract developers - and have a reason to remain ourselves -
only if we offer a different environment.  Yeah - *different* - that's
the reason why gnustep exists.  Not yet another C or C++ widget set.
Something different, something better.  And we have it.  Compare
writing a gnustep makefile with preparing an automake/autoconf
package.  Compare loading a bundle with setting up manually dynamic
library loading to look up symbols etc.  Compare our nice objects with
theirs.  And still, yes, we must be practical and get to the concrete
stuff now - applications.

In a certain sense, we have never been so attractive to developers as
now.  Because our things have never worked as much as now.  But it is
a slow process to get more developers.

The `competition' between different projects is getting `harder'.

GNOME people are constantly looking at KDE progresses with fear.  KDE
people are constantly looking at GNOME progresse with fear.  IMO this
is mostly because there is money in the game now.  

The more we (GNUstep) are able to keep calm and don't get hysterical
because of this competition, and don't disperse energies in mad
projects (rewrite window maker in objective-c, throw away gnustep gui)
but get to the concrete stuff <applications and stuff that can be
delivered>, the more we can be happy.  I guess there are many people
in the GNOME and KDE who are bored by continuous wars and changes of
APIs and chaos and unstable ugly changing complex stuff.  We can
reasonably hope to attract some of them by offering our simple,
well-designed, consistent, stable API and environment, which comes
from a long tradition.  After all, that's precisely how I got here.

And we need to think about cooperations with other projects without
this having to mean that we destroy all work done up to now (by us,
or, in the case of window maker, by them).



reply via email to

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