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....@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....@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 <szo...@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....@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....@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....@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....@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@8.motion(207667, 0.000000, 0.000000) >>> > >>>> [2299966.213] qt_extended_surface@29.onscreen_visibility(1) >>> > >>>> [2303645.301] qt_extended_surface@29.onscreen_visibility(0) >>> > >>>> [2303647.486] -> wl_surface@26.destroy() >>> > >>>> [2303648.296] -> wl_buffer@4278190080.destroy() >>> > >>>> [2303648.395] -> wl_buffer@4278190082.destroy() >>> > >>>> [2303648.448] -> wl_buffer@4278190081.destroy() >>> > >>>> >>> > >>>> and the app window disappears from qxcomposer. >>> > >>>> >>> > >>>> Same happens when running directly using SFOS composer: >>> > >>>> >>> > >>>> [2614530.331] qt_extended_surface@29.onscreen_visibility(0) >>> > >>>> [2614552.802] -> wl_surface@26.destroy() >>> > >>>> [2614555.653] -> wl_buffer@4278190080.destroy() >>> > >>>> [2614556.795] -> wl_buffer@4278190082.destroy() >>> > >>>> [2614557.099] -> wl_buffer@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 <dcali...@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-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 >>> > > >>> > > _______________________________________________ >>> > > SailfishOS.org Devel mailing list >>> > > To unsubscribe, please send a mail to >>> > > devel-unsubscr...@lists.sailfishos.org >>> > >>> >>> -- >>> Sent from my Jolla >>> _______________________________________________ >>> 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
