#sailfishos-meeting: Sailfish OS, open source, collaboration -- 15th October 2020
Meeting started by sledges at 07:00:00 UTC
(full logs).
Meeting summary
-
- Meeting information and agenda can be found
here: (sledges,
07:00:11)
- https://forum.sailfishos.org/t/community-meeting-on-irc-15th-oct-2020/2425
(sledges,
07:00:14)
- Brief introduction (5 min). Please prefix your name/handle with #info (sledges, 07:00:41)
- Simonas Leleiva - privateer for Jolla
(sledges,
07:00:47)
- Otto Mäkelä - community (ExTechOp,
07:01:09)
- Jussi Maaniitty - Sailor at Jolla (maajussi,
07:01:29)
- Anton Thomasson - purveyor of shitty apps,
killer of trees (just watching from afar) (attah_work,
07:01:32)
- Andrew Branson - sailor @ Jolla (abranson,
07:01:36)
- Ville Nummela - Sailor @ Jolla (ViGe,
07:02:05)
- Chris Adams - developer @ Jolla (chriadam,
07:02:33)
- Nikita Ukhrenkov - sailor at Jolla (TheKit,
07:04:38)
- ApB - community (ApBBB,
07:05:58)
- harbour library policy (20 min -- asked by KeeperoftheKeys) (sledges, 07:06:14)
- <KeeperoftheKeys> some details about the
topic: In light of Jolla just breaking any app using python3 sqlite
bindings by seperating the bindings from python3 into a separate
package the whole "claim to carefully curated guaranteed to be
stable" allowed dependencies in harbour is a fallacy, (sledges,
07:06:19)
- <KeeperoftheKeys> at this time we can’t
even fix our apps by adding a dependency for python3-sqlite since
that is blocked by harbour, (sledges,
07:06:26)
- <KeeperoftheKeys> it took me several
hours of back and forth on the forum to even get an internal bug on
the subject opened. (sledges,
07:06:33)
- <KeeperoftheKeys> a. This is a pretty bad
slip up, I only figured it out by digging in the changelogs, that
should have been pointed out ahead of time. (sledges,
07:06:39)
- <KeeperoftheKeys> b. If "accepted" libs
get broken you might as well allow the "unaccepted" libs too.
(sledges,
07:06:46)
- <Jolla> python3-sqlite was broken on the
Early Access release. The early access releases should be considered
as beta. Their purpose is to find exactly this kind of bugs.
(sledges,
07:07:02)
- about additional libs: allowing mpris is on
Jolla's list, but abranson mentioned there might be couple of flakey
problems to sort out in mpris first (sledges,
07:23:45)
- for the record, please be patient when raising
issues on forum, Jolla is responding in forums as a company via its
sailors, and the reaction time can't be within the same day, as
internal discussions or other activities take place (sledges,
07:26:04)
- in future early breakages should hopefully get
improved via the cbeta testers (pre-EA) as long as the apps are
concerned (sledges,
07:27:34)
- Consistency of SFOS UX/UI across apps (15 min -- asked by ApBBB) (sledges, 07:28:02)
- <ApBBB> Lately -and as SFOS progresses-
more and more examples of apps (jolla ones like email, camera) that
are included in the OS “break” the SFOS UX by choosing traditional
taps/buttons instead of swipes and gestures. (sledges,
07:28:12)
- <ApBBB> So is jolla trying to move away
from the gesture paradigm, is it just that the devs (aurora os
people???) have no idea what they are doing and don’t care about
consisteny, and what jolla will do to fix this and make the OS
consistent everywhere. (sledges,
07:28:17)
- <Jolla> The short answer is that we try
to maintain and nurture the gesture paradigm. This is not simple
though, as you've seen. Being different of mainstream requires
balancing and sometimes we need to do compromises to accommodate
problems we've identified in our user studies. (sledges,
07:28:32)
- a forum post from Jolla's UX chief Joona is in
the works, explaining incoming calls redesign rationale (sledges,
07:38:01)
- UI (15 min -- asked by Sefriol) (sledges, 07:43:22)
- <Sefriol> Old SFOS Case Study:
(sledges,
07:43:26)
- https://together.jolla.com/question/195283/sailfish-os-ux-case-study/
(sledges,
07:43:29)
- <Sefriol> Broader topic, but in general
SFOS has from the start been about one handed ease of use and
intuitive gesture control. Latest “major” update was the inclusion
of tabs. (sledges,
07:43:32)
- <Sefriol> However this is also something
that highlights one of the “problems” with current gesture controls:
horizontal swipe. It needs to be really precise when there is
vertical content. (sledges,
07:43:38)
- <Sefriol> Example of using natural “arc
swipe”: (sledges,
07:43:44)
- https://t.me/SFOSFanclub/40662
(sledges,
07:43:47)
- Also with the inclusion of top menu, official
supported devices start to get taller and taller, making it harder
to reach. Maybe allow to customize UI so that you could get it from
the bottom instead? (sledges,
07:43:59)
- <Jolla> Tweaking of touch parameters is
definitely area that should get more focus, there are already known
touch issues with e.g. Keyboard, Camera and Gallery (also reported
by community in the forum). We are also aware of regression in
one-handed usage due to the growth of average phone display
dimensions. (sledges,
07:44:26)
- QML component separtion (5 min -- asked by Sefriol) (sledges, 07:58:43)
- <Sefriol> Separating QML components from
closed source and publishing them to git: (sledges,
07:58:47)
- https://forum.sailfishos.org/t/separating-qml-components-from-closed-source-and-publishing-them-to-git/1894
(sledges,
07:58:50)
- <Sefriol> Maajussi promised to take a
look. Any updates on this front? (sledges,
07:58:53)
- <maajussi> No news available at the
moment to share. Need to come back to this later. (sledges,
07:59:01)
- Overlay apps in 3.4 and later (15 min -- asked by coderus) (sledges, 07:59:33)
- <coderus> 3.4 update has broke overlay
apps utilizing window category properties. Launching such apps
produce black screen. Problem was reported internally long before
3.4 update came out, but no action/suggestion was taken.
(sledges,
07:59:39)
- <coderus> 3.4 update obsoleted some
useful applications and “bricked” devices of some users. Jolla
position was: “we never officially supported this kind of hack for
overlay apps, so it’s your own fault”, in my opinion it looks very
frustrating, my apps was allowed and published to Jolla Store with
no problems. (sledges,
07:59:52)
- <coderus> Just tell if proper/replacement
API is/will be available for making overlay apps? I need to decide
the future of my applications. (sledges,
08:00:05)
- <Jolla> Looks like the system considers
your window to be full-screen (fully opaque) if the background
drawing gets disabled. Commented to the forum topic some ideas how
your app could be fixed, let's continue the discussion there:
(sledges,
08:00:26)
- https://forum.sailfishos.org/t/3-4-bug-lack-of-opacity-for-overlayed-window/1449/10
(sledges,
08:00:30)
- list of overlay apps: (sledges,
08:03:55)
- https://forum.sailfishos.org/t/community-meeting-on-irc-15th-oct-2020/2425/10
(sledges,
08:03:57)
- Battery Overlay, ScreenTapShot2, Edge mode in
Aliendalvik Control, okboard, taskswitcher, phonehook, Tint
Overlay (sledges,
08:05:00)
- in the light of many actual apps use an overlay
hack, a need for stable API is augmented (sledges,
08:08:52)
- regarding the stable API work prioritising,
Jolla cannot say before discussing internally other than we will
look into it (sledges,
08:15:13)
- Improving the calendar design (10min -- asked by Raymaen) (sledges, 08:15:31)
- <Raymaen> It would be great to get an
official Response from Jolla designers to this topic and if there
are plans to make the calendar app more useful for business purposes
and get a better overview over the appointments. even if it is
somehow similar to my draft: (sledges,
08:15:37)
- https://forum.sailfishos.org/t/improved-calendar-design/1579
(sledges,
08:15:43)
- <Jolla> We are constantly working on
calendar app, recently more on the bugs than design. The minimal
main calendar flows could (should) definitely be improved.
(sledges,
08:16:12)
- a shout-out to dcaliste for his great work on
the calendar (community member contributing internally, yes it's
possible, apply herein;) (sledges,
08:18:21)
- General Discussion (5mins) (sledges, 08:20:23)
- https://blog.jolla.com (sledges,
08:21:56)
- One participant just said "the less android the
better", and this tweet just backs it up (I hope Fernschreiber
receives a lot of contribs as it's FOSS!) (sledges,
08:27:23)
- https://twitter.com/Ygriega/status/1307765659619725312
(sledges,
08:27:26)
- Next meeting time and date (5 min) (sledges, 08:29:34)
- Next meeting will be held on Thursday 29th
October 2020 at 8:00am UTC: 2020-10-29T08Z (sledges,
08:32:23)
Meeting ended at 08:33:16 UTC
(full logs).
EDIT: fixed the next meeting date and time
Action items
- (none)
People present (lines said)
- sledges (112)
- ApBBB (44)
- KeeperoftheKeys (28)
- jpetrell_ (26)
- flypig (14)
- ViGe (11)
- coderus (10)
- abranson (9)
- attah_work (8)
- ExTechOp (7)
- chriadam (5)
- sailbot (4)
- NotKit (2)
- maajussi (1)
- TheKit (1)
Generated by MeetBot 0.1.4.