kpart plugins kdelibs vs. frameworks WAS: Re: dolphin branches

[Harald Sitter]

I literally have no clue how this thread ended up on kde-multimedia so
I am ditching it again from CC Oo

On Tue, Aug 11, 2015 at 3:31 PM, Martin Koller <kollix at aon.at> wrote:
> On Monday 10 August 2015 19:16:46 Emmanuel Pescosta wrote:
>> > So there's no way to get the latest qt4 based version of both
>> > dolphin and the rest of kde-baseapps.
>>
>> The latest released Qt4 based Dolphin is in Applications/15.04,
>> starting with Applications/15.08 Dolphin is now Qt5 based. The
>> same problem would also exist if Dolphin still is in kde-baseapps.
>>
>> How can we fix it? (we need to make Qt4 based Dolphin
>> co-installable, right?)
>
> Do I see this correctly that when I install Applications/15.08 where konqueror is still Qt4
> based, I can no longer use it as filemanager since it can not load the dolphin-plugin to view
> the filesystem ?

Assuming that is the case this actually is a semi-rampant attitude
problem I complained about with konsole but never saw resolved. And I
am not sure the community at large is particularly willing to do
anything about it for kdelibs->frameworks5 at least.

Ranting ramblings ahead, tldr: kparts (and KIO slaves) are shared
libraries and everyone needs to stop pretending they are not.

Moving from kdelibs4 to kde frameworks every single kpart is
essentially not soft-migrating but doing the exact opposite.
Attitude-wise we collectively consider kparts part of the application
that provides them. In of itself that is fine and reasonable, it
becomes a problem when a third party application (that is an
application other than the application providing the kpart) relies on
the presence of the kpart, as we also collectively did because why
not.
For example kdevelop uses the konsole kpart to provide an integrated
terminal (as do many other editor/IDE things based on kde tech) but
with konsole moving to qt5 that kpart suddenly wasn't available
anymore and there was no way to exclusively build the konsole kpart
for qt4 without also building the konsole application. So to keep
kdevelop working you either needed to have every distribution sort
this mess out for themselves or in case of source compile use cases
you had to intentionally overwrite artifacts installed by konsole4
with same named things from konsole5 (e.g. $prefix/bin/konsole).

Now the flaw with this entire notion is that kparts are not part of
the application. They are for all intents and purposes shared
libraries. They may not feature their own API but essentially plug
into a generic-shared-functionality-library-api (i.e. kpart) and since
they are not all equal they are not interchangeable. If you want a
terminal you want a terminal and not a video player. If you want a
terminal but there is none then functionality is lost. This makes
kparts inherently different from your ordinary purpose driven plugin
such as featured in Phonon. Whether you use phonon-vlc or
phonon-gstreamer doesn't matter as far as basic functionality is
concerned. They both provide common baseline functionality of being
able to do multimedia things in line with the Phonon API.
KParts on the other hand are as meta as they come. There is minimal
API to deal with a kpart which is good for most uses, but if you want
to use native API you can do that as well (libkompare does offer that
IIRC).

So what I am getting at is.. if you have a kpart and you port your
application to a newer Qt (or frameworks or whatever ABI incompatible
dep) you must provide a transitional path to build the legacy kpart
without the application parts, and without conflicting with whatever
the new application build installs (and this includes data files,
translations, icons, documentation etc etc). If this is not done you
are forcing a hard migration of all your dependees or a workaround on
distro and/or user level.

This pretty much applies to all kparts ever and also KIO slaves as
they are equally specific-in-purpose plugins. And it is a pretty big
issue. I can only hope we'll do a better job when migrating to
frameworks6 to enable legacy applications to continue using the
runtime plugins they expect to be there rater than retracting them
because the parenting application is being ported.

HS