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 <[email protected]> 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 _______________________________________________ release-team mailing list [email protected] https://mail.kde.org/mailman/listinfo/release-team
