Re: gEDA-user: PCB GTK version...

["Samuel A. Falvo II" <sam.falvo@xxxxxxxxx>]

On 7/26/05, Robert Thorpe <Robert.Thorpe@xxxxxxxxxxxx> wrote:
> > The future is now, and an opengl card is cheap (even in my

That may be, but remember that the more transistors that transition in
a circuit, the more power they draw.  That means more heat.  That
means cooling fans,  That means still more power draw to run the
cooling fans.  Are you aware that my computer has no less than five
fans in it?  That's five fans, sucking up at least 1.2 to 3W of power,
each.  15W is a significant amount of power -- just touch any 15W
incadescent lightbulb if you don't believe me.

If you have a fleet of electrical engineers, in a corporate situation,
that excess power draw can really add up to significant sums.  The
heat load alone has repurcussions(sp?) in that now you need to run the
air conditioning longer to maintain a comfortable temperature for the
engineers (I work in a data center; trust me on this, this IS an
issue).  This will become increasingly important as oil reserves dry
up even beyond their current levels.

That being said, I think the move towards GTK is a wise move, if for
no other reason than mind-share.  I suspect that with all the people
who work on X applications today, there are two widget sets that 90%
of all developers know -- Qt and GTK.  I have zero experience with Xaw
widgets, but I do with GTK.  Tapping into even half of that can be
significantly beneficial.

> The problem is that GTK and Qt are over-complicated and badly designed.

The idea is sound, but the execution is horrifyingly poor.  GTK 2 in
particular is bad because they are attempting to subsume the rule of
CORBA right into GTK itself, in its attempt to be both
written-language and programming-language independent.  The event
distribution model relies heavily on comparing long strings for
equality, instead of hashes or even permanently assigned 32-bit IDs. 
Therefore, event notifications (itself made slow by the fact that an
IP-domain socket is used between the X server and the client
application) are made unnecessarily slow.  Window refreshes are
triggered based on events.  Mouse and keyboard input are based on
events.  Etc.

NeXTStep had it right -- use a truely dynamic language (Objective C)
to implement a truely dynamic user interface, and be done with it.  Of
course, this is now realized in MacOS X.  It's a simple matter of
using the right tool for the right job, and it virtually eliminates
all the problems that GTK has performance-wise.  The Objective-C
runtime has been refined to the point where a worst-case method call
is 2x as slow as a C++ virtual method dispatch, which is a damn fine
performance for a language that rivals Smalltalk in its capabilities.

--
Samuel A. Falvo II