| ExTechOp | Good morning! | 06:57 |
|---|---|---|
| abr | #startmeeting Sailfish OS, open source, collaboration -- 19th August 2021 | 07:01 |
| 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 |
| sailbot | Useful Commands: #action #agreed #help #info #idea #link #topic. | 07:01 |
| abr | #info Meeting information and agenda can be found here: | 07:02 |
| abr | #link https://forum.sailfishos.org/t/community-meeting-on-irc-19th-august-2021/7534 | 07:02 |
| abr | Sledges is away so I'll be your substitute teacher today. I don't want any funny business. | 07:02 |
| abr | #topic Brief introduction (5 min). Please prefix your name/handle with #info | 07:02 |
| abr | #info abranson - Mr Branson | 07:03 |
| ExTechOp | #info Otto Mäkelä - community | 07:03 |
| chriadam | #info Chris Adams, privateer for Jolla | 07:03 |
| karry | #info Lukas Karas - community developer | 07:03 |
| flypig | #info David Llewellyn-Jones - sailor @ jolla | 07:04 |
| fridl | #info fridlmue - community | 07:04 |
| flypig | Sir, is it playtime yet? | 07:07 |
| abr | Alright let's open those textbooks | 07:07 |
| abr | settle down at the back there, Llewellyn-Jones | 07:08 |
| abr | #topic interaction hints in apps (5 min -- asked by thigg) | 07:08 |
| 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 |
| 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 |
| abr | #info <thigg> Untested Example: TouchInteractionHint used in: | 07:08 |
| abr | #link https://gist.github.com/jaymzznoori/a980314f8248e0a1e7904c29c88ecdf3 | 07:08 |
| abr | and the answer: | 07:09 |
| 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 |
| abr | Is thigg here? | 07:09 |
| 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 |
| flypig | I guess the obvious question: will the docs be added somewhere now? | 07:11 |
| fridl | are you going to provide API docks then? | 07:11 |
| abr | Yeah, I wondered that too :) | 07:12 |
| flypig | I didn't check, is the code already documented? | 07:12 |
| 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:13 |
| 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 |
| abr | anyway, let's press on | 07:14 |
| 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:14 |
| 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 |
| 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 |
| 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 |
| 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 |
| 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:15 |
| 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 |
| abr | #info <lqramen> Are phone outside Xperia line in the scope of Jolla to proivde offical support and sell licences ? | 07:16 |
| abr | bit of a long essay there | 07:16 |
| abr | and the answer: | 07:16 |
| 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 |
| abr | are we missing lqramen too? | 07:16 |
| EA3ICN | Would it be possible to know which options are being evaluated? | 07:17 |
| thilo[m] | #info thigg - community dev, sorry for being late | 07:18 |
| EA3ICN | And is this something that is seen as urgent at Jolla or as something more in the background? | 07:18 |
| 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:19 |
| EA3ICN | Same | 07:20 |
| flypig | Just for the sake of interesting discussion, apart from Fairphone, what other options are people in the community interested in? | 07:20 |
| 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 |
| EA3ICN | Took a while to order an 10ii and this was back in February. Wasn't easy to find in Spain | 07:20 |
| thilo[m] | abr: thanks, that answers my question. hope we gonna see this in the docs on the website soon as well | 07:22 |
| abr | I think Jolla are always looking out for potential additional devices to support | 07:22 |
| EA3ICN | > <flypig> Just for the sake of interesting discussion, apart from Fairphone, what other options are people in the community interested in? | 07:22 |
| EA3ICN | I'm not very knowledgeable about other options except initiatives like Volla, but maybe Nothing could be an option? | 07:22 |
| thilo[m] | need to leave again, got another meeting | 07:22 |
| fridl | flypig: I think Fairphone, Vollaphone and Pinephone are the devices which raise most interest in general. | 07:22 |
| chriadam | thanks for your question and bringing it to our attention, thilo[m] | 07:22 |
| abr | thilo[m]: glad you're happy with the answer! | 07:22 |
| flypig | fridl, all those devices seem quite different from Xperia X: aimed at a different audience. | 07:23 |
| flypig | Just an observation. | 07:23 |
| 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 |
| abr | I'm pretty sure there have been discussions between Jolla and all of those vendors in the past | 07:24 |
| fridl | flypig: yes, but i think the (current) target group for SFOS lives in that corner ;-) | 07:24 |
| 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 |
| flypig | *interested | 07:25 |
| fridl | flypig: full ACK | 07:25 |
| abr | They've all got decent community ports going on too | 07:26 |
| flypig | Yes, they lend themselves to community ports. | 07:26 |
| 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 |
| 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:28 |
| 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:29 |
| abr | I don't know the details, but I think that's probably an oversimplification. | 07:30 |
| 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 |
| fridl | abr: I'm sure it is. | 07:30 |
| fridl | But thats what the discussion was about that raised these question if i remember correctly. | 07:31 |
| fridl | (in the forums) | 07:31 |
| flypig | Interesting points fridl. | 07:31 |
| flypig | ExTechOp, that's also a good point, but the shift to 64-bit had to happen at some point. | 07:32 |
| ExTechOp | flypig Indeed, but hopefully other hardware ports would be "easier" now that this is done. | 07:33 |
| abr | And there's been an impressive amount of work done in the community to get those apps rebuilt for 64bit | 07:33 |
| 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 |
| flypig | abr, I totally second that. It's been great to see developers rise to the challenge. | 07:33 |
| 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:34 |
| 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:36 |
| 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 |
| abr | yeah you're right chris, let's move on | 07:37 |
| abr | to | 07:37 |
| abr | #topic General discussion (30 min) | 07: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 |
| 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:39 |
| 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 |
| flypig | Yes, both personal ringtones and night silence are missing from 10II. A valid repost ;) | 07:40 |
| bfd_fr | I would add personal LED blinking to the personal ringtones - had on my previous phone, very useful. | 07:41 |
| ExTechOp | Does the 10II hardware have one? | 07:41 |
| abr | yeah | 07:41 |
| abr | though the hard cover blocks it :( | 07:42 |
| 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 |
| ExTechOp | (Looking at my phone, it indeed has, blush) | 07:42 |
| 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 |
| 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:44 |
| 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 |
| 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:45 |
| chriadam | 2) there are a variety of issues / edge cases which make this tricky to implement properly in the UI | 07:46 |
| 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 |
| 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:46 |
| 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 |
| chriadam | etc | 07:47 |
| 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 |
| chriadam | For (2) would require fairly significant effort from Jolla internally to support properly, I suspect. | 07:48 |
| flypig | It sounds like (2) could be about making decisions such as to not support personal ringtones when the device is locked. | 07:49 |
| rinigus | chriadam: re (2) - is it since bits are in closed source parts? | 07:49 |
| 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 |
| chriadam | rinigus: yes | 07:49 |
| chriadam | flypig: most phone calls are received when the device is locked, I would guess. | 07:50 |
| chriadam | flypig: most problems go away when home is decrypted | 07:50 |
| 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 |
| flypig | Yeah, sorry, I meant encrypted, which is slightly different. | 07:50 |
| chriadam | even just performance / memory pressure things would need to be considered, also. | 07:51 |
| 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:51 |
| chriadam | IMO | 07:52 |
| rinigus | flypig: but when phone is encrypted, SIM is probably locked as well, isn't it? | 07:52 |
| rinigus | so, you cannot receive phone calls anyway | 07:52 |
| 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 |
| chriadam | rinigus: hmm, you may well be right. | 07:52 |
| flypig | If you have multiple users, does the incoming call app have access to multiple contact databases? | 07:53 |
| 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 |
| chriadam | flypig: that's a question for a different channel ;-) | 07:53 |
| abr | i think when the phone's locked, it still has a currently logged in user. | 07:54 |
| abr | maybe there should be a second, global contact database with shared contacts between all users :D | 07:54 |
| 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 |
| abr | rinigus: oh that's a shame. what was the problem? | 07:56 |
| rinigus | abr: re locked: it should have a current user. although, never used multiuser on SFOS device | 07:57 |
| abr | they are great though. and we must always cherish how much of that base we can make PRs for | 07:57 |
| 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:58 |
| 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 |
| rinigus | flypig: or release those bits as open source? | 07:59 |
| 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 |
| abr | rinigus: have to remember they're a small team too. it's amazing they get as much done as they do. | 08:00 |
| flypig | rinigus, that would also help the community to take it forwards, yes :) | 08:01 |
| rinigus | abr: I do NOT complain at all :) . it is amazing what they do, how well they respond and help! | 08:01 |
| flypig | Thanks chriadam, I think that's a pretty clear path. | 08:01 |
| rinigus | in general, open sourcing different bits would help and allow us to work on those aspects | 08:02 |
| ExTechOp | I think we can all say THANK YOU to the developers, both at Jolla and the community for an amazing job! | 08:02 |
| 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 |
| 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:03 |
| rinigus | maybe Jolla could discuss internally which bits can be open sourced? as the first one... | 08:05 |
| chriadam | that topic is raised quite frequently from dev side to management, rest assured.. | 08:05 |
| abr | Ok I should wrap this up then | 08:05 |
| abr | #topic Next meeting time and date (5 min) | 08:05 |
| abr | Two weeks from now is 2nd September | 08:06 |
| abr | Is that ok with everyone? | 08:06 |
| 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 |
| chriadam | time is also fine for me, but I'm in an unusual tz | 08:07 |
| fridl | I would guess that still some people are on holidays. | 08:08 |
| abr | I think that's maybe just the northern hemisphere summer still having an effect | 08:08 |
| fridl | (mine did not even start) | 08:08 |
| chriadam | ah, of course, that makes sense | 08:08 |
| abr | I'd rather not change the time when sledges is away. He's honed it over a number of months | 08:08 |
| abr | ok then | 08:08 |
| abr | #info Next meeting will be held on Thursday 2nd September 2021 at 7:00am UTC: 2021-09-02T07Z | 08:08 |
| chriadam | true, I was forgetting vacations anyway, my bad | 08:09 |
| abr | same bat time, same bat channel | 08:09 |
| chriadam | thanks for chairing this meeting abr | 08:09 |
| abr | #endmeeting | 08:09 |
| sailbot | Meeting ended Thu Aug 19 08:09:17 2021 UTC. | 08:09 |
| sailbot | Minutes: https://irclogs.sailfishos.org/meetings/sailfishos-meeting/2021/sailfishos-meeting.2021-08-19-07.01.html | 08:09 |
| sailbot | Minutes (text): https://irclogs.sailfishos.org/meetings/sailfishos-meeting/2021/sailfishos-meeting.2021-08-19-07.01.txt | 08:09 |
| sailbot | Log: https://irclogs.sailfishos.org/meetings/sailfishos-meeting/2021/sailfishos-meeting.2021-08-19-07.01.log.html | 08:09 |
| abr | you're welcome! | 08:09 |
| chriadam | thanks everyone for participating | 08:09 |
| abr | thanks for coming | 08:09 |
| flypig | Yeah, thanks abr and all. | 08:09 |
| bfd_fr | thanks a lot, see you soon | 08:09 |
| ExTechOp | Thanks everyone! | 08:09 |
| lqramen | I logged into aplogise... I completly forgot that today was Thursday and I had a question for this morning.... I literally just rememebred having a coffee while petting my cat... nearly burned the poor thing when it popped into my head. | 09:51 |
| lqramen | It just totally slipped my mind. My apologies if somebody prepared an answer and I was not there. | 09:52 |
| lqramen | I was at my laptop all morning working on a physics problem, which makes me go into the tunnel. I will repost it next thread and set some more audible reminders. | 09:55 |
| Keto | lqramen: there was some discussion on your topic, you can find the log here https://irclogs.sailfishos.org/meetings/sailfishos-meeting/2021/sailfishos-meeting.2021-08-19-07.01.log.html | 10:03 |
| lqramen | Thank you. I read it there, <abr> raised some of my points for me. I read it that the possability of "other" hardware ports should be easier, which is somewhat hopeful due to the switch to 64bit. | 10:11 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!