Qt-Addon classes merge

[Thiago Macieira]

Hello everyone,

[if you don't know what Qt-Addon is about, please take a look at the end 
of the e-mail]

Recently, TrollTech decided that they don't have the resources to 
integrate my code into Qt4, nor really the need. The current bugs and 
shortcomings in Qt3 will be resolved by enhancing the current classes 
and replacing the few where this can't be done -- with code far simpler 
than mine.

Therefore, we are left with libqt-addon and must decide what to do with 
it. Three possibilities come to mind:

1) keep it as is: a separate Qt-only library.
- Advantages: makes it possible for non-KDE (non-libkdecore) programs to 
benefit from the enhancements (DCOP comes to mind). It also makes it 
possible for TT to reconsider.
- Disadvantages: separate library which may cause overhead during load. 
It also makes my life slightly difficult in integrating with KSocks -- 
which is a requirement for KDE 3.3.

2) rename all classes and files and merge with libkdecore
- Advantages: code will benefit from KDE features, like KDebug, 
KLibLoader, etc. KSocks integration will be much easier.
- Disadvantages: some work required in the moving, renaming and porting 
the classes. Qt-only programs won't be able to benefit from the 
enhancements. (read: we won't be able to make DCOP use this)

3) drop it.
- Advantages: no work for anyone
- Disadvantages: we'll have to live with the current bugs until 
Qt4/KDE4.

Frankly, I don't really see option #3 as a real option. If only because 
I've been more than once asked to provide a proxying API.

Personally, I lean towards option #2, but I'd like to hear some input 
from other people, notably the potential users of this code.

===
What was Qt-Addon supposed to be?

When last year I decided to work on the replacement for my own 
KExtendedSocket class and fix the dependency on QDns, I included in my 
proposition the idea that TrollTech could use the code for Qt itself.

Then I really did get in touch with TT and we started working more or 
less together in defining the roadmap and API. At that time, the 
classes (that still were KDE classes) were renamed to Q-something and 
placed in a separate library: libqt-addon.

The library exists now and is being used by KDE HEAD. It implements 
truly asynchronous name-lookup -- not restricting to DNS alone -- and 
the socket classes are really flexible. I've even implemented the 
long-needed support for HTTP proxying.
-- 
  Thiago Macieira  -  Registered Linux user #65028
   thiago (AT) macieira (DOT) info
    ICQ UIN: 1967141   PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20040418/343a9ef5/attachment.sig>