Web lists-archives.com

Re: KDE/Qt Flatpak SDK/Runtime




Hi Aleix,

Thanks for the quick feedback

On 11/15/2016 12:44 AM, Aleix Pol wrote:
> Hi Matthias,
> Really happy to see there's interest!
>
> On Mon, Nov 14, 2016 at 12:44 PM, Matthias Kuhn <matthias@xxxxxxxxxx> wrote:
>> Hi,
>>
>> I'm a developer of QGIS [1] which makes heavy use of Qt libraries. I was
>> very happy to see the work on a KDE flatpak repository which already
>> packages Qt [2].
>>
>> I have recently been looking into a couple of different approaches to
>> ship app bundles and flatpak sounds like a very interesting one.
>>
>> To not duplicate work I would like to ask if there is interest for a
>> collaboration. In particular, for our needs:
>>
>>  * We require the QtLocation module. Are there plans for adding this?
>>    I will be happy to share a trivial patch that adds this.
> In general I'd say that this possibly should be part of the
> application, now Qt's cmake scripts have a limitation where they all
> need to be in the same prefix. Because of how Flatpak is put together,
> this means it needs to be in the runtime, if you have a patch please
> send it my way.
Cool, happy to do so as soon as I'm back on my desktop (it's actually a
simple copy-paste of the other recipes, replacing the Qt module with
QtLocation).

>
>>  * We also require other components which are closely related to Qt:
>>    Qt Cryptographic Architecture (QCA), QWT, QScintilla, PyQt5, would
>>    you be interested in integrating them into this repository as well?
> Few applications need this, I would recommend to get these into the
> application. I know it feels a bit arbitrary, but I wouldn't want to
> get all the dependencies in there, since we'd also lose the grip on
> what we're offering as well.
>
> At the moment what we're putting is Qt, KDE Frameworks and few bits to
> integrate visually with Plasma.
> I guess that there's few additional things that could be included, I
> also see value in 3rd parties using our runtime, but I don't really
> want the runtime to grow beyond usefulness. (I don't know about many
> KDE applications using QWT or QScintilla).

I don't mind too much about QWT or QScintilla, but I think there's quite
a few applications that could be interested in shipping with PyQt as
dependency.

As I wrote before, one other possibility would be to split up the
current KDE runtime into a Qt runtime and a KDE runtime.
On top of the Qt runtime you could build all the common KDE libraries
with bells and whistles (which we don't require on our side) and we
could put our extra libraries into a QtExtras runtime so there's no
reason to ship them along with your runtime.

Do you think that would make maintenance more complicated than necessary
or do you expect other bad side-effects?

Regards
Matthias

>
> Often it's more about just copying the recipes from one application in
> another, that's in part why I took the initial approach of getting all
> recipes in the same repository.
> https://quickgit.kde.org/?p=flatpak-kde-applications.git&a=tree
>
> Aleix

-- 
Matthias Kuhn
OPENGIS.ch - https://www.opengis.ch
Spatial • (Q)GIS • PostGIS • Open Source


Attachment: signature.asc
Description: OpenPGP digital signature