07:00:16 <flypig> #startmeeting Sailfish OS, open source, collaboration -- 14th April 2022
07:00:16 <sailbot> Meeting started Thu Apr 14 07:00:16 2022 UTC. The chair is flypig. Information about MeetBot at http://wiki.debian.org/MeetBot.
07:00:16 <sailbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
07:00:23 <flypig> #info Meeting information and agenda can be found here:
07:00:27 <flypig> #link https://forum.sailfishos.org/t/community-meeting-on-irc-14th-april-2022/10931
07:00:35 <flypig> I am the meeting's chairperson today, and will be doing my best to keep time and order. Please respect the timings and don't use Easter Eggs as bookmarks; from experience, nothing good comes of it :(
07:00:40 <flypig> #topic Brief introduction (5 min). Please prefix your name/handle with #info
07:01:11 <flypig> #info David Llewellyn-Jones - sailor @ jolla
07:01:24 <pherjung> #info pherjung - community
07:01:28 <poetaster> #info Mark poetaster - community
07:02:48 <nephros> #info Peter G. - community
07:02:58 <thilo[m]> #info thigg - community
07:03:24 <santhoshm> #info Santhosh M - User
07:03:40 <ExTechOp> #info Otto Mäkelä - community
07:03:54 <flypig> It's great to have so many here from the community today (even if you don't all want to admit it!)
07:04:24 <dcaliste> #info Damien Caliste, community
07:04:25 <sledges> #info Simonas Leleiva - privateer
07:04:34 <poetaster> top of the morning!
07:04:40 <rainemak> #info Raine Mäkeläinen - sailor @ Jolla
07:04:46 <flypig> Likewise poetaster :)
07:05:51 <flypig> It's looking to be a convincing community win today!
07:06:16 <poetaster> there is a plan...
07:06:28 <flypig> That makes me very nervous.
07:06:41 <flypig> Okay, community 7, Jolla 3.
07:06:56 <flypig> It's nice to have you all here. We have quite a few questions, so let's get straight to it.
07:07:03 <flypig> #topic Community bug coordination (15 mins -- asked by flypig)
07:07:09 <flypig> #info <Jolla> This is a follow-up topic from the last meeting, where we discussed about better bug tracking on the forum.
07:07:14 <flypig> #info <Jolla> pherjung thigg and nephros rose to the challenge, and have already done some amazing work improving the forum bug pipeline.
07:07:20 <flypig> #info <Jolla> This is an opportunity for them to share and discuss the processes they've devised further.
07:07:26 <flypig> #link https://irclogs.sailfishos.org/meetings/sailfishos-meeting/2022/sailfishos-meeting.2022-03-31-07.00.html
07:07:30 <flypig> #link https://forum.sailfishos.org/t/new-role-community-bug-coordinator/10935
07:07:49 <flypig> Would one of you, pherjung, nephros, thilo[m], mind maybe explaining what's been going on a bit?
07:08:17 <pherjung> To summarize, we catch all topics looking like a bug report and that are not marked as tagged by Jolla
07:08:55 <pherjung> First step is to get all bug reports already tracked by Jolla tagged correctly
07:09:13 <pherjung> and then help Jolla to improve the quality of bug reports
07:09:54 <pherjung> With trying to reproduce them and checking if all data are present
07:11:35 <nephros> ... this will produce a list of "good" untracked/new bug reports which we collect
07:12:19 <thilo[m]> For the quality our analysis discovered 2 problems that we are focusing on. 1) people are getting confused by the category description and are not using the template 2) people need help to create good bug reports
07:13:14 <thilo[m]> Thus one part is, to ask questions when a bug report could need improvement
07:13:30 <thilo[m]> Although most bug reports are already excellent
07:14:13 <piggz> on a related topic, I wondered why issue reporting is disabled on some (most?) github repos?
07:14:28 <nephros> something we would like to clarify is where to go from there, assuming we have a list of new "good" reports, how does jolla get prodded about them.
07:14:48 <sebix[m]> #info sebix - community and latecomer
07:15:01 <flypig> We discussed them being raised at this meeting every fortnight. Could something like that work?
07:15:23 <thilo[m]> Maybe we should try it?
07:15:56 <nephros> well do we really want to discuss a list of bugs on IRC?
07:16:00 <poetaster> I'm too verbose to chat about bugs :)
07:16:10 <poetaster> Well, I'm too verbose.
07:16:31 <flypig> I'm all for trying it. An alternative would be to discuss them in a public forum thread.
07:16:54 <pherjung> It's worth to try.
07:17:02 <poetaster> +1 thread(s)
07:17:10 <thilo[m]> I am a bit afraid that people get the feeling that their bugs are ignored when they do not show up
07:17:10 <flypig> I should say that the list you already provided to me (privately) was really useful, and ironed out some issues.
07:17:53 <flypig> thilo[m], what do you mean by "do not show up"?
07:18:00 <thilo[m]> Anyways thats just a random selection from whats been going on
07:18:11 <sebix[m]> Whats the point of discussing a list of bugs in a forum-thread while the bugs are already discussed in the forum in a more structure way?
07:18:19 <nephros> one idea was to put the list in the  "next meeting topics" thread a couple of days before. To give some time to prepare. And then in the meeting the topic could just be: anything to discuss about the bug list? no? on to the next topic...
07:18:41 <flypig> sebix[m], it's a fair point. The idea is to bring attention to the "good quality" bugs.
07:19:27 <flypig> nephros, I like that as an idea. It would help us (Jolla) to respond in a timely manner.
07:19:31 <rainemak> piggz, we haven't enabled github issues globally but only for some.
07:19:51 <thilo[m]> By do not show up, i meant they do not make it to the list
07:19:57 <pherjung> I see only one advantage submitting bug reports on community meeting: If we need some more infos to collect logs Jolla can give us some hint
07:20:07 <flypig> thilo[m], thanks for the clarification.
07:20:13 <nephros> it would also be interesting to know which *kinds* of bugs Jolla is primarily interested in, so those things can be given priority.
07:20:28 <piggz> rainemak: i sometimes feel like reporting something, to find its disabled ... i wonder why a forum is better for bugs rather than a bug tracker?
07:21:13 <flypig> nephros, perhaps that's something that will become clearer over time? It's hard to say, but regressions are particularly important.
07:21:27 <piggz> eg, the browser bug i recently reported to flypig .. issues is disabled for sailfish-browser
07:22:14 <flypig> We're coming to the end of allocated time on this topic. One more minute.
07:22:28 <rainemak> piggz, for changelog generation we need to have internal bz. I find it so that forum has lower entry barrier.
07:22:41 <pherjung> So we provide a list of bugs for the next community meeting?
07:23:08 <flypig> pherjung, let's try that. If you provide it in advance (maybe work to the 3 day requirement) then hopefully discussion at the meeting can be minmal.
07:23:18 <flypig> *minimal.
07:23:42 <flypig> Alright, we should move on. But I'd like to thank pherjung nephros and thilo[m] for their impressive work on this behind the scenes.
07:23:53 <pherjung> will be easy. Only pick from the list and let's go
07:23:54 <poetaster> yes, many thanks!
07:24:08 <flypig> #topic Structure EA phase with specific task (30 mins -- asked by pherjung)
07:24:08 <thilo[m]> All scripted ;)
07:24:14 <dcaliste> Yeh, thank you for this work on bugs. That's a very good initiative.
07:24:36 <flypig> We have another bug topic now as it happens.
07:24:38 <flypig> #info <pherjung> Seems EA phase is "let's try and catch them all".
07:24:42 <flypig> #info <pherjung> It works well, but sometimes some bug stay in the nature and appears once update is out of EA.
07:24:46 <flypig> #info <pherjung> Could it be a possibility to add a page to https://docs.sailfishos.org/Develop/Collaborate/ listing all things to test (Fingerprint, specific function, etc.) for each device.
07:24:51 <flypig> #info <pherjung> Then each user report what doesn't work in a new topic?
07:24:56 <flypig> #link https://docs.sailfishos.org/Develop/Collaborate/
07:25:08 <flypig> That's pherjung's question. Here's our initial response.
07:25:12 <flypig> #info <Jolla> Thanks for this question.
07:25:16 <flypig> #info <Jolla> The feedback we get from the community at all stages is a critical way for us to catch and understand bugs, so improvement to this process is worth exploring.
07:25:24 <flypig> #info <Jolla> We discussed this internally, particularly with our testing team, to see how it might fit in with their processes.
07:25:31 <flypig> #info <Jolla> When it comes to EA testing, the biggest area of risk is around regressions caused by changes.
07:25:39 <flypig> #info <Jolla> Consequently, the most beneficial focus for testing is on those areas listed in the Release Notes.
07:25:47 <flypig> #info <Jolla> As an immediate suggestion, if you'd like to propose a PR to add a "Testing advice" page under the page you suggested, then we can discuss it further on that PR.
07:25:58 <flypig> #info <Jolla> We have a plan to move the Known Issues section of the Release Notes to the documentation site, and once there it would make sense to reference this in the testing guidelines, to avoid duplication of effort.
07:26:10 <flypig> #link https://docs.sailfishos.org/Develop/Platform/
07:26:30 <flypig> Would you like to add anything pherjung?
07:27:00 <pherjung> Great! I'll take some time next week and submit an PR
07:27:21 <flypig> Excellent, that would be really good. Thank you pherjung.
07:27:22 <rainemak> Very good!
07:28:16 <pherjung> this will be discussed in more detail on GitHub. For me, we can move to the next topic
07:28:16 <flypig> We have quite a bit of time (30 mins) allocated here. We don't have to use it if that covers things?
07:28:44 <pherjung> Sorry, I overstimated...
07:28:53 <flypig> #info pherjung will take some time next week and submit a PR.
07:28:55 <poetaster> oh, I can make up for that.
07:29:00 <flypig> No worries, it's better to overestimate.
07:29:02 <poetaster> I underestimated.
07:29:07 <flypig> :D
07:29:07 <thilo[m]> Sometumes it easier than expected ;)
07:29:08 <pherjung> :)
07:29:14 <flypig> Alright, let's move on to the next topic then.
07:29:20 <flypig> #topic Using compass under Sailjail (5 mins -- asked by direc85)
07:29:21 <thilo[m]> s/Sometumes/Sometimes/
07:29:33 <flypig> #info <direc85> As I updated GPSInfo with appropriate Sailjail permissions, it turned out that compass isn't included in Location permission.
07:29:38 <flypig> #info <direc85> Compass works when Sensors permission is added (which makes sense), but Sensors permission should not be used by applications directly.
07:29:42 <flypig> #info <direc85> This makes GPSInfo and many other apps Harbour-incompatible.
07:29:48 <flypig> #info <direc85> Is compass going to be added to Location permission, Sensors added to allowed list, or can it be solved otherwise?
07:30:14 <flypig> direc85 isn't able to attend, but we have quite a long answer, so please bear with me.
07:30:27 <flypig> #info <Jolla> Thanks for this question. Access to the compass is a very reasonable requirement for apps.
07:30:34 <flypig> #info <Jolla> Up until now we hadn't done this because the sensor permission is quite broad (due to the way the dbus interface works, restricting it to just the compass is challenging).
07:30:42 <flypig> #info <Jolla> There also didn't seem to be many apps that required it.
07:30:50 <flypig> #info <Jolla> However, since this is needed, we now have a PR to add the Sensor permission to the Location permission group.
07:31:04 <flypig> #info (thanks to rainemak).
07:31:04 <flypig> #link https://github.com/sailfishos/sailjail-permissions/pull/122
07:31:09 <flypig> #info <Jolla> Please feel free to comment on that PR. In the meantime a workaround would be to use the Camera permission, which contains the Sensors permission.
07:31:15 <flypig> #info <Jolla> Note however that this may change in future, so should only be considered a temporary workaround.
07:31:21 <flypig> #info <Jolla> Likewise the Location permission may be tightened in future so that it doesn't allow access to non-compass settings.
07:31:21 <flypig> #info <Jolla> So please bear this in mind if adding these permissions to your app.
07:31:31 <flypig> #info <Jolla> In case someone wants to contribute to refining the permissions, all of the relevant code is open source. Some hopefully useful links follow.
07:31:39 <flypig> #info <Jolla> Location permissions
07:31:41 <flypig> #link https://github.com/sailfishos/sailjail-permissions/blob/master/permissions/Location.permission
07:31:45 <flypig> #info <Jolla> Sensors permissions
07:31:47 <flypig> #link https://github.com/sailfishos/sailjail-permissions/blob/master/permissions/Sensors.permission
07:31:50 <flypig> #info <Jolla> Allowed permissions
07:31:52 <flypig> #link https://github.com/sailfishos/sdk-harbour-rpmvalidator/blob/harbour-qa/allowed_permissions.conf
07:31:55 <flypig> #info <Jolla> SensorService DBus API tips
07:31:57 <flypig> #link https://docs.sailfishos.org/Reference/Core_Areas_and_APIs/D-Bus_APIs/#how-to-query-for-d-bus-apis
07:31:59 <flypig> #info <Jolla> sensorfw source (which provides the dbus interface)
07:32:02 <flypig> #link https://github.com/sailfishos/sensorfw
07:32:05 <flypig> That's all of 'em.
07:32:49 <flypig> We have some extra time to discuss this if anyone wants to, but as I mentioned direc85 couldn't make it this morning unfortunately.
07:33:05 <ExTechOp> As a side question, how usable is the current Sony Xperia 10II and 10III compass hardware support in SFOS? Earlier versions seemed to suffer from issues with getting it calibrated in the first place.
07:33:36 <flypig> rainemak, sledges, do you have some thoughts on that?
07:35:39 <nephros> while I'm not well versed in technical details, I wonder if haing a well-calibratied compass, and using a magnetic flip-cover/hall sensor mix well.
07:35:59 <flypig> Probably not!
07:36:03 <sledges> just checked compass works on 10II, cannot test III atm as it's being worked on other things
07:36:53 <flypig> Thank you sledges, good to know.
07:37:15 <rainemak> also 10III it seems to work but I only have raw data
07:37:29 <flypig> Oh, excellent, thank you also rainemak.
07:38:00 <flypig> Alright, well, I suggest we move on to the next question since we still have a couple more to cover.
07:38:17 <flypig> #topic Bluetooth passtrough to android (5 mins -- asked by stiray)
07:38:27 <flypig> #info <stiray> I have noticed that this option is rolling around the forums for quite a while.
07:38:34 <flypig> #info <stiray> It is not reasonable to expect that the applications for various bluetooth devices will be implemented natively in sailfish while on the other side market is full of various hardware with their proprietary android applications.
07:38:40 <flypig> #info <stiray> Avoiding buying something that at the end wont work with Sailfish is a bit of an annoyance, is there any effort to actually implement this?
07:38:45 <flypig> #info <stiray> I have read the specification for bluetooth "a bit" and the whole thing is a monster but probably there should be a way to present the bluetooth to the android container without implementing the whole stack.
07:39:15 <flypig> Is stiray with us? They said they may be able to join.
07:39:40 <flypig> I suppose not. Nevertheless, here is the initial answer we came up with.
07:39:44 <flypig> #info <Jolla> This has come up a couple of times before, and we apprecate that for many users, having Bluetooth support integrated with AppSupport is important functionality.
07:39:54 <flypig> #info <Jolla> As we have launched AppSupport as a separate product (see https://jolla.com/appsupport/) also the priority of this has increased, but as we noted back in June 2021, "We are looking into this, but we do not have any schedule to announce on this."
07:40:00 <flypig> #info <Jolla> There's no change from this statement at the moment.
07:40:04 <flypig> #link https://jolla.com/appsupport/
07:40:08 <flypig> #link https://irclogs.sailfishos.org/meetings/sailfishos-meeting/2021/sailfishos-meeting.2021-06-03-07.00.html
07:40:20 <flypig> A short answer, but we did cover this in previous meetings already.
07:40:38 <flypig> Does anyone else what to share thoughts on this?
07:40:45 <flypig> *want
07:40:59 <nephros> So, if there will be a "known issues" page separate from the release notes, maybe this topic should go in there as well - "known limitations" so it doesn't come up every 3 months.
07:41:01 <thilo[m]> Do you know what the probable solutions are?
07:41:54 <poetaster> i(ting)tooth
07:42:59 <flypig> nephros, that may not be a bad idea, but I'm not sure it would necessarily prevent the question being raised (which is fine really).
07:43:42 <nephros> flypig: yes, but it would be easier to point to to than a IRC log
07:43:46 <poetaster> don't we have a 'known to work' bluetooth page?
07:44:01 <flypig> nephros, that's true, yes, a good point.
07:44:33 <flypig> We have a list of working bluetooth devices. That one?
07:44:36 <flypig> https://forum.sailfishos.org/t/list-of-working-bluetooth-devices/8042
07:44:36 <poetaster> #info https://forum.sailfishos.org/t/list-of-working-bluetooth-devices/8042
07:44:49 <nephros> poetaster: there was a Forum post collecting working devices (peripherals) yes
07:45:38 <thilo[m]> What are most of the bt questions about? Headphones and smartwatches?
07:45:42 <flypig> I don't see any reference to AppSupport on that page though.
07:46:03 <poetaster> loudspeakers, car entertainment systems
07:46:07 <flypig> Headphones should already work with AppSupport, I think.
07:46:19 <flypig> At least, the audio part.
07:47:06 <abr> yeah the audio routing happens outside of appsupport. all audio stuff should work the same as it does in sfos.
07:47:35 <flypig> I get the impression that things like smartwatches, e-scooters, etc. are some of the main issues, because they have companion apps.
07:47:36 <rainemak> I'd like to see also this kind of "list of working bluetooth devices" to be moving towards docs.sailfishos.org
07:47:48 <thilo[m]> I played a bit with my bose headset to disable noise cancelling (which is only possible via app) and you need to send a magic string for that. For all devices which are only lacking some feature like this, we could improve the situation with a quite generic app
07:47:51 <nephros> thilo[m]: basically all kinds of "smart" devices which require Android apps and BT to configure. That's from headphones to washing machines...
07:48:41 <thilo[m]> Yeah, i see. There wont be a generic solution for escooters ;)
07:48:44 <flypig> rainemak, I guess we can promote moving it to docs in the thread itself, in case the maintainer would be willing to create the PR themselves.
07:49:43 <piggz> and if anyone wants to contribute more device supprt to amazfish, id be happy to share the burden!
07:50:30 <flypig> How many devices to you now support piggz?
07:51:16 <poetaster> PineTime, Amazfit Bip, GTS, GTR?
07:52:06 <piggz> bangle.js, gtr2/gts2, user just requested Bip-S-Lite
07:52:47 <flypig> An impressive and growing list.
07:52:49 <piggz> 15 devices exposed in ui
07:53:08 <flypig> Unfortunately I'm not sure what device the questioner specifically wanted BT connectivity for.
07:53:27 <piggz> attah: had an idea to start implementing more "health" type devices recently
07:54:50 <flypig> That sounds like a useful class to cover, for sure. I guess some care is needed in that area.
07:55:42 <flypig> Okay, we've made up for the time we saved earlier, so should probably move on. Does anyone want anything added ot the minutes on this topic?
07:56:11 <piggz> and someone else message me 2 days ago, asking about the posibility of creating a universal app that could send bytes to a bt device ... probably pretty easy if its just gatt
07:56:30 <piggz> the use case there was enabling thenoise cancelling function on some headphones
07:57:06 <poetaster> thilo[m], ?
07:57:31 <thilo[m]> Yes
07:57:42 <poetaster> thilo[m], how did you send the magic string?
07:58:07 <poetaster> not from sfos, or?
07:58:33 <nephros> piggz: that would be amazing, people could share config files for that like they share e.g. patches today.
07:58:47 <thilo[m]> On my pc I have a python script that opens a socket and sends it via that. Cant do it in sfos as bt-socket support is not compiled into python there
07:58:48 <piggz> yes, thats the idea i think
07:58:59 <piggz> thilo[m]: can you do it with the dbus api?
07:59:04 <thilo[m]> Exactly
07:59:46 <thilo[m]> I dont know, i searched around for a few hours but didnt come to a conclusion. This time i thought i gonna ask someone ;)
07:59:53 <pherjung> flypig: he wants to use a Sony WF-1000XM4. https://forum.sailfishos.org/t/bluetooth-support-in-android/3120/40
08:00:12 <flypig> Oh, nice find pherjung, thank you. What is that?
08:00:16 <pherjung> no idea
08:00:22 <pherjung> :D
08:00:38 <flypig> #info stiray is interested to use a Sony WF-1000XM4
08:00:47 <flypig> #link https://forum.sailfishos.org/t/bluetooth-support-in-android/3120/40
08:00:57 <flypig> :)
08:01:09 <flypig> Okay, we should move on, but thanks for all the nice discussion on this topic.
08:01:14 <flypig> #topic KCalendarCore & Co. (10 mins -- asked by poetaster)
08:01:14 <pherjung> Oh, it's a "Wireless Noice Cancelling Headphone". https://www.sony.com/lr/electronics/truly-wireless/wf-1000xm4
08:01:32 <thilo[m]> If someone can give me pointers, i can draft a generic app
08:01:55 <flypig> If that could "solve" stiray's probably, it would be great.
08:01:58 <flypig> #info <poetaster> Nemo-qml-plugin-calendar timeline for harbour?
08:02:06 <flypig> #info <poetaster> I would also be wiling to find a work-a-round to the use of the older libraries, libmkcal-qt5 libkcalcoren-qt5, but that has proven a bit difficult without docs.
08:02:11 <flypig> #info <poetaster> At the moment I basically have to do method for method comparison including mapping methods in extendedcalendar.h to new locations.
08:02:16 <flypig> #info <poetaster> I’d prefer to go with the qml-plugin solution.
08:02:20 <flypig> #link https://forum.sailfishos.org/t/nemo-qml-plugin-calendar-timeline-for-harbour/11119
08:02:41 <flypig> Here's our initial answer.
08:02:45 <flypig> #info <Jolla> Even though it provides a convenient interface, the nemo-qml-plugin-calendar API was primarily designed around the requirements of the Calendar app and other calendar functionality in the operating system.
08:02:47 <flypig> #info <Jolla> As such it's not ideally designed or implemented for third party app use.
08:02:53 <flypig> #info <Jolla> It looks like you've already had some fruitful discussion with dcaliste, pvuorela and martyone, on the forum.
08:03:01 <flypig> #info <Jolla> Your use the DBus interface (via QDesktopServices::openUrl) to import calendar events seems to be a good solution for what you need.
08:03:09 <flypig> #info <Jolla> To answer your question more generally though, while we don't have any immediate plans for supporting it in harbour, our advice for others would be to work with the mkcal API.
08:03:18 <flypig> #info <Jolla> A lot of effort has been put into updating mkcal and the calendar stack recently, not least by dcaliste and pvuorela.
08:03:24 <flypig> #info <Jolla> The mkcal API isn't fixed, but if we do decide to provide a harbour-compatible way to access calendars in the future, we think it's most likely to align closest to the mkcal API.
08:03:29 <flypig> #info <Jolla> Consequently it's also unlikely that nemo-qml-plugin-calendar will be harbour-supported in the future.
08:03:43 <flypig> Sorry, a bit of a long answer again.
08:03:45 <flypig> Just to mention poetaster, it's best not to edit your question inside the 3-day question window. I appreciate things moved on but it's just to avoid things getting confused!
08:03:55 <poetaster> Yeah, sorry about that.
08:04:20 <dcaliste> Thank you flypig for the detailled answer.
08:04:29 <flypig> No worries poetaster, but this is your earlier question I'm afraid.
08:04:53 <dcaliste> It's interesting to see that you may (at Jolla) thinking about allowing mKCal one day for calendar access.
08:04:56 <flypig> dcaliste, please do correct any errors in the answer!
08:05:05 <poetaster> I'm a bit unhappy with the situation since it means: work-a-rounds that don't get into harbout.
08:05:13 <dcaliste> As far as I know, everything is correct.
08:05:13 <poetaster> s/harbout/harbour/
08:05:40 <flypig> poetaster, I got the impression you do have a working harbourable solution though?
08:05:46 <dcaliste> poetaster, depends in my opinion on what is the requirement for calendar access.
08:06:01 <dcaliste> There are different scenarii:
08:06:27 <poetaster> I have a solution which will get into harour but introduces a memory leak and requires me to do file housekeeping.
08:06:33 <dcaliste> - add new events to the calendar (can be done somehow at the moment with openUrl() in a harbour compatible way),
08:06:57 <flypig> This is the openUrl approach?
08:07:02 <dcaliste> - display calendar events within the app (so read access), no current solution for harbour,
08:07:15 <poetaster> I also have 2 solutions which will not get into harbour. but only the DesktopService method is both 3.4 and 4.3 compatible.
08:07:24 <poetaster> but this latter point is not nof interest to jolla.
08:07:31 <dcaliste> - modify existing calendar events within an app (so write access), no current solution for harbour neither.
08:08:17 <poetaster> I think atomic adds is the most common case?
08:08:37 <dcaliste> The current Calendar permission allows both read / write access but is not allowed for harbour apps.
08:09:17 <flypig> And the current permission also doesn't address the availability of an API to use for harbour
08:09:49 <dcaliste> But in my opinion, the first case (addition to the calendar) may cover a good deal of cases and could be done via DBus instead of openUrl() which is leaking a file.
08:10:29 <flypig> So dcaliste, you would propose a permission for the dbus API being allowed in harbour?
08:10:53 <poetaster> Isn't higher level qml plugin the safer route?
08:11:35 <poetaster> Though I'd be happy with dbus, don't get me wrong :D
08:11:48 <piggz> reminds me, i need to port amazfish to a new calendar api, ithink the package im using is being dropped right
08:11:50 <dcaliste> Yes, I would like to add the importIcsData() method in Base.permissions. I need to create a PR so it can be discussed there, but I had not yet the time to do it :/
08:12:22 <poetaster> that would be great.
08:12:26 <dcaliste> piggz, ping me if you need assistance to do it. Or point me to the repo, so I can make a PR for you if you prefer.
08:12:46 <flypig> Seconded: that would be great. But the constraints on your time are totally understandable dcaliste.
08:13:31 <nephros> one idea: how about app-specific (local) calendars whch are read-write, while others are off-limits?
08:13:49 <dcaliste> poetaster, ss Jolla pointed out, the current nemo QML bindings are really calendar oriented. That could be interesting at one point, after mKCal stabilize to provides QML bindings for it though.
08:14:16 <dcaliste> nephros: I'm reworking mKCal API, and that should be soon possible.
08:14:41 <nephros> sounds cool!
08:14:53 <poetaster> dcaliste, perhaps a further plugin?
08:14:54 <dcaliste> I mean API would allow it from version that will be published in 4.5.
08:15:43 <piggz> dcaliste: id love a PR! https://github.com/piggz/harbour-amazfish/
08:16:20 <flypig> I'm afraid I need to move to general discussion, as we've already overrun. Anything to add to the minutes?
08:16:28 <poetaster> I have to admit, I'm also thinking about QML only apps and such being able to 'share' to the calendar.
08:16:34 <dcaliste> poetaster, why not, current mKCal is under going a large rewrite so it can be used threaded natively. Like that operation on the DB won't block the UI thread. This is done already in the nemo bindings but not in a satisfactory way in my opinion (it is duplicating all structures).
08:17:05 <dcaliste> poetaster, you would be able to do it if the DBus access is authorized.
08:17:32 <dcaliste> piggz, thanks for the pointer, I'll give a look, hopefully before the week-end.
08:18:08 <poetaster> ah, of course.
08:18:22 <poetaster> and thanks for all your help, btw!
08:18:35 <flypig> poetaster, sorry that this isn't the ideal answer you were hoping for, but I hope it's been a useful discussion nonetheless.
08:18:48 <flypig> Have to move on I'm afraid.
08:18:49 <flypig> #topic General discussion (10 min)
08:18:51 <poetaster> sure thing.
08:19:07 <flypig> You can now continue talking about the same if you like :)
08:20:42 <poetaster> I think I'll move on to a release :)
08:20:48 <pherjung> Have you already an estimation when 4.5 will be out?
08:20:53 <piggz> anyone eny thoughts on building sailfish on halium?
08:20:56 * pherjung flies far, far away
08:21:13 <flypig> :D No estimation I'm afraid.
08:21:30 <poetaster> oh, god, I forgotten what halium is.
08:21:42 <poetaster> (caldav with do that to ya)
08:21:50 <piggz> flypig: have there been any major issues with 4.4 that would nescessitate a 4.4.x?
08:22:09 <flypig> Could you elaborate on halium (just for the logs, of course) piggz?
08:23:01 <flypig> jpwalden, do you have any thoughts about piggz's query? Concerning 4.4.x issues?
08:23:10 <piggz> flypig: well, im not 100% clear on it all myself yet ... but the halium android rootfs runs inside an lxc container .... would mean ports would share the same android runtime, instead of all porters building DHD individually
08:23:25 <ExTechOp> https://en.wikipedia.org/wiki/Halium
08:23:41 <poetaster> cool, thanks.
08:23:50 <piggz> notkit demo;d itt o me for the pro1-x port .. som, im currently running with that fr the port
08:24:23 <flypig> Very interesting indeed. Can we add a line to the minutes about it?
08:24:31 <piggz> sure
08:25:10 <flypig> #info piggz asked about building Sailfsh OS on Halium.
08:25:31 <flypig> #info <piggz> the halium android rootfs runs inside an lxc container .... would mean ports would share the same android runtime, instead of all porters building DHD individually
08:25:48 <poetaster> re: the generic bluetooth app, this came to mind: https://openrepos.net/content/jdrescher/obdfish
08:26:20 <flypig> #info <piggz> (edited) notkit demoed it to me for the pro1-x port .. so, i'm currently running with that for the port
08:26:32 <flypig> (hope I understood that correctly)
08:26:37 <piggz> thx for fixing typos:)
08:27:18 <flypig> #info <poetaster> re: the generic bluetooth app, this came to mind
08:27:26 <flypig> #link https://openrepos.net/content/jdrescher/obdfish
08:27:33 <flypig> Thanks poetaster.
08:27:59 <flypig> One more minute before we wrap up. Any final thoughts?
08:29:07 <flypig> #topic Next meeting time and date (2 min)
08:29:09 <ExTechOp> The previous release of SFOS had an issue with applications disappearing, the current seems to have an issue with them appearing multiple times?
08:30:03 <flypig> ExTechOp, I think one for the next meeting (or maybe some chat after).
08:30:09 <flypig> Proposing Thursday 28th April at 07:00am UTC
08:30:26 <flypig> Any objections?
08:30:34 <ExTechOp> Works for me
08:30:45 <dcaliste> Nope, it's fine for me also.
08:30:51 <flypig> Thanks ExTechOp, dcaliste.
08:30:51 <flypig> As with this meeting, it may have to be moved, but hoepfully not.
08:31:03 <flypig> Let us go with that then.
08:31:04 <flypig> #info Next meeting will be held on Thursday 28th April 2022 at 07:00am UTC:  2022-04-28T0700Z
08:31:10 <flypig> As always, thanks for the really nice discussion today. We covered a lot of ground.
08:31:20 <flypig> #endmeeting