07:01:47 <abr> #startmeeting Sailfish OS, open source, collaboration -- 19th August 2021
07:01:47 <sailbot> Meeting started Thu Aug 19 07:01:47 2021 UTC. The chair is abr. Information about MeetBot at http://wiki.debian.org/MeetBot.
07:01:47 <sailbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
07:02:13 <abr> #info Meeting information and agenda can be found here:
07:02:13 <abr> #link https://forum.sailfishos.org/t/community-meeting-on-irc-19th-august-2021/7534
07:02:31 <abr> Sledges is away so I'll be your substitute teacher today. I don't want any funny business.
07:02:41 <abr> #topic Brief introduction (5 min). Please prefix your name/handle with #info
07:03:15 <abr> #info abranson - Mr Branson
07:03:19 <ExTechOp> #info Otto Mäkelä - community
07:03:22 <chriadam> #info Chris Adams, privateer for Jolla
07:03:34 <karry> #info Lukas Karas - community developer
07:04:53 <flypig> #info David Llewellyn-Jones - sailor @ jolla
07:04:55 <fridl> #info fridlmue - community
07:07:40 <flypig> Sir, is it playtime yet?
07:07:41 <abr> Alright let's open those textbooks
07:08:12 <abr> settle down at the back there, Llewellyn-Jones
07:08:18 <abr> #topic interaction hints in apps (5 min -- asked by thigg)
07:08:28 <abr> #info <thigg> InteractionHints are a useful way to communicate to the user, what they can do. when triggered they show a text and highlight a component on the screen.
07:08:44 <abr> #info However, there is no official documentation on them but many apps actually use them. Are there any plans to release them to the public soon?
07:08:44 <abr> #info <thigg> Untested Example: TouchInteractionHint used in:
07:08:44 <abr> #link https://gist.github.com/jaymzznoori/a980314f8248e0a1e7904c29c88ecdf3
07:09:12 <abr> and the answer:
07:09:18 <abr> #info <Jolla> You're right! For some odd reason looks like the API documentation was never provided, even though the interaction hint components (TapInteractionHint, TouchInteractionHint, InteractionHintLabel, FirstTimeUseCounter) are part of the public API (Sailfish.Silica module) and even Silica Component Gallery has code examples on how to use them.
07:09:32 <abr> Is thigg here?
07:11:26 <abr> Ah well, that answer should be good for him in the logs. I'll move on unless anyone has anything to add.
07:11:54 <flypig> I guess the obvious question: will the docs be added somewhere now?
07:11:59 <fridl> are you going to provide API docks then?
07:12:12 <abr> Yeah, I wondered that too :)
07:12:56 <flypig> I didn't check, is the code already documented?
07:13:23 <flypig> I.e. does it just need a home for docs that already exist, or do they still need to be written I wonder.
07:14:12 <abr> hmm, i'd think they'd be in the same package as all the other parts, so I'd assume they'd need to be written
07:14:30 <abr> anyway, let's press on
07:14:51 <abr> #topic Long term viability of Xperia line & possible official port for other phone with long term support (12.5 min -- asked by lqramen)
07:15:17 <abr> #info <lqramen> There have been some topic in the forum lately about stability of the official SFOS incl. Alien Dalvik, in particular the latest X10ii release. Various users express their frustration that using SFOS X as stable mobile device.
07:15:25 <abr> #info <lqramen> It appears that for each SFOSX release with a new Xperia phone there are alot of new bugs being introduced further adding to the instability of the general experience. We all aware that Jolla has limited resources SFOS public release is also balanced with other commerical commitments.
07:15:31 <abr> #info <lqramen>  However this raises the question why is there need for repeated rebuilds and rework for bugs for each Xperia release. By the time a release is stable the model of phone is difficult to obtain.
07:15:41 <abr> #info <lqramen> The discussion was raised about having another phone with a more stable hardware outlook as the baseline for a SFOS offical port.
07:15:50 <abr> #info <lqramen> Fairphone was mentioned as a prospecive candidate as there is an unlocked bootloader has officaly support, hardware is stable (alebit not cutting edge) and has a long term stable outlook availability and spare parts etc… Community port for SFOS on Fairphone is also in highly working state.
07:16:01 <abr> #info <lqramen> Given the limited and resources and hardware outlook for Xperia 10ii(i) what is Jollas plan going forth to provide a stable platform going forth.
07:16:01 <abr> #info <lqramen> Are phone outside Xperia line in the scope of Jolla to proivde offical support and sell licences ?
07:16:12 <abr> bit of a long essay there
07:16:19 <abr> and the answer:
07:16:32 <abr> #info <Jolla> New Sailfish X devices often require newer Android device adaptations and introduce new capabilities (fingerprint, 64bit, etc.). In sense they don't present rework, but come with new, previously untackled issues that need to be sorted for the platform to evolve. We are constantly evaluating our options, but don't yet have new supported devices to announce.
07:16:55 <abr> are we missing lqramen too?
07:17:31 <EA3ICN> Would it be possible to know which options are being evaluated?
07:18:02 <thilo[m]> #info thigg - community dev, sorry for being late
07:18:21 <EA3ICN> And is this something that is seen as urgent at Jolla or as something more in the background?
07:19:40 <bfd_fr> As a user, this is urgent because I had a lot of trouble to find a 10ii, now you can only find 10iii in the stores
07:20:11 <EA3ICN> Same
07:20:31 <flypig> Just for the sake of interesting discussion, apart from Fairphone, what other options are people in the community interested in?
07:20:45 <abr> As mentioned in previous meetings, there is work ongoing to be able to use SFOSX packages on community ports. But that requires a lot of messing around in the store, and you need to take a very deep breath before doing that..
07:20:53 <EA3ICN> Took a while to order an 10ii and this was back in February. Wasn't easy to find in Spain
07:22:19 <thilo[m]> abr: thanks, that answers my question. hope we gonna see this in the docs on the website soon as well
07:22:22 <abr> I think Jolla are always looking out for potential additional devices to support
07:22:30 <EA3ICN> > <flypig> Just for the sake of interesting discussion, apart from Fairphone, what other options are people in the community interested in?
07:22:32 <EA3ICN> I'm not very knowledgeable about other options except initiatives like Volla, but maybe Nothing could be an option?
07:22:33 <thilo[m]> need to leave again, got another meeting
07:22:46 <fridl> flypig: I think Fairphone, Vollaphone and Pinephone are the devices which raise most interest in general.
07:22:51 <chriadam> thanks for your question and bringing it to our attention, thilo[m]
07:22:58 <abr> thilo[m]: glad you're happy with the answer!
07:23:20 <flypig> fridl, all those devices seem quite different from Xperia X: aimed at a different audience.
07:23:26 <flypig> Just an observation.
07:24:00 <bfd_fr> Most SailfishOS won't seek a top-notch hardware in their phone, but definitely a reliable phone they can purchase without too much difficulty
07:24:09 <abr> I'm pretty sure there have been discussions between Jolla and all of those vendors in the past
07:24:27 <fridl> flypig: yes, but i think the (current) target group for SFOS lives in that corner ;-)
07:25:23 <flypig> fridl, I wouldn't necessarily disagree with that, although I suspect the corner that's interest in open hardware may be the more vocal corner.
07:25:30 <flypig> *interested
07:25:58 <fridl> flypig: full ACK
07:26:03 <abr> They've all got decent community ports going on too
07:26:50 <flypig> Yes, they lend themselves to community ports.
07:28:12 <fridl> But I think the Idea of this question was to spare jolla work by adapting to a phone which has a longer product cycle with the official sailfish x.
07:28:48 <abr> About the Sony's, I disagree a bit with the assertion that they somehow accumulate bugs. The X10ii is the most solid xperia port to date imho.
07:29:21 <fridl> and most people do not get why a deal with Fairphone is needed if you don't get money from Sony for the work on these ports. And people are raising questions there. (that's my observation only!)
07:30:01 <abr> I don't know the details, but I think that's probably an oversimplification.
07:30:08 <ExTechOp> However, 10II is a bit of a steep upgrade since some of the older software suddenly isn't any longer compatible with it due to the 64 bits
07:30:16 <fridl> abr: I'm sure it is.
07:31:02 <fridl> But thats what the discussion was about that raised these question if i remember correctly.
07:31:13 <fridl> (in the forums)
07:31:19 <flypig> Interesting points fridl.
07:32:23 <flypig> ExTechOp, that's also a good point, but the shift to 64-bit had to happen at some point.
07:33:02 <ExTechOp> flypig Indeed, but hopefully other hardware ports would be "easier" now that this is done.
07:33:03 <abr> And there's been an impressive amount of work done in the community to get those apps rebuilt for 64bit
07:33:36 <fridl> abr: I think the point also is not, that the port is not very stable or something like that. But that it has the tendency of never going to be "perfect" as a new Xperia generation needs to be considered before "all" bugs are ironed put.
07:33:42 <flypig> abr, I totally second that. It's been great to see developers rise to the challenge.
07:34:59 <flypig> fridl, the flip side is that hardware gets older. Jolla supported the Jolla C for... 7 years I think? But many users wouldn't have been satisfied if hardware support had frozen there.
07:36:01 <abr> fridl: yeah, I see that. It's very different dealing with an open source project like the sony open devices, vs getting binaries delivered from a device manufacturer. Especially one that has to chase annual Android releases that tend to change a large amount of stuff.
07:37:16 <chriadam> I'm not sure how much further we can take this discussion, here.  Jolla will always see the need to support Sailfish X on a device which is widely available for the community, and will make decisions about which devices to support when it is time to make such decisions, with available resources to do so, etc.  but I guess the people here in this meeting aren't the ones making those decisions ;-)
07:37:40 <abr> yeah you're right chris, let's move on
07:37:41 <abr> to
07:37:50 <abr> #topic General discussion (30 min)
07:39:37 <flypig> Last meeting we had some discussion about personal ringtones. tobset was keen to see them implemented, and we threw around some ideas.
07:39:45 <abr> But just to finish that - the really great thing about the sony project is how the kernel source remains the same, as do a lot of the other components. there may be new bugs per release, but lots of it is shared between devices and improves greatly. I'd say fingerprint support is a good example there.
07:40:11 <ExTechOp> flypig Also last time, in contrast, I mentioned that there does not seem to be a "night silence" type application for 10II :-D
07:40:48 <flypig> Yes, both personal ringtones and night silence are missing from 10II. A valid repost ;)
07:41:31 <bfd_fr> I would add personal LED blinking to the personal ringtones - had on my previous phone, very useful.
07:41:43 <ExTechOp> Does the 10II hardware have one?
07:41:51 <abr> yeah
07:42:10 <abr> though the hard cover blocks it :(
07:42:16 <rinigus> abr: main issue with sony seems to be struggles with the binary blobs - something open devices cannot overcome either. for example, tama port with 4.14 kernel does struggle with some issues which were not there for 4.9. but then some aspects improved... in this respect, port quality does depend a lot on sony open devices aosp quality
07:42:25 <ExTechOp> (Looking at my phone, it indeed has, blush)
07:44:21 <flypig> Concerning personal ringtones, dcaliste discovered last time the "TypeRingTone" field in the QContactDetail class, and I promised to follow up with chriadam about it to see whether it was usable. chriadam would you mind explaining for the logs?
07:44:49 <abr> rinigus: definitely. I think the trouble is that they have to move to the next Android base before the quality quite gets up to what you'd expect from a productized device. But it's an open device project and so that isn't really the aim. It's more about getting more devices opened up that otherwise would be very closed.
07:45:24 <chriadam> the QContactRingTone detail type would be the appropriate one to store per-contact ringtone (and potentially LED pattern) information, which could be used by the Phone application to play the appropriate ringtone when an incoming call from that contact is detected.  BUT
07:45:50 <chriadam> 1) we don't (afair) actually store that detail type currently in our db (as we haven't used that detail type, yet, afaik)
07:46:08 <chriadam> 2) there are a variety of issues / edge cases which make this tricky to implement properly in the UI
07:46:13 <rinigus> abr: I have the same impression. On top of it, they don't seem to have major control over qcom blobs either which could degrade between releases
07:46:55 <chriadam> including but not limited to: cases when the phone is locked and a call is received (e.g. home might not be decrypted, so contacts db not accessible; or even just leaking info about a contact when the phone is locked)
07:47:27 <chriadam> when a ringtone is deleted, appropriately updating the contacts db (and that issue is ... difficult ... to resolve properly without adding dependencies on tracker etc, which I personally would prefer to avoid)
07:47:28 <chriadam> etc
07:48:01 <chriadam> For (1) it would be reasonably simple for the community to add support.  qtcontacts-sqlite + nemo-qml-plugin-contacts / libcontacts support for the Ringtone detail type
07:48:17 <chriadam> For (2) would require fairly significant effort from Jolla internally to support properly, I suspect.
07:49:18 <flypig> It sounds like (2) could be about making decisions such as to not support personal ringtones when the device is locked.
07:49:27 <rinigus> chriadam: re (2) - is it since bits are in closed source parts?
07:49:28 <abr> rinigus: they do have quite a bit of control in there - they've fixed bugs for us in the blobs before. but that's always at the end of a long investigation that often ends up with a workaround in the open source stuff anyway.
07:49:34 <chriadam> rinigus: yes
07:50:31 <chriadam> flypig: most phone calls are received when the device is locked, I would guess.
07:50:39 <chriadam> flypig: most problems go away when home is decrypted
07:50:42 <rinigus> abr: great to hear. but with the control I would expect ability to fix a bug in blob and not via workaround
07:50:56 <flypig> Yeah, sorry, I meant encrypted, which is slightly different.
07:51:38 <chriadam> even just performance / memory pressure things would need to be considered, also.
07:51:57 <chriadam> in short, it's not something that we can just promise to add support for, without some very careful analysis of possible effects / costs / effort required
07:52:01 <chriadam> IMO
07:52:01 <rinigus> flypig: but when phone is encrypted, SIM is probably locked as well, isn't it?
07:52:22 <rinigus> so, you cannot receive phone calls anyway
07:52:22 <abr> rinigus: maybe workaround was the wrong word. more like it often looks to be in the blobs, but it's actually in the open source stuff. when that's the kernel or arcane config files it can be hard to tell.
07:52:27 <chriadam> rinigus: hmm, you may well be right.
07:53:12 <flypig> If you have multiple users, does the incoming call app have access to multiple contact databases?
07:53:17 <abr> yeah I don't think the home is ever unmounted when booted, and the device isn't really booted at all when you mount it.
07:53:35 <chriadam> flypig: that's a question for a different channel ;-)
07:54:05 <abr> i think when the phone's locked, it still has a currently logged in user.
07:54:38 <abr> maybe there should be a second, global contact database with shared contacts between all users :D
07:56:11 <rinigus> abr: re blobs/kernel - I wasn't as lucky with tama. but it was, according to sony devs, due to some major bugs in blobs and they just couldn't fix it when tried before. but, to add to this discussion regarding different devices, I had very good experience with the help from sony open devices developers and it is a big plus when working with these devices on the port
07:56:39 <abr> rinigus: oh that's a shame. what was the problem?
07:57:07 <rinigus> abr: re locked: it should have a current user. although, never used multiuser on SFOS device
07:57:13 <abr> they are great though. and we must always cherish how much of that base we can make PRs for
07:58:37 <flypig> chriadam, so to summarise (please correct me), if the community wanted to move the task forwards, they could definitely help with the backend components, but would ultimately have to let Jolla finalise things.
07:59:30 <rinigus> abr: tama problems are mainly related to battery, power consumption. but more or less should be fine with extra tuning or we got used to it
07:59:58 <rinigus> flypig: or release those bits as open source?
08:00:20 <chriadam> flypig: that's correct.  first step would be PR to qtcontacts-sqlite to support the QContactRingtone detail, plus unit tests.  second step would be checking nemo-qml-plugin-contacts / seasidecache to ensure that value can be exposed to QML properly.
08:00:34 <abr> rinigus: have to remember they're a small team too. it's amazing they get as much done as they do.
08:01:20 <flypig> rinigus, that would also help the community to take it forwards, yes :)
08:01:21 <rinigus> abr: I do NOT complain at all :) . it is amazing what they do, how well they respond and help!
08:01:51 <flypig> Thanks chriadam, I think that's a pretty clear path.
08:02:06 <rinigus> in general, open sourcing different bits would help and allow us to work on those aspects
08:02:14 <ExTechOp> I think we can all say THANK YOU to the developers, both at Jolla and the community for an amazing job!
08:03:14 <chriadam> lots of great work from the community.  I'd like to highlight again how many PRs dcaliste has provided over the last few weeks, across a variety of components.  community help and effort is ... sincerely appreciated.
08:03:46 <chriadam> so if someone is willing to step up and start creating PRs for the ringtone thing, I will do what I can internally to push that feature forward
08:05:07 <rinigus> maybe Jolla could discuss internally which bits can be open sourced? as the first one...
08:05:38 <chriadam> that topic is raised quite frequently from dev side to management, rest assured..
08:05:42 <abr> Ok I should wrap this up then
08:05:51 <abr> #topic Next meeting time and date (5 min)
08:06:32 <abr> Two weeks from now is 2nd September
08:06:50 <abr> Is that ok with everyone?
08:07:32 <chriadam> fine for me.  I am wondering: did we have less participation this week than usual?  should the time be shifted back one hour to accommodate more folks, or?
08:07:39 <chriadam> time is also fine for me, but I'm in an unusual tz
08:08:07 <fridl> I would guess that still some people are on holidays.
08:08:17 <abr> I think that's maybe just the northern hemisphere summer still having an effect
08:08:22 <fridl> (mine did not even start)
08:08:35 <chriadam> ah, of course, that makes sense
08:08:36 <abr> I'd rather not change the time when sledges is away. He's honed it over a number of months
08:08:55 <abr> ok then
08:08:59 <abr> #info Next meeting will be held on Thursday 2nd September 2021 at 7:00am UTC:  2021-09-02T07Z
08:09:04 <chriadam> true, I was forgetting vacations anyway, my bad
08:09:07 <abr> same bat time, same bat channel
08:09:12 <chriadam> thanks for chairing this meeting abr
08:09:17 <abr> #endmeeting