Re: KDE/Qt Flatpak SDK/Runtime

[Aleix Pol]

On Thu, Nov 17, 2016 at 11:45 AM, Matthias Kuhn  wrote:
> On 11/16/2016 04:02 PM, Aleix Pol wrote:
>> On Mon, Nov 14, 2016 at 12:44 PM, Matthias Kuhn  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.
>>>
>>>  * 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?
>>>
>>> Kind regards
>>> Matthias
>>>
>>> [1] http://qgis.org
>>> [2] https://community.kde.org/Guidelines_and_HOWTOs/Flatpak
>>
>> QtLocation has been applied. You can update to get it in.
>
> After updating the runtime, there seem to be no more missing Qt libs for
> us at this point.
> For now I'll just continue to build on top of the KDE runtime with all
> other deps bundled in the app.
>
> Thank you very much

Cool! :)

Re: KDE/Qt Flatpak SDK/Runtime

[Matthias Kuhn]

On 11/16/2016 04:02 PM, Aleix Pol wrote:
> On Mon, Nov 14, 2016 at 12:44 PM, Matthias Kuhn  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.
>>
>>  * 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?
>>
>> Kind regards
>> Matthias
>>
>> [1] http://qgis.org
>> [2] https://community.kde.org/Guidelines_and_HOWTOs/Flatpak
> 
> QtLocation has been applied. You can update to get it in.

After updating the runtime, there seem to be no more missing Qt libs for
us at this point.
For now I'll just continue to build on top of the KDE runtime with all
other deps bundled in the app.

Thank you very much

Matthias

> 
> Aleix
> 

Re: KDE/Qt Flatpak SDK/Runtime

[Aleix Pol]

On Mon, Nov 14, 2016 at 12:44 PM, Matthias Kuhn  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.
>
>  * 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?
>
> Kind regards
> Matthias
>
> [1] http://qgis.org
> [2] https://community.kde.org/Guidelines_and_HOWTOs/Flatpak

QtLocation has been applied. You can update to get it in.

Aleix

Re: KDE/Qt Flatpak SDK/Runtime

[Brüns , Stefan]

On Dienstag, 15. November 2016 18:00:34 CET Aleix Pol wrote:
> On Tue, Nov 15, 2016 at 1:16 PM, Matthias Kuhn  wrote:
> 
> 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
> how much.
> 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.

If I understand http://flatpak.org/developer.html correctly:
- optional/add-on parts can be referenced using Extensions
- you may use several extensions from application and/or runtime

Also runtimes seem to stack, see e.g. 
https://git.gnome.org/browse/gnome-sdk-images/tree/org.gnome.Sdk.json.in

As far as I understand the OSTree repository format, even distinct runtimes 
which have overlapping content will not duplicate storage or download 
requirements, as OSTree is a content-addressed storage, although I may be 
wrong here.

Kind regards,

Stefan

Re: KDE/Qt Flatpak SDK/Runtime

[Aleix Pol]

On Tue, Nov 15, 2016 at 1:16 PM, Matthias Kuhn  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  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?

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
how much.
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.

Aleix

Re: KDE/Qt Flatpak SDK/Runtime

[Matthias Kuhn]

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  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=tree
>
> Aleix

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




signature.asc
Description: OpenPGP digital signature

Re: KDE/Qt Flatpak SDK/Runtime

[Aleix Pol]

Hi Matthias,
Really happy to see there's interest!

On Mon, Nov 14, 2016 at 12:44 PM, Matthias Kuhn  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.

>  * 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).

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=tree

Aleix

Re: KDE/Qt Flatpak SDK/Runtime

[Matthias Kuhn]

Hi Jan,

I agree that not everything should be in there.
That's why I didn't list dependencies like postgres, proj4, geos, gdal
and many more.

The main goal I have here is to minimize the maintenance overhead by
finding the best way to generalize runtimes. E.g. QtLocation is a core
Qt module, so I think they should be part of a runtime that targets to
be the runtime for "most Qt-based applications as well".

