Redefining kdelibs and kdebase
Ingo Klöcker
kloecker at kde.org
Sun Aug 28 21:31:19 BST 2005
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?
Just my 2¢
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/20050828/a4241116/attachment.sig>
More information about the kde-core-devel
mailing list