From kde-core-devel Mon Aug 29 09:29:39 2005 From: Ingo =?utf-8?q?Kl=C3=B6cker?= Date: Mon, 29 Aug 2005 09:29:39 +0000 To: kde-core-devel Subject: Re: Redefining kdelibs and kdebase Message-Id: <200508291129.46687 () erwin ! ingo-kloecker ! de> X-MARC-Message: https://marc.info/?l=kde-core-devel&m=112530782830474 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--nextPart1700022.S8n7KAaqLH" --nextPart1700022.S8n7KAaqLH Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Monday 29 August 2005 02:01, Simon Hausmann wrote: > On Sunday 28 August 2005 22:31, Ingo Kl=C3=B6cker wrote: > > On Sunday 28 August 2005 21:16, Christoph Cullmann wrote: > > > On Sunday 28 August 2005 21:07, Ingo Kl=C3=B6cker 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 =3D 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=20 offers. So I don't really see the benefit in not porting the file=20 dialog to Windows. Do we really save that much time in doing so?=20 Kontact won't run without DCOP and KIO and I'm pretty sure that porting=20 those to Windows is a lot more difficult than porting a "simple"=20 dialog. =46WIW, IMO the print dialog is a bit different because the Windows print=20 dialog is enhanced by the printer vendors. Thus I can see why it could=20 be beneficial to use Windows's print dialog. I fail to see a similar=20 benefit with respect to the file dialog (but I have to admit that I=20 haven't really used Windows since 98 so I don't really know how the=20 file dialog on Windows looks like). Regards, Ingo --nextPart1700022.S8n7KAaqLH Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQBDEtWKGnR+RTDgudgRAtmpAJ4pek5P+x8O2ijDsFua+dTjt43OywCgxbkF oEOq+siIVZ+IuNeY2mhRzYs= =9nC2 -----END PGP SIGNATURE----- --nextPart1700022.S8n7KAaqLH--