Re: [SailfishDevel] qt upgrade

[rinigus]

I have the mapping applications distributed via Flathub and the experience
has been very good so far. In some aspects its similar to what we have now
- you rely on the runtime (Platform in flatpak lingo) and have to bundle
all extra libs with it. Libs are described using via build scripts and
archive/git (hash, commit id). In my case, its quite a few. As for overall
experience - you get support with packaging through review of the
corresponding pull request and the packages are build on their servers
(kind of OBS as a frontend for the store). Worked quite well and got help
there as well.

Would be good to have flatpak support, but I am not sure what are the
kernel requirements for it.

Back to the original question, Alexander: thanks for sorting it out, I'll
try tomorrow. I do wonder why the keyboard doesn't get activated, though.
Any tips regarding it?

Thanks for the feedback and discussion,

Rinigus


On Sun, Feb 10, 2019 at 11:16 PM Martin Kolman 
wrote:

> Sun, 10 Feb 2019 23:05:28 +0200 E.s. Rosenberg
> 
> :
>
> Flatpak would make our phones so much more insecure - instead of Jolla
> updating bad/insecure libraries (which also happens at a pace that leaves
> to be desired) you become dependent on the devs of the application you are
> using doing that.
>
> I don't think this is correct. Unlike for example App image where
> developers AFAIK *do* have to bundle everything, Flatpak has a concept of
> shared application runtimes.  As long an application uses sensitive
> libraries (mainly crypto related) from the runtime, it's not really
> different from the current system with shared system libraries - as long as
> the runtime is being properly maintained.
>
> Also both main app distribution channels in Sailfish OS are taking binary
> RPMs only and there is nothing really preventing developers from bundling
> about anything already.
>
>
> Since Jolla tries to have one of its' claims to fame be security it seems
> that flatpak support should be just about the last thing they should
> support.
>
> Looks like the Purism Librem 5 open hardware phone project aims to use
> Flatpaks for third party application distribution:
>
>
> https://www.phoronix.com/scan.php?page=news_item&px=Purism-PureOS-Store-Flatpaks
>
>
> Just my 2c
>
> Op zo 10 feb. 2019 om 22:56 schreef Martin Kolman  >:
>
>> Sun, 10 Feb 2019 09:56:06 +0200 Rinigus 
>> :
>>
>> Morning,
>>
>> suggestion to consider Qt 5.12 in /opt comes from the following:
>>
>> * newer web engine
>> * we can use and contribute to the code written for Plasma with its
>> Kirigami
>>
>> It will not bring native new applications, we don't have Silica for it.
>> However, I personally think it makes more sense to use and help out with
>> the development of Linux-based solutions than to use Android-provided web
>> browsers through SFOS Android compatibility layer.
>>
>> This would not to be intended to be installed in /usr and having platform
>> supporting multiple Qt versions at once. I have no idea whether its
>> possible and no desire to get into messing up the system layer.
>>
>> Dmitriy: I don't know whether you can mix different Qt versions in the
>> same application. In this respect, yes, you could probably ship Qt 512
>> stack fully, but would probably have to stay away from the system-provided
>> Qt.
>>
>> Leszek: fragmentation is to be considered, indeed. But, as far as I
>> understood, it makes sense to develop browser against the last version of
>> Qt. In some aspect, using Qt59 on SFOS contributes to fragmentation in a
>> way that we, on SFOS, will be using the version that is slowly phased out
>> already. At present, Kirigami is developed using Qt512, with Qt511 version
>> having at least one bug that will never be fixed. Not sure whether Kirigami
>> runs against Qt59. So, if we would like to run Kirigami apps, Qt 5.12 is
>> most probably needed.
>>
>> I hope eventually support for using Flatpak for package distribution is
>> added to Sailfish OS, as that would make it possible to decouple the
>> "system" Qt version from the "application" Qt version. Updating the system
>> version would not longer risk breakage in third party applications and
>> could be done on it's own, likely slower, pace. On the other hand updating
>> the "application" Qt would mean just releasing a new Flatpak runtime with
>> the updated Qt version. Old application would continue working with old
>> runtime/-s while new apps would be able to use all the new goodies
>> available via the new runtime. IIRC this is already being done for Qt on
>> the desktop via the Flatpak runtimes maintained by the KDE project.
>>
>> Of course there are some trade-offs and things to consider - you would
>> have to, in some capacity, maintain multiple versions of Qt and system
>> libraries in parallel. On the other hand, each Qt version would be either a
>> "system" only one or "application" one. Not one that needs to be perfect or
>> else both the system and apps will stop working. This could help to reduce

Re: [SailfishDevel] qt upgrade

[Alexey Andreyev]

Hello, everyone!
Talking about flatpak: there's even a bit aggressive criticism about it --
http://flatkill.org/
I am personally not against this technology completely, but probably more
into making more of an effort to provide better system side libraries.

пн, 11 февр. 2019 г. в 00:16, Martin Kolman :

> Sun, 10 Feb 2019 23:05:28 +0200 E.s. Rosenberg
> 
> :
>
> Flatpak would make our phones so much more insecure - instead of Jolla
> updating bad/insecure libraries (which also happens at a pace that leaves
> to be desired) you become dependent on the devs of the application you are
> using doing that.
>
> I don't think this is correct. Unlike for example App image where
> developers AFAIK *do* have to bundle everything, Flatpak has a concept of
> shared application runtimes.  As long an application uses sensitive
> libraries (mainly crypto related) from the runtime, it's not really
> different from the current system with shared system libraries - as long as
> the runtime is being properly maintained.
>
> Also both main app distribution channels in Sailfish OS are taking binary
> RPMs only and there is nothing really preventing developers from bundling
> about anything already.
>
>
> Since Jolla tries to have one of its' claims to fame be security it seems
> that flatpak support should be just about the last thing they should
> support.
>
> Looks like the Purism Librem 5 open hardware phone project aims to use
> Flatpaks for third party application distribution:
>
>
> https://www.phoronix.com/scan.php?page=news_item&px=Purism-PureOS-Store-Flatpaks
>
>
> Just my 2c
>
> Op zo 10 feb. 2019 om 22:56 schreef Martin Kolman  >:
>
>> Sun, 10 Feb 2019 09:56:06 +0200 Rinigus 
>> :
>>
>> Morning,
>>
>> suggestion to consider Qt 5.12 in /opt comes from the following:
>>
>> * newer web engine
>> * we can use and contribute to the code written for Plasma with its
>> Kirigami
>>
>> It will not bring native new applications, we don't have Silica for it.
>> However, I personally think it makes more sense to use and help out with
>> the development of Linux-based solutions than to use Android-provided web
>> browsers through SFOS Android compatibility layer.
>>
>> This would not to be intended to be installed in /usr and having platform
>> supporting multiple Qt versions at once. I have no idea whether its
>> possible and no desire to get into messing up the system layer.
>>
>> Dmitriy: I don't know whether you can mix different Qt versions in the
>> same application. In this respect, yes, you could probably ship Qt 512
>> stack fully, but would probably have to stay away from the system-provided
>> Qt.
>>
>> Leszek: fragmentation is to be considered, indeed. But, as far as I
>> understood, it makes sense to develop browser against the last version of
>> Qt. In some aspect, using Qt59 on SFOS contributes to fragmentation in a
>> way that we, on SFOS, will be using the version that is slowly phased out
>> already. At present, Kirigami is developed using Qt512, with Qt511 version
>> having at least one bug that will never be fixed. Not sure whether Kirigami
>> runs against Qt59. So, if we would like to run Kirigami apps, Qt 5.12 is
>> most probably needed.
>>
>> I hope eventually support for using Flatpak for package distribution is
>> added to Sailfish OS, as that would make it possible to decouple the
>> "system" Qt version from the "application" Qt version. Updating the system
>> version would not longer risk breakage in third party applications and
>> could be done on it's own, likely slower, pace. On the other hand updating
>> the "application" Qt would mean just releasing a new Flatpak runtime with
>> the updated Qt version. Old application would continue working with old
>> runtime/-s while new apps would be able to use all the new goodies
>> available via the new runtime. IIRC this is already being done for Qt on
>> the desktop via the Flatpak runtimes maintained by the KDE project.
>>
>> Of course there are some trade-offs and things to consider - you would
>> have to, in some capacity, maintain multiple versions of Qt and system
>> libraries in parallel. On the other hand, each Qt version would be either a
>> "system" only one or "application" one. Not one that needs to be perfect or
>> else both the system and apps will stop working. This could help to reduce
>> the maintenance burden somewhat.
>>
>> Also, even if it would be nice to keep all older runtimes around so that
>> all old (and likely abandoned) apps continue working, it would be likely
>> prudent to stop maintaining old runtimes after a while to keep the
>> maintenance burden reasonable.
>>
>> There is also a question if this is something that community can at least
>> start or Jolla involvement is needed. As already mentioned in the thread,
>> due to Silica still being closed source a community only Flatpak effort
>> likely could not support running Silica applications. A Jolla provided
>> runtime - or open source Silica - would be needed for that.
>>

