[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GNUstep & The Window Manager Problem
From: |
Marciano Siniscalchi |
Subject: |
Re: GNUstep & The Window Manager Problem |
Date: |
Tue, 25 May 2004 10:51:23 -0500 |
User-agent: |
KMail/1.6.2 |
On Monday 24 May 2004 16:55, Alex Perez wrote:
> Maybe the issue is that we just need to grow our developer community.
> Would anyone be interested in developing a plan of action for recruitment
> of disaffected GNOME/KDE/other developers who are unhappy with the current
> discussions within the GNOME community about which direction to take GNOME
> in, and then acting on that plan while those who are disaffected are "ripe
> for the picking," so to speak? I would be very interested in helping out
> in this areana.
I think this would be an excellent move for both the GNUstep and the GNOME
communities. My personal view of the situation is as follows:
* GNOME has a lot of mindshare, as well as traction in the commercial world.
GNUstep has much less visibility (except by association with OSX/Cocoa).
* GNOME folks interact a lot with, and often lead, efforts devoted to
developing "platform" technologies such as Gstreamer, Fontconfig,
"next-generation" X extensions, etc.
* There are some similarities / commonalities between the GTK+/GNOME libraries
and the GNUstep libraries. For instance, GObject has a few things in common
with NSObject (including, for example, refcounting); The GNOME Canvas is
based on libart.
* GNOME/GTK+ lacks a modern development environment, a la GORM/Project Center,
and at at least some members of that community are looking at alternative
language bindings (there are partial ObjC bindings for GTK, btw). They are
looking at .NET / Mono, but there are also up-to-date Java bindings; a lot of
people are wary of depending upon a Microsoft or otherwise proprietary
technology. [In this respect, OpenStep may also be perceived as a somewhat
not-entirely-free-and-open technology]
For these reasons, some form of combination of the GNUstep and GNOME
technologies could be beneficial (and, BTW, yes, I am aware of the relevant
entry in the FAQ...). This could happen in many ways.
At the lowest level, the possibility of using the GTK widget drawing APIs in
-gui (or -back, or some combination thereof) could be investigated. That is:
keep the GS run loop, event handling, object model, etc., and call GTK or
GNOME libs as required to draw menus, buttons, the file selector, color
wheel, etc. Also, the Pango text rendering library could probably be used to
improve upon current text handling in GNUstep; one advantage is that, this
way, changing font settings in the Gnome Font Properties applet affects
rendering in traditional Gnome *and* GNUstep apps.
This could probably be done incrementally, which is an advantage IMHO. THe end
result would be GNUstep libraries that look good in a GNOME environment.
Another advantage is the fact that GTK+ *is* ported and working on the
Windows platform (natively, not under Cygwin/XFree), and can be made to use
the default Windows themeing engine. THis means that GNUstep apps could also
look good in a Windows environment.
If this can be done without exposing the GTK/GNOME apis, one side result is
that GNOME gains a modern development environment *and* language for free (as
well as other nice apps, e.g. GWorkspace, although I guess GNOME people will
prefer to stick with Nautilus). On the other hand, GNUstep (and Cocoa!)
developers would significantly expand their target audience and visibility.
OK, sorry for the lengthy email, which probably is a rehash of discussions
that have already occurred several times. But, as the original poster
mentioned, the current discussions within the GNOME community might indicate
that times are ripe for a GNOME/GNUstep (GNOMEstep???) collaboration...
If any or all of the above is crazy, feel free to say so!
M
--
Marciano Siniscalchi
Department of Economics
Northwestern University