Kill KIO (was: Repositioning the KDE brand)

[Thiago Macieira]

Em Terça-feira 14 Julho 2009, às 16:19:07, Boudewijn Rempt escreveu:
> On Tuesday 14 July 2009, Thiago Macieira wrote:
> > Em Terça-feira 14 Julho 2009, às 11:06:06, Pau Garcia i Quiles escreveu:
> > > Hello,
> > >
> > > > Qt-only programs always makes me wonder what is wrong with the KDE
> > > > libs, as these are supposed to help for better programs.
> > >
> > > One of the main hurdles on Windows is DBus. Then there's the awful lot
> > > of KDE libraries you need to redistribute: most of what you distribute
> > > are KDE libraries and its dependencies, and only a small part is your
> > > actual application.
> >
> > The problem is not the KDE libraries. Using kdecore, kdeui, kpty, kutils,
> > etc. is not a problem.
>
> Well, where they simply add bulk and dependencies while not providing
> something over Qt, it's a problem. And, actually, the size _is_ a problem
> in for some target platforms. Even just the size the library files take up
> on disk or in the installer.

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

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.

>
> > The "problem" is that the KDE libraries expect a KDE runtime environment.
> > They will read from sycoca (which may trigger running of kbuildsycoca4),
> > they will try and talk to kded, kglobalacceld, klauncher. KIO, in
> > special, will ask klauncher to start the ioslaves to do I/O.
>
> Yes, that's a big problem.

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.

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)

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.

> > Qt is a simply a toolkit library, integrating with the platform. KDE, on
> > the other hand, *is* the platform, which means its libraries do
> > "platform-y" stuff, like launching daemons, collecting information about
> > installed plugins, requiring D-Bus. The libraries have their own concept
> > of locale and settings, completely separate from the rest of the system
> > even!
> >
> > The way I see it, there's nothing *wrong* with this picture.
>
> It does mean that a KDE application is not portable to other platforms; if
> you try to do so, you drag the KDE platform with you, and that is
> undesirable. 

Desirable depends on who's asking.

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.

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.

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.

> 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:

> > 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.

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.
-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Senior Product Manager - Nokia, Qt Software
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20090714/9415a5b9/attachment.sig>