Re: [SailfishDevel] qt upgrade

[Martin Kolman]

Sun, 10 Feb 2019 23:05:28 +0200 E.s. Rosenberg 
:
Flatpak would make our phones so much more insecure - instead of Jolla 
updating bad/insecure libraries (which also happens at a pace that 
leaves to be desired) you become dependent on the devs of the 
application you are using doing that.


I don't think this is correct. Unlike for example App image where 
developers AFAIK *do* have to bundle everything, Flatpak has a concept 
of shared application runtimes.  As long an application uses sensitive 
libraries (mainly crypto related) from the runtime, it's not really 
different from the current system with shared system libraries - as long 
as the runtime is being properly maintained.


Also both main app distribution channels in Sailfish OS are taking 
binary RPMs only and there is nothing really preventing developers from 
bundling about anything already.




Since Jolla tries to have one of its' claims to fame be security it 
seems that flatpak support should be just about the last thing they 
should support.


Looks like the Purism Librem 5 open hardware phone project aims to use 
Flatpaks for third party application distribution:


https://www.phoronix.com/scan.php?page=news_item&px=Purism-PureOS-Store-Flatpaks



Just my 2c

Op zo 10 feb. 2019 om 22:56 schreef Martin Kolman 
mailto:martin.kol...@gmail.com>>:


Sun, 10 Feb 2019 09:56:06 +0200 Rinigus 
:

Morning,

suggestion to consider Qt 5.12 in /opt comes from the following:

* newer web engine
* we can use and contribute to the code written for Plasma with
its Kirigami

It will not bring native new applications, we don't have Silica
for it. However, I personally think it makes more sense to use
and help out with the development of Linux-based solutions than
to use Android-provided web browsers through SFOS Android
compatibility layer.

This would not to be intended to be installed in /usr and having
platform supporting multiple Qt versions at once. I have no idea
whether its possible and no desire to get into messing up the
system layer.

Dmitriy: I don't know whether you can mix different Qt versions
in the same application. In this respect, yes, you could probably
ship Qt 512 stack fully, but would probably have to stay away
from the system-provided Qt.

Leszek: fragmentation is to be considered, indeed. But, as far as
I understood, it makes sense to develop browser against the last
version of Qt. In some aspect, using Qt59 on SFOS contributes to
fragmentation in a way that we, on SFOS, will be using the
version that is slowly phased out already. At present, Kirigami
is developed using Qt512, with Qt511 version having at least one
bug that will never be fixed. Not sure whether Kirigami runs
against Qt59. So, if we would like to run Kirigami apps, Qt 5.12
is most probably needed.


I hope eventually support for using Flatpak for package
distribution is added to Sailfish OS, as that would make it
possible to decouple the "system" Qt version from the
"application" Qt version. Updating the system version would not
longer risk breakage in third party applications and could be done
on it's own, likely slower, pace. On the other hand updating the
"application" Qt would mean just releasing a new Flatpak runtime
with the updated Qt version. Old application would continue
working with old runtime/-s while new apps would be able to use
all the new goodies available via the new runtime. IIRC this is
already being done for Qt on the desktop via the Flatpak runtimes
maintained by the KDE project.

Of course there are some trade-offs and things to consider - you
would have to, in some capacity, maintain multiple versions of Qt
and system libraries in parallel. On the other hand, each Qt
version would be either a "system" only one or "application" one.
Not one that needs to be perfect or else both the system and apps
will stop working. This could help to reduce the maintenance
burden somewhat.

Also, even if it would be nice to keep all older runtimes around
so that all old (and likely abandoned) apps continue working, it
would be likely prudent to stop maintaining old runtimes after a
while to keep the maintenance burden reasonable.

There is also a question if this is something that community can
at least start or Jolla involvement is needed. As already
mentioned in the thread, due to Silica still being closed source a
community only Flatpak effort likely could not support running
Silica applications. A Jolla provided runtime - or open source
Silica - would be needed for that.




Cheers,

Rinigus

On Sun, Feb 10, 2019 at 8:55 AM Dmitriy Purgin mailto:dpur...@gmail.com>> wrote:

Hi all,

if there are some parts of the newer Qt you need in your app,
you can always compi

Re: [SailfishDevel] qt upgrade

[E.S. Rosenberg]

Flatpak would make our phones so much more insecure - instead of Jolla
updating bad/insecure libraries (which also happens at a pace that leaves
to be desired) you become dependent on the devs of the application you are
using doing that.

Since Jolla tries to have one of its' claims to fame be security it seems
that flatpak support should be just about the last thing they should
support.

Just my 2c

Op zo 10 feb. 2019 om 22:56 schreef Martin Kolman :

