[CLAM] Re: CLAM digest, Vol 1 #63 - 8 msgs

[Miguel Ram__rez J__vega]

Two cents about what's going on behind the scenes...

> > Is it just me, but Qt usually equals problems sooner or later.
> > Making upgrading hard and compiling more difficult than it should
> > actually be?
> 
> There is also the wxWindows choice: it exists for Linux, Windows, MacOSX
> and other platforms, is quite mature, has a nice license (can be used
> both for proprietary AND open source / GPL'd projects) and it has a
> large users base. Apart from the GUI aspect, it also has other very
> useful cross-platform things like threading, networking, some DB
> connectivity, ... It does have a larger "footprint" than FLTK I think.
> If you did not yet take a decision about which toolkit to use, you might
> want to check it out (but you probably already did :-) ):
> http://www.wxwindows.org
> 

Note the following facts:
+ CLAM tries to be a cross-platform toolkit. This discards toolkits such as MFC or Carbon, independently of how good they are.
+ CLAM tries to be an OO framework. And prefers to achieve this through the possibilites offered by ANSI C++. So GTK for instance does not qualify at all, for quite obvious reasons. One might remind us of the existence of GTKmm. However, I don't feel GTKmm to be mature enough - this is, with an stable interface. This favours toolkits like wxWindows ( and to some extent ) FLTK. Qt is as OO as wxWindows, but it makes use of non ANSI C++ mechanisms to implement their object model.
+ CLAM tries to be *pure* free software. This has nasty implications for Qt, in some platforms.
+ CLAM graphics should be fast. This discards that just wrap other toolkits, since this is inherently inefficient. This favours toolkits like Qt and FLTK, that *emulate* GUI services from the lowest available OS graphics API  up.
+ CLAM tries to minimize the number of macros and other weirdly implemented idioms. DynamicTypes are enough ;) This is a minus for toolkits like Qt or FOX ( or GTK ).
+ If CLAM has to choose a certain  toolkit, it should choose a feature-rich toolkit, whose look and feel matches the most popular look & feel standard available for the target platform. We usually program applications that will be used by normal people. I don't wish to start any flame war about look & feel standards: Aqua vs. XP vs. KDE vs. GTK vs. Motif vs. ... and so up to infinity. A discussion on this topic is pointless: usually is "economical" success the primary criterion for deciding imposition of some standard. Quality comes in second place, and sometimes with time.

I have been looking for the perfect toolkit for three years. After intensive brain pounding I just see two ways of actions:
1) Try our hand at developing the *perfect* toolkit.
2) Design CLAM in a way that application developers can choose the GUI toolkit that suit best their app requirements. This should make sure that, for instance, if someone wants to use MFCs, if he wants or need to, it is possible.

As you can imagine I have chosen the second approach. Maybe other clam-devel members think otherwise...

Miguel.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.clam-project.org/pipermail/clam-users-clam-project.org/attachments/20040205/dd19afcc/attachment-0002.pgp>