Kill KIO (was: Repositioning the KDE brand)

[Boudewijn Rempt]

On Tuesday 14 July 2009, Thiago Macieira wrote:

> If they didn't provide anything, they would be empty. They have something
> there that they do provide.

But can they earn their keep?

> There are classes building upon what Qt does, adding new functionality not
> present in Qt. That's what I meant that it's completely fine.

For my purposes, KPushButton, KComboBox, KApplication, KMessageBox just add 
api and platform L&F integration -- nothing of intrinsic value. And nothing 
users of Krita on another platform expect -- or would be able to discover, 
even. And if the choice is between krita and no krita, not even the network 
transparency of kio or the menu merging of kxmlgui will help.

> The way I see it, there are two types of "platform-y" things:
>
> 1) unnecessary, done only because it was convenient to do so, like locale
> formatting reading configuration files, timezone things communicating with
> daemons, etc.
>
> 2) necessary, because the _real_ platform underneath doesn't provide the
> functionality. This is the case of kglobalacceld, knotify, etc. And if you
> want to go even further, KIO (the original topic of this thread) is also an
> example. If there had been a VFS layer before KIO, we would have most
> likely used it and not rolled out our own.

If the platform doesn't provide those, what use are they? Users don't know 
they will be there, and for things like knotify, would be well out of it. On a 
mac, you have growl, or nothing. And more than growl is not something any mac 
user expects -- so Qt's growl support is sufficient.

> Now, from those two types again, there are things present in other
> environments, like Windows, Mac and maybe Maemo too. (Maemo is a full
> platform like KDE)

Yes, that's one of the platforms I've been playing with. On maemo, since mini-
sd cards are no longer available, I need to fit krita in the internal memory. 
With KDE, that won't work. On OSX, I've never been able to get a setup where I 
could open a file using the file dialog, and even getting there was hell. On 
Windows -- I've been able to install everything using the wonderful KDE 
installer for windows, but that's not something I'd expect ordinary users to 
use. They want a bitrock installer.

Now, personally, I don't want to lose all the nice KDE things, when working on 
and in my chosen platform. Compared to KDE, I feel clumsy everywhere else. But 
they are KDE advantages, so I'd like to abstract them away, and have Krita use 
those facilities only when running on KDE.

> And the reason I wrote "problem" above in quotes is because I don't believe
> this to be bad. It just is the way it is because the real platform
> underneath KDE is so low that we have to build up far too much to get
> things done.

But if it prevents my app from running, it is a problem. And if it gives my 
app behaviour that the users on those platforms report as bugs (like, cannot 
open a file on OSX), it's a problem.

> Desirable depends on who's asking.

Yes, well... I don't like nf2's harping on using gobject and so on. But in 
this case, I am spending work on trying to make krita use KDE when running on 
KDE, but just Qt and other non-KDE dependencies when running elsewhere.

> I believe KDE libs should integrate into the platform as much as they can,
> if they're not running on the KDE Workspace. That would mean using standard
> global shortcut APIs on Mac and Windows instead of launching kglobalacceld,
> for example.

And not using additional memory (on disk and in ram) if they don't deliver 
anything extra that's truly compelling.

> But I also believe that KDE libs should use what technologies they have
> that are better than what the other desktops have. This includes, for
> example, the file dialog: I definitely don't want to see the GTK file
> dialog in my KDE applications if I launch them in GNOME.

I would, actually, love that. It would save so many complaints...

> The point is that KDE libs don't have the same goal as Qt. Qt wants to
> integrate to the platform where it is as much as possible, so that your app
> can look native. KDE libs want to bring the best desktop experience you can
> have and, if that means being different from the platform because we think
> we're doing better, then so be it.

Yes, that's part of the problem: I want KDE to be the best desktop, the best 
platform, but I don't want users of other platforms to get an extra platform 
when they install my application.

> > So, for my applications, I need to find a way to switch out the KDE
> > libraries when porting them to other platforms.
>
> I think we need a "platformless" set of libraries, like you want. That is,
> technically, Qt's goal, so those widgets and other APIs should be either in
> Qt, or in Qt-related projects. See what I had written below:

Yes, indeed. And for the rest it should be easy to switch it off without 
hacking in the source. That's platform, it should be papered over by Qt.

> > > What could be considered wrong is if there's a nice feature that
> > > doesn't depend on anything of the "platform-y" stuff. If that's the
> > > case, then it should be moved upstream through the libraries. (Or the
> > > case of features that do depend on those things, but for silly reasons,
> > > like our locale formatting routines requiring KConfig)
>
> KDE libs, IMHO, should remain focussing on "the best desktop".
>
> And, that said, I also believe KDE applications should be "the best
> applications" and that may mean deviating from the platform where
> necessary. Therefore, I do want Krita to be the best app you can get on Mac
> and Windows. And if that brings in kded, klauncher and the D-Bus daemon, so
> be it.

But... kded, klauncher, dbus and all that jazz doesn't make Krita better on 
Windows, it makes it worse, because it adds bulk, confuses the user and makes 
installation harder.

> PS: Maemo also has the D-Bus daemon, the equivalent of klauncher and many
> daemons too. That only goes to prove what I said about the underlying
> platform being far too primitive.

Which is even worse -- krita needs its own klauncher, so on the very 
constrained maemo platform, we have to run two of everything! Of course, it 
would have been smart to not just switch to Qt, but also to switch to KDE, but 
as long as that hasn't happened...


-- 
Boudewijn Rempt | http://www.valdyas.org