> Sun, 10 Feb 2019 09:56:06 +0200 Rinigus 
> :
>
> Morning,
>
> suggestion to consider Qt 5.12 in /opt comes from the following:
>
> * newer web engine
> * we can use and contribute to the code written for Plasma with its
> Kirigami
>
> It will not bring native new applications, we don't have Silica for it.
> However, I personally think it makes more sense to use and help out with
> the development of Linux-based solutions than to use Android-provided web
> browsers through SFOS Android compatibility layer.
>
> This would not to be intended to be installed in /usr and having platform
> supporting multiple Qt versions at once. I have no idea whether its
> possible and no desire to get into messing up the system layer.
>
> Dmitriy: I don't know whether you can mix different Qt versions in the
> same application. In this respect, yes, you could probably ship Qt 512
> stack fully, but would probably have to stay away from the system-provided
> Qt.
>
> Leszek: fragmentation is to be considered, indeed. But, as far as I
> understood, it makes sense to develop browser against the last version of
> Qt. In some aspect, using Qt59 on SFOS contributes to fragmentation in a
> way that we, on SFOS, will be using the version that is slowly phased out
> already. At present, Kirigami is developed using Qt512, with Qt511 version
> having at least one bug that will never be fixed. Not sure whether Kirigami
> runs against Qt59. So, if we would like to run Kirigami apps, Qt 5.12 is
> most probably needed.
>
> I hope eventually support for using Flatpak for package distribution is
> added to Sailfish OS, as that would make it possible to decouple the
> "system" Qt version from the "application" Qt version. Updating the system
> version would not longer risk breakage in third party applications and
> could be done on it's own, likely slower, pace. On the other hand updating
> the "application" Qt would mean just releasing a new Flatpak runtime with
> the updated Qt version. Old application would continue working with old
> runtime/-s while new apps would be able to use all the new goodies
> available via the new runtime. IIRC this is already being done for Qt on
> the desktop via the Flatpak runtimes maintained by the KDE project.
>
> Of course there are some trade-offs and things to consider - you would
> have to, in some capacity, maintain multiple versions of Qt and system
> libraries in parallel. On the other hand, each Qt version would be either a
> "system" only one or "application" one. Not one that needs to be perfect or
> else both the system and apps will stop working. This could help to reduce
> the maintenance burden somewhat.
>
> Also, even if it would be nice to keep all older runtimes around so that
> all old (and likely abandoned) apps continue working, it would be likely
> prudent to stop maintaining old runtimes after a while to keep the
> maintenance burden reasonable.
>
> There is also a question if this is something that community can at least
> start or Jolla involvement is needed. As already mentioned in the thread,
> due to Silica still being closed source a community only Flatpak effort
> likely could not support running Silica applications. A Jolla provided
> runtime - or open source Silica - would be needed for that.
>
>
>
> Cheers,
>
> Rinigus
>
> On Sun, Feb 10, 2019 at 8:55 AM Dmitriy Purgin  wrote:
>
>> Hi all,
>>
>> if there are some parts of the newer Qt you need in your app, you can
>> always compile it yourself, link your app against the newer version and
>> ship these libraries with your app.
>>
>> Cheers
>> Dmitriy
>>
>> On Sat, Feb 9, 2019 at 6:44 PM rinigus  wrote:
>>
>>> Hi,
>>>
>>> sounds like there are porting and licensing issues on the way of getting
>>> qt 5.9 for SFOS (see logs from the last #mer-meeting). Its all
>>> understandable, but it would be great to get a way forward. Not sure
>>> whether it has been considered by others and I wonder whether we can make a
>>> separate Qt 5.12 packages for /opt/qt512?
>>>
>>> From a quick test, it is possible to run non-silica applications as well
>>> (tested with qmlscene and QML with plain Window). In that test, even
>>> keyboard worked as expected. Look was non-native, but let it be for now.
>>>
>>> So, I wonder, whether its possible to get Qt 5.12 compiled with
>>> /opt/qt512 prefix and then use it for development using the latest libs
>>> (new web browser?) and collaborate with other mobile Linux'es out there. As
>>> far as I remember, Wayland was rather old and, maybe, it will preclude Q

Re: [SailfishDevel] qt upgrade

[Martin Kolman]

Sun, 10 Feb 2019 09:56:06 +0200 Rinigus :

Morning,

suggestion to consider Qt 5.12 in /opt comes from the following:

* newer web engine
* we can use and contribute to the code written for Plasma with its 
Kirigami


It will not bring native new applications, we don't have Silica for 
it. However, I personally think it makes more sense to use and help 
out with the development of Linux-based solutions than to use 
Android-provided web browsers through SFOS Android compatibility layer.


This would not to be intended to be installed in /usr and having 
platform supporting multiple Qt versions at once. I have no idea 
whether its possible and no desire to get into messing up the system 
layer.


Dmitriy: I don't know whether you can mix different Qt versions in the 
same application. In this respect, yes, you could probably ship Qt 512 
stack fully, but would probably have to stay away from the 
system-provided Qt.


Leszek: fragmentation is to be considered, indeed. But, as far as I 
understood, it makes sense to develop browser against the last version 
of Qt. In some aspect, using Qt59 on SFOS contributes to fragmentation 
in a way that we, on SFOS, will be using the version that is slowly 
phased out already. At present, Kirigami is developed using Qt512, 
with Qt511 version having at least one bug that will never be fixed. 
Not sure whether Kirigami runs against Qt59. So, if we would like to 
run Kirigami apps, Qt 5.12 is most probably needed.


I hope eventually support for using Flatpak for package distribution is 
added to Sailfish OS, as that would make it possible to decouple the 
"system" Qt version from the "application" Qt version. Updating the 
system version would not longer risk breakage in third party 
applications and could be done on it's own, likely slower, pace. On the 
other hand updating the "application" Qt would mean just releasing a new 
Flatpak runtime with the updated Qt version. Old application would 
continue working with old runtime/-s while new apps would be able to use 
all the new goodies available via the new runtime. IIRC this is already 
being done for Qt on the desktop via the Flatpak runtimes maintained by 
the KDE project.


Of course there are some trade-offs and things to consider - you would 
have to, in some capacity, maintain multiple versions of Qt and system 
libraries in parallel. On the other hand, each Qt version would be 
either a "system" only one or "application" one. Not one that needs to 
be perfect or else both the system and apps will stop working. This 
could help to reduce the maintenance burden somewhat.


Also, even if it would be nice to keep all older runtimes around so that 
all old (and likely abandoned) apps continue working, it would be likely 
prudent to stop maintaining old runtimes after a while to keep the 
maintenance burden reasonable.


There is also a question if this is something that community can at 
least start or Jolla involvement is needed. As already mentioned in the 
thread, due to Silica still being closed source a community only Flatpak 
effort likely could not support running Silica applications. A Jolla 
provided runtime - or open source Silica - would be needed for that.





Cheers,

Rinigus

On Sun, Feb 10, 2019 at 8:55 AM Dmitriy Purgin > wrote:


Hi all,

if there are some parts of the newer Qt you need in your app, you
can always compile it yourself, link your app against the newer
version and ship these libraries with your app.

Cheers
Dmitriy

On Sat, Feb 9, 2019 at 6:44 PM rinigus mailto:rinigus@gmail.com>> wrote:

Hi,

sounds like there are porting and licensing issues on the way
of getting qt 5.9 for SFOS (see logs from the last
#mer-meeting). Its all understandable, but it would be great
to get a way forward. Not sure whether it has been considered
by others and I wonder whether we can make a separate Qt 5.12
packages for /opt/qt512?

From a quick test, it is possible to run non-silica
applications as well (tested with qmlscene and QML with plain
Window). In that test, even keyboard worked as expected. Look
was non-native, but let it be for now.

So, I wonder, whether its possible to get Qt 5.12 compiled
with /opt/qt512 prefix and then use it for development using
the latest libs (new web browser?) and collaborate with other
mobile Linux'es out there. As far as I remember, Wayland was
rather old and, maybe, it will preclude Qt 5.12 compilation.
@mal, though, had a newer version around and it may serve a
purpose for such project. Is there anything else that should
be considered?

Cheers,

Rinigus

PS: Please consider it as request-for-comment and not as any
kind of statement nor call-for-action :)
___
SailfishOS.o

Re: [SailfishDevel] qt upgrade

[Martin Kolman]

Sun, 10 Feb 2019 12:20:31 +0100 Lukáš Karas :

Hi all


To sum up, no idea how much we can help with 5.9 transition and what's
holding it back specifically.


 From the Fosdem discussion, I feel like there is no big technical issue.
There was message that majority of SFOS core components already has branches
prepared for Qt 5.9. Issue with transition is licensing - more Qt components
was switched from LGPLv2.1 license to LGPLv3 [1]. If I understand it
correctly, LGPLv2 guarantees you as a user that you will get source code for
the library and you should be able to update library without application
modification - it allows proprietary applications to link shared Qt
libraries... But this second right is not mentioned explicitly. It is fixed in
LGPLv3 that guarantee to user that have to be possible to replace libraries.

This is not problem for SFOS itself, when you can get root access just by one
click. But for some Jolla partners, that want to create certified devices for
governments, this right may be a problem. Noone mention specific companies,
but it is clear that Jolla needs approval from their partners first...


I really hope they finally decide to just got with GPLv3, as it's not 
just Qt, but many


important system libraries, that are stuck on ancient pre-GPLv3 
versions. Many of those libraries


are likely no longer maintained by upstream, which long ago moved to 
taking care of the new GPLv3


licensed codebase instead.



Lukas

1) https://blog.qt.io/blog/2014/08/20/adding-lgpl-v3-to-qt/

