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