Re: KDE/Qt Flatpak SDK/Runtime
- Date: Tue, 15 Nov 2016 18:00:34 +0100
- From: Aleix Pol <aleixpol@xxxxxxx>
- Subject: Re: KDE/Qt Flatpak SDK/Runtime
On Tue, Nov 15, 2016 at 1:16 PM, Matthias Kuhn <matthias@xxxxxxxxxx> wrote:
> 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:
>>> I'm a developer of QGIS  which makes heavy use of Qt libraries. I was
>>> very happy to see the work on a KDE flatpak repository which already
>>> packages Qt .
>>> 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
>>> * 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
> 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?
I would like to see how much pyqt increases the size of the (not yet
optimized) runtime. I agree it can be interesting, but I'm not sure by
Also the fact that there's so many approaches for python Qt bindings
doesn't make things much simpler, and that's python alone. Does that
mean we want to have all languages in there? I'll be happy to work
with anyone who wants to get PyQt in their application, if we see that
we're getting so much projects that need PyQt that it makes sense,
then by all means it should go in.
Having different run-times for applications that use KDE Frameworks
and applications that don't feels like shooting ourselves in the foot,
at this moment. Note that in Flatpak runtimes don't extend each other,
they duplicate, AFAIK.