___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org


___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org

Re: [SailfishDevel] qt upgrade

[Alexander Akulich]

Oh, for some reason the project was indeed rebuilt by 07-Feb-2019.
Last time I tried it two month ago and it worked well :-(.

I fixed some small new issues and now, wow, the problem with wayland is gone!
This opens the possibility to develop and deploy at least the limited
QQC2-based applications without a keyboard support. The last time I
checked the build, I tried to develop a game for exactly that case in
90 minutes. If you're curious, you're welcome to check it out:
zypper in one-to-nine
QT_SCALE_FACTOR=2 LD_LIBRARY_PATH=/usr/lib/qt5.9/lib
/usr/lib/qt5.9/bin/one-to-nine

On Sun, Feb 10, 2019 at 4:58 PM rinigus  wrote:
>
> No go, file conflicts appeared for several packages trying to overwrite qt56 
> installation. For example, qt5.9-qtdeclarative-qtquick was trying to write 
> /usr/lib/libQt5Quick.so.5 . I presume something changed in OBS and your 
> prefix path wasn't picked up.
>
> Rinigus
>
> On Sun, Feb 10, 2019 at 1:01 PM Alexander Akulich 
>  wrote:
>>
>> The keypoints of the build:
>> - upstream Qt-5.9.6
>> - Q_OS_SAILFISH platform [1]
>> - Sailfish Theme added as a plugin instead of direct
>> QGenericUnixTheme patching [2]
>> - _qt5_version re-defined in the OBS project config [3] (default value
>> defined in qt5 macros).
>> - qt5 macros [4] extended and moved to own repository [5]. The added
>> macros fix installations conflicts, improve compatibility with fedora
>> specs and let us flexibly define Qt installation layout from the
>> outside of qtbase.
>> - qtchooser-config is built as a part of qtbase.
>>
>> [1] 
>> https://git.merproject.org/Kaffeine/qtbase/commit/7b8850fc9df17384a8cf53dc8b1d1e435e806794
>> [2] 
>> https://git.merproject.org/Kaffeine/qtbase/commit/816d9f7fe4fac0208d672086ae910cae772dcd32
>> [3] https://build.merproject.org/project/prjconf/home:Kaffeine:qt:prefix:5.9
>> [4] 
>> https://git.merproject.org/mer-core/qtbase/blob/mer-5.6/rpm/macros.qt5-default
>> [5] https://git.merproject.org/Kaffeine/qt5-rpm-macros/blob/master/macros.qt5
>>
>> Just try quickcontrols2/gallery and you'll see what's the problem
>> (maliit keyboard doesn't show up and the window doesn't appear in
>> lipstick home screen).
>>
>> On Sun, Feb 10, 2019 at 1:07 PM rinigus  wrote:
>> >
>> > Nice work,
>> >
>> > so, there is already something similar done. Can't find where do you 
>> > define _qt_prefix for your SPEC 
>> > (https://git.merproject.org/Kaffeine/qtbase/blob/sailfish-platform-5.9/rpm/qtbase.spec).
>> >  There are also bunch of conflicts defined there, no idea whether they 
>> > interfere.
>> >
>> > Which issues did you have with Wayland and keyboard (which of them, maliit 
>> > or qtvirtualkeyboard?).
>> >
>> > @tortoisedoc: Sounds like this upgrade (5.6->5.9) is as much political as 
>> > it is technical. As for 5.12, I don't know if there are some bugs there 
>> > that have to be fixed. When using flatpak platform with 5.12, I have 
>> > issues with QML Audio and some strange scaling of the map (latter could be 
>> > also my bug in mapbox gl qml plugin). On 5.11, all performed as it was 
>> > expected. So, either flatpak platform has still some issues at 5.12 or 
>> > 5.12 itself has some bugs.
>> >
>> > To sum up, no idea how much we can help with 5.9 transition and what's 
>> > holding it back specifically.
>> >
>> > Rinigus
>> >
>> > On Sun, Feb 10, 2019 at 11:17 AM Alexander Akulich 
>> >  wrote:
>> >>
>> >> Hi,
>> >>
>> >> I experimented with a build in prefix in March 2018. I changed MER Qt
>> >> build configuration to make it trivial to install an arbitrary number
>> >> of versions simultaneously. I'll make PRs on git.merproject.org once
>> >> Qt-5.9 support will be merged to master.
>> >> There are two issues — wayland and virtual keyboard. I posted
>> >> instruction in Sailfish OS Fan Club group in Telegram, here it is:
>> >>
>> >> >// Qt 5.9 for Sailfish OS (installed to /usr/lib/qt5.9 simultaneously to 
>> >> >the system Qt)
>> >> >// To install (root or privileged):
>> >> >ssu ar qt-prefix-5.9 
>> >> >http://repo.merproject.org/obs/home:/Kaffeine:/qt:/prefix:/5.9/latest_armv7hl
>> >> >zypper ref qt-prefix-5.9
>> >> >zypper in qt5.9-qtquickcontrols2-examples qt5.9-qtwayland
>> >> >
>> >> >// To remove (root or privileged):
>> >> >zypper rm qt5.9*
>> >> >
>> >> >// To try out (nemo):
>> >> >QT_SCALE_FACTOR=2 LD_LIBRARY_PATH=/usr/lib/qt5.9/lib 
>> >> >/usr/lib/qt5.9/examples/quickcontrols2/gallery/gallery
>> >> >
>> >> >This is a very first success build, please do not expect much :).
>> >> >
>> >> >P.S.: Select Material style in the settings at the right top corner to 
>> >> >make the demo a bit nicer.
>> >>
>> >> I also mostly built Qt-5.11, but it is not an LTS and IMO not as big
>> >> step forward as 5.9, so I didn't evolve it.
>> >>
>> >> On Sat, Feb 9, 2019 at 8:44 PM rinigus  wrote:
>> >> >
>> >> > Hi,
>> >> >
>> >> > sounds like there are porting and licensing issues on the way of 
>> >> > getting qt 5.9 for SFOS (see logs from the last #mer-meeting). Its all 
>> >> 

Re: [SailfishDevel] qt upgrade

[Dmitriy Purgin]

> Dmitriy: I don't know whether you can mix different Qt versions in the
same application.
> In this respect, yes, you could probably ship Qt 512 stack fully, but
would probably have
> to stay away from the system-provided Qt.

Sorry, my wording was a bit misleading.

What I actually meant was: If you need a newer functionality from a newer
Qt version (some wild guess: QtSerialBus or QtOpcUa), you can take the
sources of Qt 5.12 and compile them using the Sailfish SDK Qt 5.9 kit (or
whatever the current one is?). Thus you get a Qt module (library) working
with the system Qt and all the Sailfish stuff, and you just link your app
against this "custom" library, not the SDK one. I did this a couple of
years ago to backport the QtConnectivity with Blueetooth LE  to some old
Sailfish 2.x, and it worked. Of course, the newer the Qt library is that
you want to backport, the worse it gets in terms of source and toolchain
compatibility but it's still possible.

Cheers
Dmitriy

On Sun, Feb 10, 2019 at 8:56 AM rinigus  wrote:

> Morning,
>
> suggestion to consider Qt 5.12 in /opt comes from the following:
>
> * newer web engine
> * we can use and contribute to the code written for Plasma with its
> Kirigami
>
> It will not bring native new applications, we don't have Silica for it.
> However, I personally think it makes more sense to use and help out with
> the development of Linux-based solutions than to use Android-provided web
> browsers through SFOS Android compatibility layer.
>
> This would not to be intended to be installed in /usr and having platform
> supporting multiple Qt versions at once. I have no idea whether its
> possible and no desire to get into messing up the system layer.
>
> Dmitriy: I don't know whether you can mix different Qt versions in the
> same application. In this respect, yes, you could probably ship Qt 512
> stack fully, but would probably have to stay away from the system-provided
> Qt.
>
> Leszek: fragmentation is to be considered, indeed. But, as far as I
> understood, it makes sense to develop browser against the last version of
> Qt. In some aspect, using Qt59 on SFOS contributes to fragmentation in a
> way that we, on SFOS, will be using the version that is slowly phased out
> already. At present, Kirigami is developed using Qt512, with Qt511 version
> having at least one bug that will never be fixed. Not sure whether Kirigami
> runs against Qt59. So, if we would like to run Kirigami apps, Qt 5.12 is
> most probably needed.
>
> Cheers,
>
> Rinigus
>
> On Sun, Feb 10, 2019 at 8:55 AM Dmitriy Purgin  wrote:
>
>> Hi all,
>>
>> if there are some parts of the newer Qt you need in your app, you can
>> always compile it yourself, link your app against the newer version and
>> ship these libraries with your app.
>>
>> Cheers
>> Dmitriy
>>
>> On Sat, Feb 9, 2019 at 6:44 PM rinigus  wrote:
>>
>>> Hi,
>>>
>>> sounds like there are porting and licensing issues on the way of getting
>>> qt 5.9 for SFOS (see logs from the last #mer-meeting). Its all
>>> understandable, but it would be great to get a way forward. Not sure
>>> whether it has been considered by others and I wonder whether we can make a
>>> separate Qt 5.12 packages for /opt/qt512?
>>>
>>> From a quick test, it is possible to run non-silica applications as well
>>> (tested with qmlscene and QML with plain Window). In that test, even
>>> keyboard worked as expected. Look was non-native, but let it be for now.
>>>
>>> So, I wonder, whether its possible to get Qt 5.12 compiled with
>>> /opt/qt512 prefix and then use it for development using the latest libs
>>> (new web browser?) and collaborate with other mobile Linux'es out there. As
>>> far as I remember, Wayland was rather old and, maybe, it will preclude Qt
>>> 5.12 compilation. @mal, though, had a newer version around and it may serve
>>> a purpose for such project. Is there anything else that should be
>>> considered?
>>>
>>> Cheers,
>>>
>>> Rinigus
>>>
>>> PS: Please consider it as request-for-comment and not as any kind of
>>> statement nor call-for-action :)
>>> ___
>>> SailfishOS.org Devel mailing list
>>> To unsubscribe, please send a mail to
>>> devel-unsubscr...@lists.sailfishos.org
>>
>> ___
>> SailfishOS.org Devel mailing list
>> To unsubscribe, please send a mail to
>> devel-unsubscr...@lists.sailfishos.org
>
> ___
> SailfishOS.org Devel mailing list
> To unsubscribe, please send a mail to
> devel-unsubscr...@lists.sailfishos.org
___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org

Re: [SailfishDevel] qt upgrade

[rinigus]

No go, file conflicts appeared for several packages trying to overwrite
qt56 installation. For example, qt5.9-qtdeclarative-qtquick was trying to
write /usr/lib/libQt5Quick.so.5 . I presume something changed in OBS and
your prefix path wasn't picked up.

Rinigus

On Sun, Feb 10, 2019 at 1:01 PM Alexander Akulich <
akulichalexan...@gmail.com> wrote:

> The keypoints of the build:
> - upstream Qt-5.9.6
> - Q_OS_SAILFISH platform [1]
> - Sailfish Theme added as a plugin instead of direct
> QGenericUnixTheme patching [2]
> - _qt5_version re-defined in the OBS project config [3] (default value
> defined in qt5 macros).
> - qt5 macros [4] extended and moved to own repository [5]. The added
> macros fix installations conflicts, improve compatibility with fedora
> specs and let us flexibly define Qt installation layout from the
> outside of qtbase.
> - qtchooser-config is built as a part of qtbase.
>
> [1]
> https://git.merproject.org/Kaffeine/qtbase/commit/7b8850fc9df17384a8cf53dc8b1d1e435e806794
> [2]
> https://git.merproject.org/Kaffeine/qtbase/commit/816d9f7fe4fac0208d672086ae910cae772dcd32
> [3]
> https://build.merproject.org/project/prjconf/home:Kaffeine:qt:prefix:5.9
> [4]
> https://git.merproject.org/mer-core/qtbase/blob/mer-5.6/rpm/macros.qt5-default
> [5]
> https://git.merproject.org/Kaffeine/qt5-rpm-macros/blob/master/macros.qt5
>
> Just try quickcontrols2/gallery and you'll see what's the problem
> (maliit keyboard doesn't show up and the window doesn't appear in
> lipstick home screen).
>
> On Sun, Feb 10, 2019 at 1:07 PM rinigus  wrote:
> >
> > Nice work,
> >
> > so, there is already something similar done. Can't find where do you
> define _qt_prefix for your SPEC (
> https://git.merproject.org/Kaffeine/qtbase/blob/sailfish-platform-5.9/rpm/qtbase.spec).
> There are also bunch of conflicts defined there, no idea whether they
> interfere.
> >
> > Which issues did you have with Wayland and keyboard (which of them,
> maliit or qtvirtualkeyboard?).
> >
> > @tortoisedoc: Sounds like this upgrade (5.6->5.9) is as much political
> as it is technical. As for 5.12, I don't know if there are some bugs there
> that have to be fixed. When using flatpak platform with 5.12, I have issues
> with QML Audio and some strange scaling of the map (latter could be also my
> bug in mapbox gl qml plugin). On 5.11, all performed as it was expected.
> So, either flatpak platform has still some issues at 5.12 or 5.12 itself
> has some bugs.
> >
> > To sum up, no idea how much we can help with 5.9 transition and what's
> holding it back specifically.
> >
> > Rinigus
> >
> > On Sun, Feb 10, 2019 at 11:17 AM Alexander Akulich <
> akulichalexan...@gmail.com> wrote:
> >>
> >> Hi,
> >>
> >> I experimented with a build in prefix in March 2018. I changed MER Qt
> >> build configuration to make it trivial to install an arbitrary number
> >> of versions simultaneously. I'll make PRs on git.merproject.org once
> >> Qt-5.9 support will be merged to master.
> >> There are two issues — wayland and virtual keyboard. I posted
> >> instruction in Sailfish OS Fan Club group in Telegram, here it is:
> >>
> >> >// Qt 5.9 for Sailfish OS (installed to /usr/lib/qt5.9 simultaneously
> to the system Qt)
> >> >// To install (root or privileged):
> >> >ssu ar qt-prefix-5.9
> http://repo.merproject.org/obs/home:/Kaffeine:/qt:/prefix:/5.9/latest_armv7hl
> >> >zypper ref qt-prefix-5.9
> >> >zypper in qt5.9-qtquickcontrols2-examples qt5.9-qtwayland
> >> >
> >> >// To remove (root or privileged):
> >> >zypper rm qt5.9*
> >> >
> >> >// To try out (nemo):
> >> >QT_SCALE_FACTOR=2 LD_LIBRARY_PATH=/usr/lib/qt5.9/lib
> /usr/lib/qt5.9/examples/quickcontrols2/gallery/gallery
> >> >
> >> >This is a very first success build, please do not expect much :).
> >> >
> >> >P.S.: Select Material style in the settings at the right top corner to
> make the demo a bit nicer.
> >>
> >> I also mostly built Qt-5.11, but it is not an LTS and IMO not as big
> >> step forward as 5.9, so I didn't evolve it.
> >>
> >> On Sat, Feb 9, 2019 at 8:44 PM rinigus  wrote:
> >> >
> >> > Hi,
> >> >
> >> > sounds like there are porting and licensing issues on the way of
> getting qt 5.9 for SFOS (see logs from the last #mer-meeting). Its all
> understandable, but it would be great to get a way forward. Not sure
> whether it has been considered by others and I wonder whether we can make a
> separate Qt 5.12 packages for /opt/qt512?
> >> >
> >> > From a quick test, it is possible to run non-silica applications as
> well (tested with qmlscene and QML with plain Window). In that test, even
> keyboard worked as expected. Look was non-native, but let it be for now.
> >> >
> >> > So, I wonder, whether its possible to get Qt 5.12 compiled with
> /opt/qt512 prefix and then use it for development using the latest libs
> (new web browser?) and collaborate with other mobile Linux'es out there. As
> far as I remember, Wayland was rather old and, maybe, it will preclude Qt
> 5.12 compilation. @mal, th

Re: [SailfishDevel] qt upgrade

[Lukáš Karas]

Hi all

> 
> To sum up, no idea how much we can help with 5.9 transition and what's
> holding it back specifically.
> 

>From the Fosdem discussion, I feel like there is no big technical issue. 
There was message that majority of SFOS core components already has branches 
prepared for Qt 5.9. Issue with transition is licensing - more Qt components 
was switched from LGPLv2.1 license to LGPLv3 [1]. If I understand it 
correctly, LGPLv2 guarantees you as a user that you will get source code for 
the library and you should be able to update library without application 
modification - it allows proprietary applications to link shared Qt 
libraries... But this second right is not mentioned explicitly. It is fixed in 
LGPLv3 that guarantee to user that have to be possible to replace libraries.

This is not problem for SFOS itself, when you can get root access just by one 
click. But for some Jolla partners, that want to create certified devices for 
governments, this right may be a problem. Noone mention specific companies, 
but it is clear that Jolla needs approval from their partners first...

Lukas 

1) https://blog.qt.io/blog/2014/08/20/adding-lgpl-v3-to-qt/


