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: Sungjin Chun
Subject: Re: GNUstep Window Manager (was RE: Idea)
Date: Mon, 8 Jan 2001 13:36:29 +0900

Hi,

But if GDK and linart is just a drawing engine like things then,
we need not to sacrifice our NeXTSTEP look and feel, and this
is what Philippe suggests as far as I understand.( for speed and
functionality? )

----- Original Message ----- 
From: "Nicola Pero" <n.pero@mi.flashnet.it>
To: <discuss-gnustep@gnu.org>
Sent: Thursday, December 14, 2000 7:39 PM
Subject: Re: GNUstep Window Manager (was RE: Idea)


> >>>>> "Philippe" == Philippe C D Robert <phr@projectcenter.ch> writes:
> 
>     Philippe> Richard Frith-Macdonald <richard@brainstorm.co.uk> 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).
> 
> _______________________________________________
> Discuss-gnustep mailing list
> Discuss-gnustep@gnu.org
> http://mail.gnu.org/mailman/listinfo/discuss-gnustep
> 
> 




reply via email to

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