[SailfishDevel] Flatpak for Sailfish

Sun Jan 5 22:18:08 UTC 2020

Good part is that this home-cooked libhybris will live separately from the
main one in your home folder (see
https://github.com/sailfishos-flatpak/flatpak-runner/blob/master/scripts/flatpak-extension-hybris
for script generating it). So, you can experiment while keeping system one
intact.

Rinigus

On Mon, Jan 6, 2020 at 12:10 AM <szopin at gmail.com> wrote:

> I'm probably totally wrong, but you can run all kinds of homecooked
> libhybris versions on a device without needing kernel recompiled, unless
> some specific kernel options are missing?
>
> On Sunday, 5 January 2020, rinigus wrote:
> > Re kernel options: USER_NS is one of them, rest I am not sure as it
> worked
> > immediately for me on Xperia XZ2. As a result, I never looked too deeply
> > into it.
> >
> > Re libhybris: isn't it compiled against device specific droid-hal?
> >
> > Rinigus
> >
> > On Sun, Jan 5, 2020 at 11:37 PM <szopin at gmail.com> wrote:
> >
> > > If it's only in libhybris, then it's not device specific? Which exactly
> > > kernel options need to be turned on for it? Or I'm totally confused
> > >
> > > On Sunday, 5 January 2020, rinigus wrote:
> > > > Hi,
> > > >
> > > > I think that the patch suggested for libhybris is a bugfix. So, I
> hope it
> > > > will be merged and distributed with one of the next SFOS updates.
> > > Assuming
> > > > that Jolla C is still getting updates, you should get it too.
> > > >
> > > > Now, libhybris bug is in the linker, as you can see from my PR. I
> don't
> > > > know how device-specific it is, hopefully knowledgeable porters can
> chip
> > > in
> > > > and comment on it. If its not device specific then we can just
> package
> > > the
> > > > linker and use the rest as it is on device.
> > > >
> > > > Let's see what the next few days bring. I presume many of developers
> are
> > > > back from holidays next week which could speed up the response.
> > > >
> > > > Cheers,
> > > >
> > > > Rinigus
> > > >
> > > >
> > > >
> > > > On Sun, Jan 5, 2020 at 10:52 PM <szopin at gmail.com> wrote:
> > > >
> > > > > It's device specific? Shame, doubt jolla C can help then. Still
> hopeful
> > > > > the eventual cosmo communicator edition will support it. Any hints
> what
> > > > > needs to be enabled in kernel?
> > > > >
> > > > > Thanks in advance,
> > > > > szopin
> > > > >
> > > > > On Sunday, 5 January 2020, rinigus wrote:
> > > > > > Hi,
> > > > > >
> > > > > > I have moved all repositories required for Flatpak support to
> > > > > > https://github.com/sailfishos-flatpak . Documentation is
> available
> > > at
> > > > > > https://github.com/sailfishos-flatpak/main describing how to
> > > install and
> > > > > > develop using this environment. Issues are expected to be filed
> fixed
> > > > > under
> > > > > > https://github.com/sailfishos-flatpak/main and, when
> appropriate,
> > > under
> > > > > > https://github.com/sailfishos-flatpak/flatpak-runner. I tried to
> > > list
> > > > > all
> > > > > > current issues under those repositories.
> > > > > >
> > > > > > I have also opened a thread at TMO (
> > > > > > http://talk.maemo.org/showthread.php?p=1564143) for those who
> prefer
> > > > > that
> > > > > > way of communication.
> > > > > >
> > > > > > Cheers,
> > > > > >
> > > > > > Rinigus
> > > > > >
> > > > > > On Sat, Jan 4, 2020 at 10:22 AM rinigus <rinigus.git at gmail.com>
> > > wrote:
> > > > > >
> > > > > > > Excellent! If something in kernel config is missing, I expect
> that
> > > you
> > > > > > > could use Xperia 10 as a base to check the settings or for
> Xperia
> > > XZ2
> > > > > used
> > > > > > > by me at
> > > > > > >
> > > > >
> > >
> https://github.com/sailfishos-sony-tama/android_kernel_sony_msm/blob/hybris-sony-aosp-9.0.0-4.9-tama-sony/arch/arm64/configs/aosp_tama_akari_defconfig
> > > > > > >
> > > > > > > Rinigus
> > > > > > >
> > > > > > > On Sat, Jan 4, 2020 at 12:47 AM Adam Pigg <adam at piggz.co.uk>
> > > wrote:
> > > > > > >
> > > > > > >> Ill build it on mido and try it out, thanks!
> > > > > > >>
> > > > > > >> On Fri, 3 Jan 2020 at 22:45, rinigus <rinigus.git at gmail.com>
> > > wrote:
> > > > > > >>
> > > > > > >>> Hi,
> > > > > > >>>
> > > > > > >>> I have submitted PR to libhybris allowing to use Flatpak on
> > > hybris
> > > > > > >>> devices with the same version serving its main purpose and
> inside
> > > > > Flatpak
> > > > > > >>> sandbox: https://github.com/libhybris/libhybris/pull/433.
> > > > > > >>>
> > > > > > >>> As soon as your device has such libhybris, you could
> > > > > > >>>
> > > > > > >>> - use
> > > https://build.merproject.org/project/show/home:rinigus:flatpak
> > > > > to
> > > > > > >>> install flatpak, flatpak-runner
> > > > > > >>> - run flatpak-extension-hybris to generate Flatpah hybris
> > > extension
> > > > > at
> > > > > > >>> user nemo's home (run as nemo)
> > > > > > >>> - install flatpak apps, see instructions at Flathub on how
> to do
> > > it
> > > > > > >>> - run them using flatpak-runner
> > > > > > >>>
> > > > > > >>> Many things don't work, but would be faster to get it fixed
> > > together
> > > > > > >>> with other devs.
> > > > > > >>>
> > > > > > >>> Cheers.
> > > > > > >>>
> > > > > > >>> Rinigus
> > > > > > >>>
> > > > > > >>> On Fri, Jan 3, 2020 at 12:18 AM rinigus <
> rinigus.git at gmail.com>
> > > > > wrote:
> > > > > > >>>
> > > > > > >>>> Hi,
> > > > > > >>>>
> > > > > > >>>> just finished the first version of a wrapper for 'flatpak
> run'
> > > > > command
> > > > > > >>>> as well, available at
> https://github.com/rinigus/flatpak-runner
> > > .
> > > > > Its
> > > > > > >>>> based on qxcompositor and it opens new Wayland server before
> > > > > running an
> > > > > > >>>> application, all explained in README. Device rotation is
> > > supported
> > > > > and
> > > > > > >>>> should be followed.
> > > > > > >>>>
> > > > > > >>>> So, as it is:
> > > > > > >>>>
> > > > > > >>>> - we have to resolve libhybris linker issue to make it
> possible
> > > to
> > > > > > >>>> distribute.
> > > > > > >>>> - keyboard is not supported currently. At present, app has
> to
> > > have
> > > > > > >>>> qtvirtualkeyboard support added as in
> > > > > > >>>>
> > > > >
> > >
> https://doc.qt.io/qt-5/qtvirtualkeyboard-deployment-guide.html#creating-inputpanel
> > > > > > >>>> .
> > > > > > >>>> - only single-window apps are working well, such as QML
> > > developed
> > > > > for
> > > > > > >>>> mobile
> > > > > > >>>> - no sound so far
> > > > > > >>>> - probably many other things are missing, haven't bumped
> into
> > > them.
> > > > > > >>>>
> > > > > > >>>> Essentially, we will have access to the latest Qt, but would
> > > have to
> > > > > > >>>> write apps for this use. Fortunately, it all goes along SFOS
> > > > > programming
> > > > > > >>>> and should be simple to convert later to Silica, when/if it
> > > catches
> > > > > up with
> > > > > > >>>> Qt versions.
> > > > > > >>>>
> > > > > > >>>> I guess we can get better integration after it will be
> simple to
> > > > > > >>>> install on other devices and start using it by others.
> > > > > > >>>>
> > > > > > >>>> Cheers,
> > > > > > >>>>
> > > > > > >>>> Rinigus
> > > > > > >>>>
> > > > > > >>>> On Wed, Jan 1, 2020 at 5:25 PM rinigus <
> rinigus.git at gmail.com>
> > > > > wrote:
> > > > > > >>>>
> > > > > > >>>>> Hi,
> > > > > > >>>>>
> > > > > > >>>>> wait a bit, I may have a way to simplify setup. Few days
> ago,
> > > after
> > > > > > >>>>> discussion on IRC, I found a way around disappearance of
> the
> > > > > window when
> > > > > > >>>>> wrapped into qxcomposer. So, that blocker is over now.
> Which
> > > means
> > > > > that we
> > > > > > >>>>> will be able to craft apps using the latest Qt available in
> > > > > Flatpaks.
> > > > > > >>>>>
> > > > > > >>>>> Currently, I am looking into
> > > > > > >>>>>
> > > > > > >>>>> - how we can use regular hybris
> > > > > > >>>>> - making a wrapper similar to qxcomposer for Flatpaks.
> > > > > > >>>>>
> > > > > > >>>>> Shouldn't take too long for an update on status.
> > > > > > >>>>>
> > > > > > >>>>> Cheers,
> > > > > > >>>>>
> > > > > > >>>>> Rinigus
> > > > > > >>>>>
> > > > > > >>>>> On Wed, Jan 1, 2020 at 4:55 PM <szopin at gmail.com> wrote:
> > > > > > >>>>>
> > > > > > >>>>>> Could you elaborate on:
> > > > > > >>>>>> > libhybris compiled with specification of default
> > > > > > >>>>>> hybris-ld-library-path,
> > > > > > >>>>>> > content of libexec/droid-hybris added with GL extension.
> > > > > > >>>>>> Is that libhybris build available (and safe to run on main
> > > > > device, or
> > > > > > >>>>>> should I dig out my j1)?
> > > > > > >>>>>> Also not sure what added with GL extension means? Having a
> > > browser
> > > > > > >>>>>> that uses up to date webengine would be awesome.
> > > > > > >>>>>>
> > > > > > >>>>>> Thanks and happy new year!
> > > > > > >>>>>> szopin
> > > > > > >>>>>>
> > > > > > >>>>>> On Sunday, 29 December 2019, rinigus wrote:
> > > > > > >>>>>> > Hi,
> > > > > > >>>>>> >
> > > > > > >>>>>> > I would have preferred to stay away from discussion on
> why
> > > do we
> > > > > > >>>>>> need/not
> > > > > > >>>>>> > need Flatpak on SFOS. But I guess I have to take it as
> the
> > > one
> > > > > > >>>>>> working on
> > > > > > >>>>>> > making it possible.
> > > > > > >>>>>> >
> > > > > > >>>>>> > Native apps rely on the libs allowed in the Store and
> > > bundle the
> > > > > > >>>>>> rest of
> > > > > > >>>>>> > them. I presume OSM Scout Server and Pure Maps are
> > > exceptions,
> > > > > but
> > > > > > >>>>>> they are
> > > > > > >>>>>> > built around almost 20 libs bundled with the
> application and
> > > > > > >>>>>> compiled with
> > > > > > >>>>>> > newer gcc than the one on the platform. If I would have
> > > > > continued to
> > > > > > >>>>>> > provide OSM Scout Server via the official Store, I'd
> have to
> > > > > bundle
> > > > > > >>>>>> > libsystemd as well - something that I found was
> crossing a
> > > line
> > > > > for
> > > > > > >>>>>> me. So,
> > > > > > >>>>>> > any security issue in those bundled libs would be
> > > propagated the
> > > > > > >>>>>> same way
> > > > > > >>>>>> > as with the Flatpak. I admit that its way less libs than
> > > > > > >>>>>> distributed via
> > > > > > >>>>>> > Flatpak. However, in the case of Flatpak, apps are
> provided
> > > on
> > > > > the
> > > > > > >>>>>> top of
> > > > > > >>>>>> > "runtimes" with the app including everything which is
> > > extending
> > > > > the
> > > > > > >>>>>> runtime
> > > > > > >>>>>> > to make it work. So, in case of OSM Scout Server and
> Pure
> > > Maps,
> > > > > > >>>>>> their
> > > > > > >>>>>> > Flatpaks do include some libs as well. Those runtimes
> are
> > > > > updated.
> > > > > > >>>>>> Now, I
> > > > > > >>>>>> > am not in position to say whether its security updates
> are
> > > as
> > > > > fast
> > > > > > >>>>>> as of
> > > > > > >>>>>> > distros and have no idea how it compares to SFOS.
> > > > > > >>>>>> >
> > > > > > >>>>>> > However, I see mainly portability and up-to-date toolbox
> > > aspect
> > > > > of
> > > > > > >>>>>> Flatpak,
> > > > > > >>>>>> > not that much security in terms of sandbox. These are my
> > > > > > >>>>>> preferences and
> > > > > > >>>>>> > they could differ from yours.
> > > > > > >>>>>> >
> > > > > > >>>>>> > Looking at the speed of upcoming Qt update, I was
> > > considering
> > > > > > >>>>>> whether to
> > > > > > >>>>>> > make qt5.12 (or later) in /opt (/home/opt) and use it
> from
> > > > > there to
> > > > > > >>>>>> allow
> > > > > > >>>>>> > us to work on newer browser engine or make Flatpak
> > > available.
> > > > > The
> > > > > > >>>>>> both
> > > > > > >>>>>> > solutions would break look-and-feel of SFOS, but allow
> us
> > > to use
> > > > > > >>>>>> current
> > > > > > >>>>>> > libs, something that we have been missing for too long.
> > > And, in
> > > > > many
> > > > > > >>>>>> > aspects, we, as developers, waste lot of time to fight
> > > against.
> > > > > I
> > > > > > >>>>>> swayed
> > > > > > >>>>>> > towards Flatpaks as it has well developed tools around
> it,
> > > > > provides
> > > > > > >>>>>> > portability (you can run it on desktop), and will make
> > > sense to
> > > > > > >>>>>> have when
> > > > > > >>>>>> > other mobile Linux distros will start going as a way to
> use
> > > the
> > > > > > >>>>>> same app at
> > > > > > >>>>>> > all of them.
> > > > > > >>>>>> >
> > > > > > >>>>>> > Note that is we develop apps immediately with the
> > > reservation
> > > > > that
> > > > > > >>>>>> we could
> > > > > > >>>>>> > switch to a native version as soon as it is ready to
> > > receive it
> > > > > (in
> > > > > > >>>>>> terms
> > > > > > >>>>>> > of Qt version, for example), we can start working on
> things
> > > > > that are
> > > > > > >>>>>> > impossible right now on SFOS but may become available
> later
> > > (Qt
> > > > > > >>>>>> 5.12?). I
> > > > > > >>>>>> > would expect that this much better than using Android
> > > browser on
> > > > > > >>>>>> SFOS.
> > > > > > >>>>>> >
> > > > > > >>>>>> > Please note that it is not to criticize Jolla regarding
> the
> > > > > update
> > > > > > >>>>>> speed of
> > > > > > >>>>>> > Qt. Its probably a complex process and, as we have all
> built
> > > > > around
> > > > > > >>>>>> it, may
> > > > > > >>>>>> > break few things to put it mildly. But a large part of
> my
> > > work
> > > > > as a
> > > > > > >>>>>> > developer on SFOS is around incompatibilities imposed
> by old
> > > > > libs
> > > > > > >>>>>> and gcc.
> > > > > > >>>>>> > So, from developer POV, its important to prioritize Qt
> > > update as
> > > > > > >>>>>> much as
> > > > > > >>>>>> > possible. Not sure how much we can help with it, but
> that's
> > > > > probably
> > > > > > >>>>>> > separate discussion (please start it if you wish).
> > > > > > >>>>>> >
> > > > > > >>>>>> > Sorry for long post, please see my previous ones on
> > > technical
> > > > > > >>>>>> issues that
> > > > > > >>>>>> > we currently face.
> > > > > > >>>>>> >
> > > > > > >>>>>> > As for latest state:
> > > > > > >>>>>> >
> > > > > > >>>>>> > Test browser that I can run is executed with:
> > > > > > >>>>>> >
> > > > > > >>>>>> > QT_WAYLAND_FORCE_DPI=physical flatpak run
> --filesystem=host
> > > > > > >>>>>> --device=all
> > > > > > >>>>>> >
> > > > > > >>>>>>
> > > > >
> > >
> --env=HYBRIS_EGLPLATFORM_DIR=/usr/lib/arm-linux-gnueabihf/GL/default/lib/libhybris
> > > > > > >>>>>> >
> > > > > > >>>>>>
> > > > >
> > >
> --env=HYBRIS_LINKER_DIR=/usr/lib/arm-linux-gnueabihf/GL/default/lib/libhybris/linker
> > > > > > >>>>>> > org.qutebrowser.qutebrowser together.jolla.com
> > > > > > >>>>>> >
> > > > > > >>>>>> > libhybris compiled with specification of default
> > > > > > >>>>>> hybris-ld-library-path,
> > > > > > >>>>>> > content of libexec/droid-hybris added with GL extension.
> > > > > > >>>>>> >
> > > > > > >>>>>> > Cheers,
> > > > > > >>>>>> >
> > > > > > >>>>>> > Rinigus
> > > > > > >>>>>> >
> > > > > > >>>>>> >
> > > > > > >>>>>> >
> > > > > > >>>>>> > On Sun, Dec 29, 2019 at 9:26 PM E.S. Rosenberg <
> > > > > > >>>>>> > es.rosenberg+sailfishos.org at gmail.com> wrote:
> > > > > > >>>>>> >
> > > > > > >>>>>> > > Native apps rely on the libs shipped with the OS, thus
> > > they
> > > > > don't
> > > > > > >>>>>> ship
> > > > > > >>>>>> > > with unsecure libs unless Jolla is shipping them and
> they
> > > > > become
> > > > > > >>>>>> secure the
> > > > > > >>>>>> > > moment Jolla updated the libs (and should the update
> break
> > > > > binary
> > > > > > >>>>>> > > compatibility will require a new release compiled
> against
> > > the
> > > > > new
> > > > > > >>>>>> libs).
> > > > > > >>>>>> > > Flatpacks and snaps are security nightmares, instead
> of
> > > > > getting
> > > > > > >>>>>> them lets
> > > > > > >>>>>> > > work on moving the SFOS platform along.
> > > > > > >>>>>> > >
> > > > > > >>>>>> > > Op zo 29 dec. 2019 om 20:41 schreef rinigus <
> > > > > > >>>>>> rinigus.git at gmail.com>:
> > > > > > >>>>>> > >
> > > > > > >>>>>> > >> Hi,
> > > > > > >>>>>> > >>
> > > > > > >>>>>> > >> If you refer to http://flatkill.org/ , it does have
> lot
> > > of
> > > > > good
> > > > > > >>>>>> points.
> > > > > > >>>>>> > >> In this respect, its similar to what we have with the
> > > native
> > > > > > >>>>>> apps, as soon
> > > > > > >>>>>> > >> as some security flaws are used. At the moment, I
> would
> > > > > prefer
> > > > > > >>>>>> to get
> > > > > > >>>>>> > >> access to the latest Qt and other recent software.
> But
> > > users
> > > > > are
> > > > > > >>>>>> still
> > > > > > >>>>>> > >> responsible for thinking before installing, as they
> are
> > > now.
> > > > > > >>>>>> Note that in
> > > > > > >>>>>> > >> many aspects our current packaging together with
> bundled
> > > > > libs is
> > > > > > >>>>>> similar to
> > > > > > >>>>>> > >> flatpak already. So, why not to make it with the
> recent
> > > libs
> > > > > as
> > > > > > >>>>>> well?
> > > > > > >>>>>> > >>
> > > > > > >>>>>> > >> Cheers,
> > > > > > >>>>>> > >>
> > > > > > >>>>>> > >> Rinigus
> > > > > > >>>>>> > >>
> > > > > > >>>>>> > >>
> > > > > > >>>>>> > >> On Sun, Dec 29, 2019 at 8:26 PM E.S. Rosenberg <
> > > > > > >>>>>> > >> es.rosenberg+sailfishos.org at gmail.com> wrote:
> > > > > > >>>>>> > >>
> > > > > > >>>>>> > >>> No one is bothered by the serious (bad) security
> > > > > implications
> > > > > > >>>>>> of running
> > > > > > >>>>>> > >>> flatpacks?
> > > > > > >>>>>> > >>> Though I guess we are all tolerating the claim to
> > > > > "security" on
> > > > > > >>>>>> ancient
> > > > > > >>>>>> > >>> kernels so we have no right to blab about security
> now
> > > 🤔
> > > > > > >>>>>> > >>>
> > > > > > >>>>>> > >>> Op za 28 dec. 2019 om 12:04 schreef rinigus <
> > > > > > >>>>>> rinigus.git at gmail.com>:
> > > > > > >>>>>> > >>>
> > > > > > >>>>>> > >>>> Hi,
> > > > > > >>>>>> > >>>>
> > > > > > >>>>>> > >>>> I am not 100% sure whether xdg-shell availability
> is
> > > the
> > > > > > >>>>>> blocker. There
> > > > > > >>>>>> > >>>> is something going on which I cannot explain yet -
> its
> > > as
> > > > > if
> > > > > > >>>>>> Wayland
> > > > > > >>>>>> > >>>> rendering disappears even when I use qxcomposer.
> > > > > > >>>>>> > >>>>
> > > > > > >>>>>> > >>>> qxcomposer does allow me to minimize and then
> restore.
> > > > > > >>>>>> However, when
> > > > > > >>>>>> > >>>> keeping app minimized and switching to other apps,
> I
> > > do get
> > > > > > >>>>>> (with
> > > > > > >>>>>> > >>>> WAYLAND_DEBUG=1)
> > > > > > >>>>>> > >>>>
> > > > > > >>>>>> > >>>> [2294832.935] wl_pointer at 8.motion(207667,
> 0.000000,
> > > > > 0.000000)
> > > > > > >>>>>> > >>>> [2299966.213]
> > > qt_extended_surface at 29.onscreen_visibility
> > > > > (1)
> > > > > > >>>>>> > >>>> [2303645.301]
> > > qt_extended_surface at 29.onscreen_visibility
> > > > > (0)
> > > > > > >>>>>> > >>>> [2303647.486]  -> wl_surface at 26.destroy()
> > > > > > >>>>>> > >>>> [2303648.296]  -> wl_buffer at 4278190080.destroy()
> > > > > > >>>>>> > >>>> [2303648.395]  -> wl_buffer at 4278190082.destroy()
> > > > > > >>>>>> > >>>> [2303648.448]  -> wl_buffer at 4278190081.destroy()
> > > > > > >>>>>> > >>>>
> > > > > > >>>>>> > >>>> and the app window disappears from qxcomposer.
> > > > > > >>>>>> > >>>>
> > > > > > >>>>>> > >>>> Same happens when running directly using SFOS
> composer:
> > > > > > >>>>>> > >>>>
> > > > > > >>>>>> > >>>> [2614530.331]
> > > qt_extended_surface at 29.onscreen_visibility
> > > > > (0)
> > > > > > >>>>>> > >>>> [2614552.802]  -> wl_surface at 26.destroy()
> > > > > > >>>>>> > >>>> [2614555.653]  -> wl_buffer at 4278190080.destroy()
> > > > > > >>>>>> > >>>> [2614556.795]  -> wl_buffer at 4278190082.destroy()
> > > > > > >>>>>> > >>>> [2614557.099]  -> wl_buffer at 4278190081.destroy()
> > > > > > >>>>>> > >>>>
> > > > > > >>>>>> > >>>> So, looks like the surface gets destroyed, but
> nothing
> > > > > really
> > > > > > >>>>>> restores
> > > > > > >>>>>> > >>>> it.
> > > > > > >>>>>> > >>>>
> > > > > > >>>>>> > >>>> As such, some kind of wrapper, similar to
> qxcomposer,
> > > > > around
> > > > > > >>>>>> Flatpak
> > > > > > >>>>>> > >>>> programs maybe handy. It could take few tasks,
> such as
> > > > > > >>>>>> > >>>>
> > > > > > >>>>>> > >>>> - follow orientation of the screen
> > > > > > >>>>>> > >>>> - restore app after wl_buffer.destroy()
> > > > > > >>>>>> > >>>> - provide keyboard support
> > > > > > >>>>>> > >>>>
> > > > > > >>>>>> > >>>> I don't know enough about Wayland to be efficient
> in
> > > > > working
> > > > > > >>>>>> on it. So,
> > > > > > >>>>>> > >>>> I wonder if someone would like to step in and help
> with
> > > > > this
> > > > > > >>>>>> part. If there
> > > > > > >>>>>> > >>>> is interest, I will work on packaging libhybris
> > > extension
> > > > > and
> > > > > > >>>>>> provide an
> > > > > > >>>>>> > >>>> example at OBS for Xperia Tama devices.
> > > > > > >>>>>> > >>>>
> > > > > > >>>>>> > >>>> Cheers,
> > > > > > >>>>>> > >>>>
> > > > > > >>>>>> > >>>> Rinigus
> > > > > > >>>>>> > >>>>
> > > > > > >>>>>> > >>>> On Sat, Dec 28, 2019 at 12:54 AM Damien Caliste <
> > > > > > >>>>>> dcaliste at free.fr>
> > > > > > >>>>>> > >>>> wrote:
> > > > > > >>>>>> > >>>>
> > > > > > >>>>>> > >>>>> Thank you Rinigus for all of this. Indeed, the
> current
> > > > > main
> > > > > > >>>>>> blocker
> > > > > > >>>>>> > >>>>> seems to be the fact that xdg-shell is not
> available
> > > in
> > > > > > >>>>>> Lipstick. This is
> > > > > > >>>>>> > >>>>> linked to the ancient version of QtWayland, even
> not
> > > 5.6,
> > > > > but
> > > > > > >>>>>> still 5.4 !
> > > > > > >>>>>> > >>>>> They already have a 5.9 branch in SailfishOS git (
> > > > > > >>>>>> > >>>>>
> > > > > https://git.sailfishos.org/mer-core/qtwayland/tree/mer-5.9),
> > > > > > >>>>>> but we
> > > > > > >>>>>> > >>>>> need to wait for Jolla to make the Qt switch. I
> don't
> > > > > think
> > > > > > >>>>>> it's something
> > > > > > >>>>>> > >>>>> community can change on device... I hope I can be
> > > proven
> > > > > > >>>>>> wrong though.
> > > > > > >>>>>> > >>>>>
> > > > > > >>>>>> > >>>>> Damien.
> > > > > > >>>>>> > >>>>> _______________________________________________
> > > > > > >>>>>> > >>>>> SailfishOS.org Devel mailing list
> > > > > > >>>>>> > >>>>> To unsubscribe, please send a mail to
> > > > > > >>>>>> > >>>>> devel-unsubscribe at lists.sailfishos.org
> > > > > > >>>>>> > >>>>
> > > > > > >>>>>> > >>>> _______________________________________________
> > > > > > >>>>>> > >>>> SailfishOS.org Devel mailing list
> > > > > > >>>>>> > >>>> To unsubscribe, please send a mail to
> > > > > > >>>>>> > >>>> devel-unsubscribe at lists.sailfishos.org
> > > > > > >>>>>> > >>>
> > > > > > >>>>>> > >>> _______________________________________________
> > > > > > >>>>>> > >>> SailfishOS.org Devel mailing list
> > > > > > >>>>>> > >>> To unsubscribe, please send a mail to
> > > > > > >>>>>> > >>> devel-unsubscribe at lists.sailfishos.org
> > > > > > >>>>>> > >>
> > > > > > >>>>>> > >> _______________________________________________
> > > > > > >>>>>> > >> SailfishOS.org Devel mailing list
> > > > > > >>>>>> > >> To unsubscribe, please send a mail to
> > > > > > >>>>>> > >> devel-unsubscribe at lists.sailfishos.org
> > > > > > >>>>>> > >
> > > > > > >>>>>> > > _______________________________________________
> > > > > > >>>>>> > > SailfishOS.org Devel mailing list
> > > > > > >>>>>> > > To unsubscribe, please send a mail to
> > > > > > >>>>>> > > devel-unsubscribe at lists.sailfishos.org
> > > > > > >>>>>> >
> > > > > > >>>>>>
> > > > > > >>>>>> --
> > > > > > >>>>>> Sent from my Jolla
> > > > > > >>>>>> _______________________________________________
> > > > > > >>>>>> SailfishOS.org Devel mailing list
> > > > > > >>>>>> To unsubscribe, please send a mail to
> > > > > > >>>>>> devel-unsubscribe at lists.sailfishos.org
> > > > > > >>>>>
> > > > > > >>>>> _______________________________________________
> > > > > > >>> SailfishOS.org Devel mailing list
> > > > > > >>> To unsubscribe, please send a mail to
> > > > > > >>> devel-unsubscribe at lists.sailfishos.org
> > > > > > >>
> > > > > > >> _______________________________________________
> > > > > > >> SailfishOS.org Devel mailing list
> > > > > > >> To unsubscribe, please send a mail to
> > > > > > >> devel-unsubscribe at lists.sailfishos.org
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > > --
> > > > > Sent from my Jolla
> > > > > _______________________________________________
> > > > > SailfishOS.org Devel mailing list
> > > > > To unsubscribe, please send a mail to
> > > > > devel-unsubscribe at lists.sailfishos.org
> > > >
> > >
> > > --
> > > Sent from my Jolla
> > > _______________________________________________
> > > SailfishOS.org Devel mailing list
> > > To unsubscribe, please send a mail to
> > > devel-unsubscribe at lists.sailfishos.org
> >
>
> --
> Sent from my Jolla
> _______________________________________________
> SailfishOS.org Devel mailing list
> To unsubscribe, please send a mail to
> devel-unsubscribe at lists.sailfishos.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.sailfishos.org/pipermail/devel/attachments/20200106/7771176e/attachment-0001.html>