signature.asc
Description: This is a digitally signed message part.
___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org

Re: [SailfishDevel] qt upgrade

[Alexander Akulich]

The keypoints of the build:
- upstream Qt-5.9.6
- Q_OS_SAILFISH platform [1]
- Sailfish Theme added as a plugin instead of direct
QGenericUnixTheme patching [2]
- _qt5_version re-defined in the OBS project config [3] (default value
defined in qt5 macros).
- qt5 macros [4] extended and moved to own repository [5]. The added
macros fix installations conflicts, improve compatibility with fedora
specs and let us flexibly define Qt installation layout from the
outside of qtbase.
- qtchooser-config is built as a part of qtbase.

[1] 
https://git.merproject.org/Kaffeine/qtbase/commit/7b8850fc9df17384a8cf53dc8b1d1e435e806794
[2] 
https://git.merproject.org/Kaffeine/qtbase/commit/816d9f7fe4fac0208d672086ae910cae772dcd32
[3] https://build.merproject.org/project/prjconf/home:Kaffeine:qt:prefix:5.9
[4] 
https://git.merproject.org/mer-core/qtbase/blob/mer-5.6/rpm/macros.qt5-default
[5] https://git.merproject.org/Kaffeine/qt5-rpm-macros/blob/master/macros.qt5

