[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Redefining kdelibs and kdebase
From:       Ingo =?utf-8?q?Kl=C3=B6cker?= <kloecker () kde ! org>
Date:       2005-08-28 20:31:19
Message-ID: 200508282231.47611 () erwin ! ingo-kloecker ! de
[Download RAW message or body]


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

[Attachment #3 (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]