From kde-core-devel Sun Aug 28 20:31:19 2005 From: Ingo =?utf-8?q?Kl=C3=B6cker?= Date: Sun, 28 Aug 2005 20:31:19 +0000 To: kde-core-devel Subject: Re: Redefining kdelibs and kdebase Message-Id: <200508282231.47611 () erwin ! ingo-kloecker ! de> X-MARC-Message: https://marc.info/?l=kde-core-devel&m=112526116415434 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--nextPart1193285.fki8gpeShm" --nextPart1193285.fki8gpeShm Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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=20 should not put too much effort in this. FWIW, I want KMail to run on=20 Windows in order to help convert Windows users to KDE on Unix/Linux=20 users. I don't want KMail to be just another Windows email client. And=20 thus I'd prefer KMail to look as much as a KDE application (even when=20 running on Windows) as possible. One point that so far everybody seems to have missed is that using the=20 Windows file dialog (and other stuff) will create inconsistency between=20 KDE apps running on Windows and KDE apps running on Unix/Linux. This=20 inconsistency will obviously make the migration from Windows to=20 Unix/Linux harder instead of making it easier because the users will=20 have to be trained twice. First they have to be trained to use the KDE=20 app with some Windows specific dialogs and later they will have to be=20 trained to use the KDE specific dialogs. So instead of making migration=20 either we make migration more difficult and more expensive. So what is the purpose of using the Windows file dialog in KDE apps?=20 What is our goal? Do you really think any ISV will write a KDE=20 application because it will have the Windows file dialog when running=20 in Windows? It's hard to believe that this would be a selling point. If=20 an ISV chooses to write a KDE application then he will do so because of=20 the great integration with the rest of the KDE desktop (which is _not_=20 available on Windows). If he wants to write a Windows app which should=20 also run on Unix/Linux then why should he choose KDE over Qt? Where's=20 the benefit? Just my 2=C2=A2 Ingo --nextPart1193285.fki8gpeShm Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQBDEh8zGnR+RTDgudgRApVFAKDO/FN6E4OL3BmiJdrEs/e8aCkmzgCePjDY vBpXuifSE2timRJI4hOVEwQ= =tMkH -----END PGP SIGNATURE----- --nextPart1193285.fki8gpeShm--