Redefining kdelibs and kdebase

[Simon Hausmann]

On Sunday 28 August 2005 22:31, Ingo Klöcker wrote:
> On Sunday 28 August 2005 21:16, Christoph Cullmann wrote:
> > On Sunday 28 August 2005 21:07, Ingo Klöcker wrote:
> > > Why would you need any of this? If we really want good integration
> > > with the environment then KDE apps would obviously have to use the
> > > ENVIRONMENT's help browser and the ENVIRONMENT's configuration
> > > thingy when run in ENVIRONMENT, where ENVIRONMENT = KDE, GNOME, OS
> > > X, Windows, ...
> >
> > Because this part talked about what we define as the "KDE Desktop
> > Environment", and not, the "KDE Desktop Environment" is a specific
> > set of apps the KDE project provides, no user setting, that kde apps
> > should follow settings we have given by the mime-system is good and
> > already done, but btw., your kmail help won't show up in the gnome
> > help browser ;) Some limits must be given.
>
> My point is that going just the half way is ridiculous. And therefore we
> should not put too much effort in this. FWIW, I want KMail to run on
> Windows in order to help convert Windows users to KDE on Unix/Linux
> users. I don't want KMail to be just another Windows email client. And
> thus I'd prefer KMail to look as much as a KDE application (even when
> running on Windows) as possible.
>
> One point that so far everybody seems to have missed is that using the
> Windows file dialog (and other stuff) will create inconsistency between
> KDE apps running on Windows and KDE apps running on Unix/Linux. This
> inconsistency will obviously make the migration from Windows to
> Unix/Linux harder instead of making it easier because the users will
> have to be trained twice. First they have to be trained to use the KDE
> app with some Windows specific dialogs and later they will have to be
> trained to use the KDE specific dialogs. So instead of making migration
> either we make migration more difficult and more expensive.
>
> So what is the purpose of using the Windows file dialog in KDE apps?
> What is our goal? Do you really think any ISV will write a KDE
> application because it will have the Windows file dialog when running
> in Windows? It's hard to believe that this would be a selling point. If
> an ISV chooses to write a KDE application then he will do so because of
> the great integration with the rest of the KDE desktop (which is _not_
> available on Windows). If he wants to write a Windows app which should
> also run on Unix/Linux then why should he choose KDE over Qt? Where's
> the benefit?

Indeed the ISV has to migrate the application to KDE first before the user can 
do so. I agree that a good benefit for ISVs to migrate to KDE should be the 
integration with the rest of the KDE desktop.

The proposal that Benjamin posted is trying to address exactly that. If we do 
want kdelibs on Windows so that we can run kmail and initiate the migration 
then we have to start somewhere.

It is all about breaking apart dependencies and making things a bit more 
modular. If we do that in an incremental way we can much sooner tell an ISV: 
'Hey, you don't have to wait until all of kdelibs is ported, you can instead 
start using those classes in the 'kdecomponents' directory now.'

The idea of 'kdecomponents' is to provide something similar to 'Qt Solutions': 
Little pieces of software people can just use without having to worry about 
linking against a huge libkdeui that drags in libkdecore, libkdefx, libDCOP 
and libICE.

The sooner such a module fills up the better. It would enable ISVs to start 
using KDE classes much sooner. And that is clearly in everyone's interest.

And once people start using KDE components they might ask: "Hey, those utility 
classes are nice, but how about those classes that define an application 
framework?"

And that is what the idea of 'kdeframework' tries to address, extending the 
toolkit with a true framework. Standard actions, a mainwindow that 
automatically provides an about dialog that has correct author/license 
information, document structure interfaces like kparts, etc. etc.

And the sooner there is a static KFileDialog::getOpenFilename interface that 
works portably, even if it just fires up a native Windows dialog until kio is 
ported, even if it makes the migration to KDE under Unix/Linux so expensive 
then, it's better than telling: "Sorry, you can only use 
KFileDialog::getOpenFileName when compiling for KDE under Unix/Linux and 
otherwise you have to #ifdef for QFileDialog's wrapper". 

Right now using kdelibs basically means all or nothing. And for this proposal 
it all depends on how much of a goal it is for us to change that situation 
(in hope for a wider adoption and use of our code).

Simon