Just try quickcontrols2/gallery and you'll see what's the problem
(maliit keyboard doesn't show up and the window doesn't appear in
lipstick home screen).

On Sun, Feb 10, 2019 at 1:07 PM rinigus  wrote:
>
> Nice work,
>
> so, there is already something similar done. Can't find where do you define 
> _qt_prefix for your SPEC 
> (https://git.merproject.org/Kaffeine/qtbase/blob/sailfish-platform-5.9/rpm/qtbase.spec).
>  There are also bunch of conflicts defined there, no idea whether they 
> interfere.
>
> Which issues did you have with Wayland and keyboard (which of them, maliit or 
> qtvirtualkeyboard?).
>
> @tortoisedoc: Sounds like this upgrade (5.6->5.9) is as much political as it 
> is technical. As for 5.12, I don't know if there are some bugs there that 
> have to be fixed. When using flatpak platform with 5.12, I have issues with 
> QML Audio and some strange scaling of the map (latter could be also my bug in 
> mapbox gl qml plugin). On 5.11, all performed as it was expected. So, either 
> flatpak platform has still some issues at 5.12 or 5.12 itself has some bugs.
>
> To sum up, no idea how much we can help with 5.9 transition and what's 
> holding it back specifically.
>
> Rinigus
>
> On Sun, Feb 10, 2019 at 11:17 AM Alexander Akulich 
>  wrote:
>>
>> Hi,
>>
>> I experimented with a build in prefix in March 2018. I changed MER Qt
>> build configuration to make it trivial to install an arbitrary number
>> of versions simultaneously. I'll make PRs on git.merproject.org once
>> Qt-5.9 support will be merged to master.
>> There are two issues — wayland and virtual keyboard. I posted
>> instruction in Sailfish OS Fan Club group in Telegram, here it is:
>>
>> >// Qt 5.9 for Sailfish OS (installed to /usr/lib/qt5.9 simultaneously to 
>> >the system Qt)
>> >// To install (root or privileged):
>> >ssu ar qt-prefix-5.9 
>> >http://repo.merproject.org/obs/home:/Kaffeine:/qt:/prefix:/5.9/latest_armv7hl
>> >zypper ref qt-prefix-5.9
>> >zypper in qt5.9-qtquickcontrols2-examples qt5.9-qtwayland
>> >
>> >// To remove (root or privileged):
>> >zypper rm qt5.9*
>> >
>> >// To try out (nemo):
>> >QT_SCALE_FACTOR=2 LD_LIBRARY_PATH=/usr/lib/qt5.9/lib 
>> >/usr/lib/qt5.9/examples/quickcontrols2/gallery/gallery
>> >
>> >This is a very first success build, please do not expect much :).
>> >
>> >P.S.: Select Material style in the settings at the right top corner to make 
>> >the demo a bit nicer.
>>
>> I also mostly built Qt-5.11, but it is not an LTS and IMO not as big
>> step forward as 5.9, so I didn't evolve it.
>>
>> On Sat, Feb 9, 2019 at 8:44 PM rinigus  wrote:
>> >
>> > Hi,
>> >
>> > sounds like there are porting and licensing issues on the way of getting 
>> > qt 5.9 for SFOS (see logs from the last #mer-meeting). Its all 
>> > understandable, but it would be great to get a way forward. Not sure 
>> > whether it has been considered by others and I wonder whether we can make 
>> > a separate Qt 5.12 packages for /opt/qt512?
>> >
>> > From a quick test, it is possible to run non-silica applications as well 
>> > (tested with qmlscene and QML with plain Window). In that test, even 
>> > keyboard worked as expected. Look was non-native, but let it be for now.
>> >
>> > So, I wonder, whether its possible to get Qt 5.12 compiled with /opt/qt512 
>> > prefix and then use it for development using the latest libs (new web 
>> > browser?) and collaborate with other mobile Linux'es out there. As far as 
>> > I remember, Wayland was rather old and, maybe, it will preclude Qt 5.12 
>> > compilation. @mal, though, had a newer version around and it may serve a 
>> > purpose for such project. Is there anything else that should be considered?
>> >
>> > Cheers,
>> >
>> > Rinigus
>> >
>> > PS: Please consider it as request-for-comment and not as any kind of 
>> > statement nor call-for-action :)
>> > ___
>> > SailfishOS.org Devel mailing list
>> > To unsubscribe, please send a mail to 
>> > devel-unsubscr...@lists.sailfishos.org
>> _