Another approach would be to have a generic Qt runtime on top of which a
separate KDE runtime can be built and another one we manage for our
dependencies. I'm open for all kind of clever ideas.

All the best
Matthias

On 11/14/2016 12:57 PM, Jan Grulich wrote:
> Hi,
> 
> if you add your additional dependencies which are not in KDE's flatpak 
> runtime 
> currently, then I guess it won't have any difference for your users. They 
> will 
> either have to download a runtime requiring more space or an app bundle/repo 
> requiring extra space due to QtLocation, QCA and so on. My personal opinion 
> is 
> that we should cover the most needed stuff for most of the KDE/Qt 
> applications, while keep the extra dependencies in application manifests 
> itself, avoiding to make our runtime unnecesarily huge. Anyway, it's not me 
> who takes care currently of KDE/Qt flatpak runtime, so not my decision.
> 
> Regards,
> Jan
> 
> On pondělí 14. listopadu 2016 12:44:42 CET Matthias Kuhn 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.
>>
>>  * 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?
>>
>> Kind regards
>> Matthias
>>
>> [1] http://qgis.org
>> [2] https://community.kde.org/Guidelines_and_HOWTOs/Flatpak
> 

Re: KDE/Qt Flatpak SDK/Runtime

[Matthias Kuhn]

Hi Jan,

I agree that not everything should be in there.
That's why I didn't list dependencies like postgres, proj4, geos, gdal
and many more.

The main goal I have here is to minimize the maintenance overhead by
finding the best way to generalize runtimes. E.g. QtLocation is a core
Qt module, so I think they should be part of a runtime that targets to
be the runtime for "most Qt-based applications as well".

Another approach would be to have a generic Qt runtime on top of which a
separate KDE runtime can be built and another one we manage for our
dependencies. I'm open for all kind of clever ideas.

All the best
Matthias

On 11/14/2016 12:57 PM, Jan Grulich wrote:
> Hi,
> 
> if you add your additional dependencies which are not in KDE's flatpak 
> runtime 
> currently, then I guess it won't have any difference for your users. They 
> will 
> either have to download a runtime requiring more space or an app bundle/repo 
> requiring extra space due to QtLocation, QCA and so on. My personal opinion 
> is 
> that we should cover the most needed stuff for most of the KDE/Qt 
> applications, while keep the extra dependencies in application manifests 
> itself, avoiding to make our runtime unnecesarily huge. Anyway, it's not me 
> who takes care currently of KDE/Qt flatpak runtime, so not my decision.
> 
> Regards,
> Jan
> 
> On pondělí 14. listopadu 2016 12:44:42 CET Matthias Kuhn 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.
>>
>>  * 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?
>>
>> Kind regards
>> Matthias
>>
>> [1] http://qgis.org
>> [2] https://community.kde.org/Guidelines_and_HOWTOs/Flatpak
> 

Re: KDE/Qt Flatpak SDK/Runtime

[Jan Grulich]

Hi,

if you add your additional dependencies which are not in KDE's flatpak runtime 
currently, then I guess it won't have any difference for your users. They will 
either have to download a runtime requiring more space or an app bundle/repo 
requiring extra space due to QtLocation, QCA and so on. My personal opinion is 
that we should cover the most needed stuff for most of the KDE/Qt 
applications, while keep the extra dependencies in application manifests 
itself, avoiding to make our runtime unnecesarily huge. Anyway, it's not me 
who takes care currently of KDE/Qt flatpak runtime, so not my decision.

Regards,
Jan

On pondělí 14. listopadu 2016 12:44:42 CET Matthias Kuhn 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.
> 
>  * 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?
> 
> Kind regards
> Matthias
> 
> [1] http://qgis.org
> [2] https://community.kde.org/Guidelines_and_HOWTOs/Flatpak

KDE/Qt Flatpak SDK/Runtime

[Matthias Kuhn]

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.

 * 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?

Kind regards
Matthias

[1] http://qgis.org
[2] https://community.kde.org/Guidelines_and_HOWTOs/Flatpak