RFC: split platformtheme plugin from frameworkintegration and move to kde/workspace

Jerome Leclanche jerome at leclan.ch
Sat Dec 12 12:42:23 UTC 2015


Most of our users currently prefer the basic Qt file dialog, but if
there's some way to get the KDE one outside of plasma, I'm sure many
would rejoice.

On 12 December 2015 at 13:31, David Faure <faure at kde.org> wrote:
> On Thursday 10 December 2015 10:38:06 Weng Xuetian wrote:
>>  if you want to achieve the same feature in some
>> other desktop, it would be better to make a fork of
>> frameworkintegration.
>
> Not frameworkintegration, just the platformtheme (QPT).
>
> Like some others before, you're confusing frameworkintegration
> (the framework, which contains 3 different things) and
> the platformtheme plugin (which is one of these things).
>
> There is 0 point in anyone forking the other things like
> integrationplugin, which is about KMessageBox being able
> to use KConfig when both are installed.
>
> ---
>
> Back to the topic: the platformtheme plugin is indeed about "KF5 based apps
> integrating better with the plasma desktop, visually". I.e. getting
> a KFileDialog in Plasma. The thing is, this could be generalized to
> "getting a KFileDialog in plasma or any other workspace based on Qt+KF5"
>
> But I don't even know if e.g. LXQt wants to see the KDE File Dialog or the Qt File Dialog.
> -> CC'ing Jerome Leclanche for input.
>
> However, as Martin says, the *current* code is only loaded in a plasma
> session anyway (Qt looks for e.g. $XDG_CURRENT_DESKTOP=KDE)
> so this move won't, in itself, change anything for LXQt users.
>
> Therefore I'm OK with it moving. (*)
>
> I would just like to define the best architecture longer term. If KFileDialog is
> wanted outside of plasma, then indeed some code should move back to KF5
> (e.g. in KIO) and be shared between the platformthemes. But not the code
> that derives from QPA classes since they are not fully public, gah....
>
> (*)
> The packagers are going to hate this though, there will be a conflict between
> KF 5.16 and Plasma X.Y (the next release), which will only be resolved once
> KF 5.17 is out. Any time we move something we go against the idea
> of "separate products".
> This is never simple to solve. If you make plasma check for the KF version
> at cmake time to skip the installation of the plugin, someone then upgrading
> from KF 5.16 to KF 5.17 ends up with no plugin at all.
> Changing the filename is one option, I guess the theme factory in Qt will
> then randomly pick one of the two plugins providing the key "KDE" ?
>
> --
> David Faure, faure at kde.org, http://www.davidfaure.fr
> Working on KDE Frameworks 5
>


More information about the Kde-frameworks-devel mailing list