Re: [gtk-list] RE: GTK++ proposal

[Bill Huey <billh mag ucsd edu>]

> I generally disagree with moving to C++. I for one would no longer
> contribute to GTK+ if it moved to C++. I see no good reasons in your
> 'argument' for doing so.

A strong counter example is how high quality the BeOS GUI kit is
with each window being encapsulated in a single thread and easily
modifyable by simply deriving the Parent class of a window view. 

There are poor ones in OO languages and there are good ones, which I
believe the BeOS is a very powerful and easy to use GUI kit.

In fact, the structure of it is *much* more powerful than what
I've seen in typical X and Win32 based kits for general media
handling and potentially document/print handling.

> IMO, C++ is just an attempt to jump on the OO bandwagon and is an
> ugly and bloatish misconception. I am by no means a C++ expert, but I
> have written a 20,000 line software project using it.

Yeah, but different implementations of OO designs *vary* greatly like
most projects using a software engineering framework of *any* sort.

> I always look at the aborted attempt to use C++ in the Linux kernel
> as a good example of why not to use C++. It's less efficient and the
> compilers are horrendously bug ridden ( and the gcc people have
> traditionally been very bad at fixing them ).

The flakiness of a compiler technology isn't really a good reason to
discount an *entire* design methodology. Kernels themselves don't fit
well in an OO framework and in most case that I've seen wouldn't benifit
from the use of a full OO framework mainly because of how non-reuseable most
of the code for various subsections are within the kernel.

Filesystems might be a possible exception, but the process of coding a
filesystem is not really something that OO can dramatically help in
anyway because they aren't traditional problems that OO was designed
to help facilitate. They are more like general data structure problems
and C is as good as any of them for this purpose.

Just give those folks malloc() and a pointer amoungst other things.

> This simply doesn't follow. The *vast* majority of users of the
> toolkit are not interested in creating new widgets. I don't know, but
> how many of the current developers would we lose through changing to
> C++?
> 
> IMO, GTK+ is a very well designed OO system as it stands.

Compare to what ?

This is the key question that I'm getting at.

Well designed compare to the BeOS ? OpenStep ?

> I have never met anyone who thinks that C++ is the 'future'. More
> like a step backwards. OO should be more a way of thinking
> about/designing software than in actually coding it. 

What about stuff like Java in particular with the Swing kit ?

Java's RMI ? (assuming that it doesn't run over a very slow protocol
like HTTP)

What about OpenStep and their use of Objective-C and their PostScript
architecture?

My feeling is that if you're going to design GUI kit then you should
steal from the very best such as Apple's QuickDraw GX or Display Postscript
for various kinds of high quality document handling and color management.

The BeOS is good for things that media stream driven, because of the
independent manner in which windows have their own seperate kernel thread
amoungst other things.

I see no real reason that something like GTK or QT can't reach that level
of sheer power.

The X community, as general rule, doesn't steal many great ideas from other
kits and it suffers greatly because of it.

I talked to one project manager of Applix when I went to MacWorld and I
verified many of the possible problems in building a compound document
architecture that I believe might be overlooked by the GTK folks, but I
might be premature in that development in GTK is still progress.

My background is in OO kits like OpenStep, BeOS and Java.

My first professional gig was compound documents, so I know a thing or
two about how to deal with such things.

I see no reason that GTK folk can't steal all the best ideas from some
of the very best kits around.

Think about it.

> -tony
> E-Mail: trog@gtk.org

bill