[SailfishDevel] Flatpak for Sailfish

rinigus rinigus.git at gmail.com
Sat Jan 11 14:52:36 UTC 2020


I finished the first version of support for Maliit keyboard in Qt apps
inside Flatpak. It required, in the end, separate communication channel via
dbus p2p between maliit plugin inside Flatpak container and Sailfish host
(flatpak-runner) to assist the plugin by providing info regarding screen
rotation and active state of the app. Code is in Github project
(maliit-framework and flatpak-runner). I have also added small example on
how to package Flatpak app using it under
https://github.com/sailfishos-flatpak/example-apps .

Now would have to figure out how to avoid the separate packaging and
implant maliit plugin into Flatpak container.



On Thu, Jan 9, 2020 at 9:11 AM rinigus <rinigus.git at gmail.com> wrote:

> Morning,
> I've got SFOS keyboard triggered from Flatpak app by planting in Maliit
> input context plugin into it. Had to drop compensation for keyboard
> rectangle inside Flatpak as it was compensated twice (once in SFOS and once
> in Flatpak) leading to large empty area above the keyboard.
> Currently, keyboard is stuck in portrait mode and doesn't know much about
> app being minimized. As a result, while app is rotating in response to the
> screen rotation, keyboard gets stuck in portrait. In addition, if you open
> keyboard in Flatpak, minimize the app, move to some other SFOS app, you'll
> get open keyboard with the text prediction still pointing towards Flatpak
> app context. This is not surprising as orientation and focus are set by the
> plugin and it just doesn't have data to work with. So, I plan to write
> small dbus server/client to pass these data from flatpak-runner (host of
> flatpak apps) to Maliit plugin. In the end, we will have special version of
> the plugin oriented towards running inside Flatpaks, but that should be OK.
> Tried last night to pass orientation by setting Wayland's server
> setScreenOrientation (
> https://git.sailfishos.org/mer-core/qtwayland/blob/master/src/compositor/compositor_api/waylandcompositor.h#L96),
> but that didn't help and the plugin was not getting any signals from
> qGuiApp->primaryScreen. So, that shortcut didn't work...
> All in all, we are getting there.
> Cheers,
> Rinigus
> On Tue, Jan 7, 2020 at 12:03 PM rinigus <rinigus.git at gmail.com> wrote:
>> Thanks! Let's see how it will work in practice. I'll report back
>> after the tests.
>> Rinigus
>> On Tue, Jan 7, 2020 at 11:59 AM Pekka Vuorela <pekka.vuorela at jolla.com>
>> wrote:
>>> On Tue, 2020-01-07 at 11:42 +0200, rinigus wrote:
>>> > Pekka,
>>> >
>>> > thanks for the swift reply!
>>> >
>>> >
>>> > > > - is SFOS keyboard drawn by Lipstick?
>>> > >
>>> > > Keyboard running in its own process, maliit-server.
>>> >
>>> > But something is drawing it on the screen via QML. Is that the server
>>> > and Lipstick just making space for it? If it is then that would fit
>>> > with such separation perfectly.
>>> Maliit-server acts as a host for input plugins, and Jolla-keyboard
>>> implements such and has the qml parts. The content is drawn in a
>>> separate window, and Lipstick handles the window composition.
>>> Maliit passes the used keyboard area to application via the qt input
>>> plugin so the app knows which area to avoid for active content, and
>>> maliit also sets the window properties so Lipstick knows which area of
>>> the window should get mouse events.
>>> _______________________________________________
>>> 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/20200111/69d4551b/attachment.html>

More information about the Devel mailing list