Re: GNUstep & The Window Manager Problem

[Marciano Siniscalchi]

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