Re: [SailfishDevel] qt upgrade

[rinigus]

Nice work,

so, there is already something similar done. Can't find where do you define
_qt_prefix for your SPEC (
https://git.merproject.org/Kaffeine/qtbase/blob/sailfish-platform-5.9/rpm/qtbase.spec).
There are also bunch of conflicts defined there, no idea whether they
interfere.

Which issues did you have with Wayland and keyboard (which of them, maliit
or qtvirtualkeyboard?).

@tortoisedoc: Sounds like this upgrade (5.6->5.9) is as much political as
it is technical. As for 5.12, I don't know if there are some bugs there
that have to be fixed. When using flatpak platform with 5.12, I have issues
with QML Audio and some strange scaling of the map (latter could be also my
bug in mapbox gl qml plugin). On 5.11, all performed as it was expected.
So, either flatpak platform has still some issues at 5.12 or 5.12 itself
has some bugs.

To sum up, no idea how much we can help with 5.9 transition and what's
holding it back specifically.

Rinigus

On Sun, Feb 10, 2019 at 11:17 AM Alexander Akulich <
akulichalexan...@gmail.com> wrote:

> Hi,
>
> I experimented with a build in prefix in March 2018. I changed MER Qt
> build configuration to make it trivial to install an arbitrary number
> of versions simultaneously. I'll make PRs on git.merproject.org once
> Qt-5.9 support will be merged to master.
> There are two issues — wayland and virtual keyboard. I posted
> instruction in Sailfish OS Fan Club group in Telegram, here it is:
>
> >// Qt 5.9 for Sailfish OS (installed to /usr/lib/qt5.9 simultaneously to
> the system Qt)
> >// To install (root or privileged):
> >ssu ar qt-prefix-5.9
> http://repo.merproject.org/obs/home:/Kaffeine:/qt:/prefix:/5.9/latest_armv7hl
> >zypper ref qt-prefix-5.9
> >zypper in qt5.9-qtquickcontrols2-examples qt5.9-qtwayland
> >
> >// To remove (root or privileged):
> >zypper rm qt5.9*
> >
> >// To try out (nemo):
> >QT_SCALE_FACTOR=2 LD_LIBRARY_PATH=/usr/lib/qt5.9/lib
> /usr/lib/qt5.9/examples/quickcontrols2/gallery/gallery
> >
> >This is a very first success build, please do not expect much :).
> >
> >P.S.: Select Material style in the settings at the right top corner to
> make the demo a bit nicer.
>
> I also mostly built Qt-5.11, but it is not an LTS and IMO not as big
> step forward as 5.9, so I didn't evolve it.
>
> On Sat, Feb 9, 2019 at 8:44 PM rinigus  wrote:
> >
> > Hi,
> >
> > sounds like there are porting and licensing issues on the way of getting
> qt 5.9 for SFOS (see logs from the last #mer-meeting). Its all
> understandable, but it would be great to get a way forward. Not sure
> whether it has been considered by others and I wonder whether we can make a
> separate Qt 5.12 packages for /opt/qt512?
> >
> > From a quick test, it is possible to run non-silica applications as well
> (tested with qmlscene and QML with plain Window). In that test, even
> keyboard worked as expected. Look was non-native, but let it be for now.
> >
> > So, I wonder, whether its possible to get Qt 5.12 compiled with
> /opt/qt512 prefix and then use it for development using the latest libs
> (new web browser?) and collaborate with other mobile Linux'es out there. As
> far as I remember, Wayland was rather old and, maybe, it will preclude Qt
> 5.12 compilation. @mal, though, had a newer version around and it may serve
> a purpose for such project. Is there anything else that should be
> considered?
> >
> > Cheers,
> >
> > Rinigus
> >
> > PS: Please consider it as request-for-comment and not as any kind of
> statement nor call-for-action :)
> > ___
> > SailfishOS.org Devel mailing list
> > To unsubscribe, please send a mail to
> devel-unsubscr...@lists.sailfishos.org
> ___
> SailfishOS.org Devel mailing list
> To unsubscribe, please send a mail to
> devel-unsubscr...@lists.sailfishos.org
___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org

Re: [SailfishDevel] qt upgrade

[Tone Kastlunger]

How about focussing on the 5.9 -> 5.12 transition instead?
if you start from the work of jolla, you will speed up the process.

tortoisedoc

On Sun, Feb 10, 2019 at 11:17 AM Alexander Akulich <
akulichalexan...@gmail.com> wrote:

> Hi,
>
> I experimented with a build in prefix in March 2018. I changed MER Qt
> build configuration to make it trivial to install an arbitrary number
> of versions simultaneously. I'll make PRs on git.merproject.org once
> Qt-5.9 support will be merged to master.
> There are two issues — wayland and virtual keyboard. I posted
> instruction in Sailfish OS Fan Club group in Telegram, here it is:
>
> >// Qt 5.9 for Sailfish OS (installed to /usr/lib/qt5.9 simultaneously to
> the system Qt)
> >// To install (root or privileged):
> >ssu ar qt-prefix-5.9
> http://repo.merproject.org/obs/home:/Kaffeine:/qt:/prefix:/5.9/latest_armv7hl
> >zypper ref qt-prefix-5.9
> >zypper in qt5.9-qtquickcontrols2-examples qt5.9-qtwayland
> >
> >// To remove (root or privileged):
> >zypper rm qt5.9*
> >
> >// To try out (nemo):
> >QT_SCALE_FACTOR=2 LD_LIBRARY_PATH=/usr/lib/qt5.9/lib
> /usr/lib/qt5.9/examples/quickcontrols2/gallery/gallery
> >
> >This is a very first success build, please do not expect much :).
> >
> >P.S.: Select Material style in the settings at the right top corner to
> make the demo a bit nicer.
>
> I also mostly built Qt-5.11, but it is not an LTS and IMO not as big
> step forward as 5.9, so I didn't evolve it.
>
> On Sat, Feb 9, 2019 at 8:44 PM rinigus  wrote:
> >
> > Hi,
> >
> > sounds like there are porting and licensing issues on the way of getting
> qt 5.9 for SFOS (see logs from the last #mer-meeting). Its all
> understandable, but it would be great to get a way forward. Not sure
> whether it has been considered by others and I wonder whether we can make a
> separate Qt 5.12 packages for /opt/qt512?
> >
> > From a quick test, it is possible to run non-silica applications as well
> (tested with qmlscene and QML with plain Window). In that test, even
> keyboard worked as expected. Look was non-native, but let it be for now.
> >
> > So, I wonder, whether its possible to get Qt 5.12 compiled with
> /opt/qt512 prefix and then use it for development using the latest libs
> (new web browser?) and collaborate with other mobile Linux'es out there. As
> far as I remember, Wayland was rather old and, maybe, it will preclude Qt
> 5.12 compilation. @mal, though, had a newer version around and it may serve
> a purpose for such project. Is there anything else that should be
> considered?
> >
> > Cheers,
> >
> > Rinigus
> >
> > PS: Please consider it as request-for-comment and not as any kind of
> statement nor call-for-action :)
> > ___
> > SailfishOS.org Devel mailing list
> > To unsubscribe, please send a mail to
> devel-unsubscr...@lists.sailfishos.org
> ___
> SailfishOS.org Devel mailing list
> To unsubscribe, please send a mail to
> devel-unsubscr...@lists.sailfishos.org
___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org

