Re: wxWindows and GNOME

[Karl Nelson <kenelson ece ucdavis edu>]

> 
> On Fri, 27 Aug 1999, Karl Nelson wrote:
> 
> > The other approach is to use the tools that are there and 
> > subsititute for them if they are missing.
> 
> You misunderstood me: I removed libtool and autoconf, because 
> they don´t work (libtool cannot create C++ libraries unless
> you rewrite parts of it, automake cannot do "make dist" if
> the source is in different directories (compiled using VPATH).

Then improve libtool and automake.  It seems that people
will evaluate an open source tool and discover that it is
missing some feature thus thus they go about trying to reinvent
the tool.  If STL is not portable enough or is too big improve
it!  Gtk-- has had little problem building C++ libraries with
libtool, and the same goes for KDE.  Further, the use of cvs
and automake to make a module for each varation in which make
dist works properly is an easy chore.

> > I wrote libsigc++ to work accross almost as many platforms 
> > as WxWindows,
> 
> I´m not sure what libsigc++ is, but I guess it is a library
> for adding to C++ the obvious missing thing, a standard way
> to propagate events. Well "almost as many" may not be what
> we want any I can imagine that wxWindows might be be a little
> bigger so that an approach that works for your library might
> not be the right thing for the likes of wxWindows.

(Yes, libsigc++ is a callback propagation library with
typesafe templates.)

I do realize that my approach is still ad hoc, but abandoning
tools that will improve over time for some short term gain 
does not seem worth it to me.  Feature requests, patchs and
improvement are what drive open source projects.  Your approach
of abandoning rather that expanding seems to me to run counter
to expanding open source and more toward fragmentation.  
(I have had this debate with way too many other C++ gtk+ wrappers.)

(By the way when we have time KDE and Gtk-- are planning
to contribute a large number of C++ autoconf macros back to
autoconf project.)

> > WxGtk no more deserves to be in GNOME release than Gtk-- or VDK .
> 
> Never did I say so or remotely thought that.
> 
> > so if we include it we might as well include Qt and it is as 
> > closely related.
> 
> Read this sentence again and ask yourself: "Was this really my
> honest belief?" Isn´t maybe the GTK toolkit a distinguishing
> feature of the GNOME environment? 

Well, if you hook in a gtk+-like theme and write a gnome-like app 
with Qt then it would fit your description of what wxGtk is 
used for.  You don't want to share the backend managment of
anything but gtk+ and you use that basically for just rendering.
(If I understand your API correctly.)  Thus I am quite serious
why not include Qt as the C++ widget set for GNOME?  Because
it doesn't use any of the GNOME libraries.  
 
> > wxWindows´s goals do not seem to match those of GNOME
> 
> A 100% pure GNOME world? GNOME-- will be good for that,
> wxWindows for the remaining 95% of reality.

Why should GNOME include you at all then?  You seem to
be indicating that GNOME should just be replaced by WxWindows.

> > I personally think unless a large number of GNOME applications
> > (not gnome-like) start using one of the bindings, should
> > that binding be included.
> 
> Er - I didn´t understand this one.

Including excess libraries is just a lot of clutter.  If 
some major GNOME project becomes dependent on one of the bindings
then perhaps one should be included.  It would be great
if they did get included, but I doubt that the GNOME people
will include any.

--Karl