Re: Tempting change..

Thanks for bringing this thread up again, Henry. I was planning on
commenting but then screenfuls of other messages invaded my inbox..


On Fri, Jul 29, 2005 at 02:44:26PM +0200, Andreas Aardal Hanssen wrote:
> On Mon, 25 Jul 2005, Peter Stuge wrote:
> >> Qt is really really nice though :)
> >..probably, but it's so big.
> 
> Actually, QtCore is ~1.4MB. I think there are several other
> libraries out there that are significantly larger.

That's not bad at all.


> >I think it's (almost) OK for KDE to depend on Qt but I don't like
> >"Qt" and "server" in the same sentence. Oh, guess I just wrote
> >that already.. :)
> 
> That's different with Qt 4. Qt 4 is a collection of libraries now,
> and the only library that would be in use would be QtCore.

Ok. This is what matters and as long as QtCore can be distributed/
built/installed separately from anything else Qt I think reusing it
sounds good, with one small reservation..


> Qt 4 is a complete c++ dev framework; not a huge GUI library.

Right, like glib != gtk.


> >* ease of use (compile time, installation requirements)
> >* size (lines of code, security obviously)
> >* memory usage and speed (C++ is resource hungry, one bincimapd and Qt
> >  per logged-in user => gigabytes worth of RAM.. (Yeahyeah, shared
> >  objects..))
> 
> This I don't understand. I'm quite certain that using Qt would
> reduce the number of lines in Binc IMAP; especially because of the
> hassle of running around with pointers and const references. For
> instance, all Qt containers are implicitly shared and do
> copy-on-write. They also use less memory than the STL ones, and are
> faster than STL ones (despite that there is no memory pooling, which
> btw means that today's on-average 3-4MB binc processes would drop to
> a pleasant 1-1.5, which is what is actually in use).

..namely that Qt(Core) still is many many lines of code, and that I
want as few lines of code as possible dealing with uncontrolled data
from the network.


> >Agreed, most users may not self-compile, but please don't add this
> >dependency to the few of us that do.
> 
> Qt compiles on more platforms than Binc does, so I don't think this
> would be a big issue.

The issue is human and machine workload required to make a build. One
more dependency means more work.


> >Size, as I said, unless Qt4 is split up in lots of bits and pieces
> >adding Qt to bincimap(-up) exposes it to unauthenticated users on
> >the network.
> 
> http://doc.trolltech.com/4.0/qt4-intro.html#build-system

Aye. Looked around a bit and it looks nice, but the fact that the
different libraries aren't available separately kills the idea for
me. Plus, it doesn't even look like it's possible to only configure
and build single parts of Qt 4, the way I understand configure --help
is that all of Qt 4 has to be built to get QtCore.


> >Which exact features in Qt are you longing for, Andreas? I guess
> >it's more than Unicode? Perhaps more light-weight alternatives can
> >be found?
> 
> Qt is light-weight already. There's absolutely nothing bloated about
> it. And seriously, if you can find another free toolkit out there
> that can do text codecs, implicitly shared fully-featured
> containers, process/thread handling, plugins and
> internationalization... :-)

Very good point - I doubt I can. But I would rather live without any
features gained from Qt 4 dependency than have the dependency. IMHO
Qt is too uncommon to use in a smaller project. I will admit to being
puritan and conservative. :p But times will change of course.


//Peter