Re: [SailfishDevel] qt upgrade

[Alexander Akulich]

Hi,

I experimented with a build in prefix in March 2018. I changed MER Qt
build configuration to make it trivial to install an arbitrary number
of versions simultaneously. I'll make PRs on git.merproject.org once
Qt-5.9 support will be merged to master.
There are two issues — wayland and virtual keyboard. I posted
instruction in Sailfish OS Fan Club group in Telegram, here it is:

>// Qt 5.9 for Sailfish OS (installed to /usr/lib/qt5.9 simultaneously to the 
>system Qt)
>// To install (root or privileged):
>ssu ar qt-prefix-5.9 
>http://repo.merproject.org/obs/home:/Kaffeine:/qt:/prefix:/5.9/latest_armv7hl
>zypper ref qt-prefix-5.9
>zypper in qt5.9-qtquickcontrols2-examples qt5.9-qtwayland
>
>// To remove (root or privileged):
>zypper rm qt5.9*
>
>// To try out (nemo):
>QT_SCALE_FACTOR=2 LD_LIBRARY_PATH=/usr/lib/qt5.9/lib 
>/usr/lib/qt5.9/examples/quickcontrols2/gallery/gallery
>
>This is a very first success build, please do not expect much :).
>
>P.S.: Select Material style in the settings at the right top corner to make 
>the demo a bit nicer.

I also mostly built Qt-5.11, but it is not an LTS and IMO not as big
step forward as 5.9, so I didn't evolve it.

On Sat, Feb 9, 2019 at 8:44 PM rinigus  wrote:
>
> Hi,
>
> sounds like there are porting and licensing issues on the way of getting qt 
> 5.9 for SFOS (see logs from the last #mer-meeting). Its all understandable, 
> but it would be great to get a way forward. Not sure whether it has been 
> considered by others and I wonder whether we can make a separate Qt 5.12 
> packages for /opt/qt512?
>
> From a quick test, it is possible to run non-silica applications as well 
> (tested with qmlscene and QML with plain Window). In that test, even keyboard 
> worked as expected. Look was non-native, but let it be for now.
>
> So, I wonder, whether its possible to get Qt 5.12 compiled with /opt/qt512 
> prefix and then use it for development using the latest libs (new web 
> browser?) and collaborate with other mobile Linux'es out there. As far as I 
> remember, Wayland was rather old and, maybe, it will preclude Qt 5.12 
> compilation. @mal, though, had a newer version around and it may serve a 
> purpose for such project. Is there anything else that should be considered?
>
> Cheers,
>
> Rinigus
>
> PS: Please consider it as request-for-comment and not as any kind of 
> statement nor call-for-action :)
> ___
> SailfishOS.org Devel mailing list
> To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org

Re: [SailfishDevel] qt upgrade

[Lutor, Zoltán]

Hi,

But even if we get 5.9 it will be ages old and getting fixes for “important 
bugs only”...
https://blog.qt.io/blog/2018/02/22/qt-roadmap-2018/

Telling the truth I'm not being familiar with all the details and there must be 
reason not to leapfrog to the latest Qt version in Sailfish but having one old 
version after an other one is not the best. I know 5.9 has its own merits but...

I'm just a hobbist app developer but apps I make tries to be cross-platform - 
and it would be great to use the same features for SFOS and the-rest-of-world - 
in one way or tge other...

Of course, single but up to date Qt version would be “ the qutiest”... ;) 

Br,

Zoltan

On Saturday, February 9, 2019, Leszek Lesner wrote:
> Hi,
> 
> Am Samstag, 9. Februar 2019, 20:11:18 CET schrieb Dylan Van Assche via Devel:
> > Hi,
> >
> > I would really like this! Getting Qt 5.12 on SFOS would be great :) This way
> > we can keep up with the LTS releases of Qt, this would speed up the
> > development of SFOS apps.
> 
> I am against it.
> It would be the opposite actually. Instead of speeding up the development it
> would be like stick you throw inbetween your legs.
> Jolla is barely keeping the Qt Versions up to date for now. Its not going to
> help if we have 2 versions that need to be supported.
> It will create more chaos when some apps will be based on Qt 5.9 and others on
> Qt 5.12
> Also incompatibilities will appear all over the place. Hacks would be needed.
> In general it is not a good idea to split the dev community in a Qt 5.9 and Qt
> 5.12 section.
> Supporting multiple Qt Versions on one platform is a no go. It will break your
> neck.
> 
> Instead I would suggest putting more and more work in quality control and
> having a team that tries to do the best they can for a smooth transition to Qt
> 5.9
> 
> Greetings
> Leszek Lesner
> 
> >
> > Kind regards,
> > Dylan Van Assche
> >
> > Sent from ProtonMail mobile
> >
> >  Original Message 
> >
> > On 9 Feb 2019 18:44, rinigus wrote:
> > > Hi,
> > >
> > > sounds like there are porting and licensing issues on the way of getting
> > > qt 5.9 for SFOS (see logs from the last #mer-meeting). Its all
> > > understandable, but it would be great to get a way forward. Not sure
> > > whether it has been considered by others and I wonder whether we can make
> > > a separate Qt 5.12 packages for /opt/qt512?
> > >
> > > From a quick test, it is possible to run non-silica applications as well
> > > (tested with qmlscene and QML with plain Window). In that test, even
> > > keyboard worked as expected. Look was non-native, but let it be for now.
> > >
> > > So, I wonder, whether its possible to get Qt 5.12 compiled with /opt/qt512
> > > prefix and then use it for development using the latest libs (new web
> > > browser?) and collaborate with other mobile Linux'es out there. As far as
> > > I remember, Wayland was rather old and, maybe, it will preclude Qt 5.12
> > > compilation. @mal, though, had a newer version around and it may serve a
> > > purpose for such project. Is there anything else that should be
> > > considered?
> > >
> > > Cheers,
> > >
> > > Rinigus
> > >
> > > PS: Please consider it as request-for-comment and not as any kind of
> > > statement nor call-for-action :)
> 
> 
> ___
> SailfishOS.org Devel mailing list
> To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.or
___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org