On Mon, Mar 23, 2020 at 11:51 PM Tone Kastlunger
wrote:
> Obvious things first: timers are whako?
>
>
Morning,
and how would I test that?
Rinigus
___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to
Obvious things first: timers are whako?
On Sat, Feb 22, 2020 at 5:11 PM rinigus wrote:
> Hi,
>
> I would like to ask for help regarding animation rendering from hybris/qt
> gurus. In Flatpak apps, when running QT animation, such as spinning busy
> indicator, I am getting general slow down of
Hi,
I would like to ask for help regarding animation rendering from hybris/qt
gurus. In Flatpak apps, when running QT animation, such as spinning busy
indicator, I am getting general slow down of the applications. Slowdown can
be felt by trying to pull drawers, slower web pages download, and
Hi,
just one more comment - I would expect Lipstick to follow the specified
standards. When we have an option to specify `X-Nemo-Single-Instance=no`,
it should be respected. Especially, when the fix is known and involves
one-liner. Turned out that there is an old issue filed regarding it at
Hi,
sounds a bit like over-engineering, but maybe dbus service will be needed
unless we can utilize Lipstick handling of the windows.
Cheers,
Rinigus
On Tue, Jan 28, 2020 at 3:38 PM Андрей Кожевников
wrote:
> what if you try to remove Exec from desktop file and will handle launch
> only via
what if you try to remove Exec from desktop file and will handle launch
only via dbus service? single dbus service will start applications.
вт, 28 янв. 2020 г. в 01:11, Dietmar Schwertberger <
maill...@schwertberger.de>:
> Hi!
>
> Single instance handling has always been broken for Sailfish OS
Hi!
Single instance handling has always been broken for Sailfish OS 3.
Not even different .desktop files with different Exec entries like these
are working, as they are probably both interpreted as "python3":
|Exec=python3 /path/to/application/app1.py |
||Exec=python3
Hi,
I am currently having issues with running multiple flatpak applications
under Lipstick. Flatpak apps are started through a wrapper - flatpak-runner
which has multiple functions
* provide wayland compositor for flatpak app
* set its environment to ensure that libhybris gl is used
* forward
Hi,
as the holidays are over, I wonder if someone could look into libhybris
patch https://github.com/libhybris/libhybris/pull/433 .
As for keyboard support in Flatpak applications, I will ask for adding it
as an extension for KDE runtime. For now, we have ugly solution with Maliit
plugin for
Hi,
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
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,
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
wrote:
> On Tue, 2020-01-07 at 11:42 +0200, rinigus wrote:
> > Pekka,
> >
> > thanks for the swift reply!
> >
> >
> > > > - is SFOS keyboard drawn by
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
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
On Tue, 2020-01-07 at 09:30 +0200, rinigus wrote:
> I am working on adding Maliit into Flatpak sandbox. Idea is to use
> Maliit plugin on Flatpak side and via DBus communicate with SFOS
> keyboard. However, I make few assumptions and would be like to get
> some background info:
>
> - is SFOS
I am working on adding Maliit into Flatpak sandbox. Idea is to use Maliit
plugin on Flatpak side and via DBus communicate with SFOS keyboard.
However, I make few assumptions and would be like to get some background
info:
- is SFOS keyboard drawn by Lipstick?
- does communication between app and
Exactly, something like that is needed. Ideally, it would be hooked via
Wayland (input extension?) and trigger the keyboard on focusing on any text
field. But I will be happy with Qt only solution as well. Any tips on how
to make it possible?
Rinigus
On Mon, Jan 6, 2020 at 10:51 AM Андрей
Android side is using "remote keyboard" to show sailfish keyboard on top of
Android
пн, 6 янв. 2020 г., 9:52 rinigus :
> Morning!
>
> Re compositor issue: that has been worked around by having
> compositor-in-compositor. In theory, but I didn't look too much more than a
> day into it, we could
Morning!
Re compositor issue: that has been worked around by having
compositor-in-compositor. In theory, but I didn't look too much more than a
day into it, we could have headless compositor rendered on gles widget
which could be rather current, with all protocols supported. I mainly
bailed out
Hi all and thank you for working on this.
Back in 2018 I had Qt 5.9 and Qt 5.11 builds for SFOS (they are not
available anymore because of changes in OBS repos), but the builds
were not usable because the of the same issues — wayland and virtual
keyboard. As far as I understood, a compositor with
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
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
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 wrote:
> If it's only in
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
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
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
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
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
Ill build it on mido and try it out, thanks!
On Fri, 3 Jan 2020 at 22:45, rinigus 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:
>
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
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
Re simplification:
To get hybris libs supported, we need to give them through host GL
extension. Now, we can mount many filesystems readonly, such as /system and
/vendor, as needed. However, /usr is blacklisted and provided via Flatpak
runtime with host /usr mounted under /var/run/host/usr. So,
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.
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
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
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
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
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 :
> Hi,
>
> I am not 100% sure whether
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
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
If you can provide a basic.qml for a portal for x, pretty sure tons of people
will be able to help with portals for y (still no idea how that would work with
the whole virtualization, but hopefully only you need to do the hard carry and
rest can help with the localization/copy pasting stuff)
Yes, pretty much GUI allowing access to files and other sandboxed
functions. See https://github.com/flatpak/flatpak/wiki/Portals
Rinigus
On Fri, Dec 27, 2019 at 9:43 PM wrote:
> 'writing portals' would mean? Like qml files to handle i/o?
>
>
> On Friday, 27 December 2019, rinigus wrote:
> >
'writing portals' would mean? Like qml files to handle i/o?
On Friday, 27 December 2019, rinigus wrote:
> That was exactly the thought behind it. There will be work to do, such as
> writing portals, but we need to get compositor issue fixed first. Or use
> some separate one...
>
> Rinigus
>
>
That was exactly the thought behind it. There will be work to do, such as
writing portals, but we need to get compositor issue fixed first. Or use
some separate one...
Rinigus
On Fri, Dec 27, 2019 at 9:17 PM wrote:
> This is amazing, if there is something I can do to help please let me
> know,
This is amazing, if there is something I can do to help please let me know, not
being tied to os version of qt is awesome, we could maybe get a proper browser
with this? Hope leszek is on the list
On Friday, 27 December 2019, rinigus wrote:
> I have a breakthrough. Had to compile libhybris
I have a breakthrough. Had to compile libhybris with
--with-default-hybris-ld-library-path=/usr/lib/arm-linux-gnueabihf/GL/default/libexec/droid-hybris/system/lib:/vendor/lib:/system/lib:/odm/lib
and enable "--filesystem=host --device=all" in "flatpak run". As a result,
I have some Qt flatpak
>From comparing logs of normal apps and the app in Flatpak sasndbox, looks
like sandboxed app does not find /usr/libexec/droid-hybris. Is there a way
to let it search under
>
/usr/lib/arm-linux-gnueabihf/GL/default/libexec/droid-hybris
instead? Any env variable to tune? Seems like
Hi,
I have been working on getting Flatpak on Sailfish device. It doesn't work
yet, but let me give a short overview of the status.
Why: Flatpak would allow us to get latest Qt base, 5.12 and 5.13 are
available already. There are other advantages, as collaboration between
Linux mobile
48 matches
Mail list logo
