Redefining kdelibs and kdebase

[Ingo Klöcker]

On Monday 29 August 2005 02:01, Simon Hausmann wrote:
> 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.

Obviously, Kontact makes use of basically all the great technologies KDE 
offers. So I don't really see the benefit in not porting the file 
dialog to Windows. Do we really save that much time in doing so? 
Kontact won't run without DCOP and KIO and I'm pretty sure that porting 
those to Windows is a lot more difficult than porting a "simple" 
dialog.

FWIW, IMO the print dialog is a bit different because the Windows print 
dialog is enhanced by the printer vendors. Thus I can see why it could 
be beneficial to use Windows's print dialog. I fail to see a similar 
benefit with respect to the file dialog (but I have to admit that I 
haven't really used Windows since 98 so I don't really know how the 
file dialog on Windows looks like).

Regards,
Ingo
-------------- 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/20050829/4b78c59e/attachment.sig>