Ill build it on mido and try it out, thanks! On Fri, 3 Jan 2020 at 22:45, rinigus <rinigus....@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....@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
_______________________________________________ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
