On Sunday 28 August 2005 22:31, Ingo Klöcker wrote:
> 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.
;) Same for me for Kate, Kate would loose a lot's of it's unique stuff, if we 
would loose the kfiledialog, the ioslaves and all on windows, why at all use 
Kate if not for it's key features? Same for KMail, why drop the filedialog, 
if we need to make it work on windows we need the ioslaves nodaways, as the 
whole sending/receiving is based on them?

>
> 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.
Yes, and we loose our whole integration ;)

>
> 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?
Yes, exactly ;)
And as said, if we really want to provide such an addons to ISV, which would 
allow them to use one interface to the different 
filedialogs/printerdialogs/... whatever, this should be on top of kdelibs and 
outside of it, on top does not mean link to it, just let it use the kdelibs 
stuff via dbus or whatever but please let this stay out of the whole API 
chain a kde app uses and just let it be additional sugar for QT only apps 
wanting some slight integration without being pinned down to link to kde 
stuff.