Qt4addons module?

Matthias Welwarsky matze at stud.fbi.fh-darmstadt.de
Mon May 30 13:59:19 BST 2005


On Monday 30 May 2005 14:22, David Faure wrote:
> On Monday 30 May 2005 14:12, Eva Brucherseifer wrote:
> > There are 2 arguments:
> > - There are people out there, esp companies but not only, who won't drop
> > the Windows platform.
>
> This is a valid argument for Qt3/kde3, but not for Qt4/kde4. Why are you
> applying a kde3 argument to kde4? This makes no sense. Using kdelibs4 will
> NOT mean dropping the Windows platform.

Think a little bit further, please. What services of the KDE platform can you 
use without transforming your QApplication into a KApplication? Can you think 
of ways to use KDE platform services (e.g. printing, ioslaves, wallet) 
without having to link against kdelibs at compile-time? How would you make an 
application use the corresponding windows service if it does not find the 
installed KDE service?

Following your path, it is still an "all or nothing" approach, because the 
application will just stop to work as it has a hard dependency to kdelibs.

The question is: how do you make the KDE platform useful for Windows programms 
with the least possible effort, and how do you make KDE applications run on 
Windows with the minimum set of additional packages to be installed.

Example: How would kmail on Windows use kwallet? Can this be resolved at 
run-time or do you have to decide while compiling kmail, creating a hard 
dependency to kwallet. Would kwallet have an icon in the Windows systray or 
do you have to run kicker? What about Kgpg or any other utility living in the 
KDE systray? Is there a generic approach to this kind of problems?

regards,
	matthias

-- 
From the 'Handbook of Corporate Slang':

- to protect prior investment (phrase):
    describes the inability to revert a wrong decision made
    in the past, expresses willingness of throwing 
    good money after bad. (q.v. Fiorina, C.)




More information about the kde-core-devel mailing list