07:59:59 <sledges> #startmeeting Sailfish OS, open source, collaboration -- 11th February 2021
07:59:59 <sailbot_> Meeting started Thu Feb 11 07:59:59 2021 UTC. The chair is sledges. Information about MeetBot at http://wiki.debian.org/MeetBot.
07:59:59 <sailbot_> Useful Commands: #action #agreed #help #info #idea #link #topic.
08:00:14 <sledges> #info Meeting information and agenda can be found here:
08:00:22 <sledges> #link https://forum.sailfishos.org/t/community-meeting-on-irc-11th-feb-2021/4306
08:00:27 <sledges> I am the meeting's chairperson today, and will be doing my best to keep time and order. Please behave, and respect cambelt timing.
08:00:34 <sledges> #topic Brief introduction (5 min). Please prefix your name/handle with #info
08:00:41 <sledges> #info Simonas Leleiva -- privateer for Jolla
08:01:03 <Mister_Magister> #info Mister_Magister - community member
08:01:03 <sledges> (double #startmeeting Irish-style - "to be sure, to be sure!")
08:01:12 <santhoshm> #info Santhosh Manikandan - Community member
08:01:19 <ljo> #info Leif-Jöran Olsson, community member
08:01:23 <Zyuc2G> #info Zyuc2G community member
08:01:33 <fridl> #info fridlmue - community
08:01:39 <Mister_Magister> sledges: nice to see you!
08:01:58 <karry> #info Lukas Karas - developer, community member
08:02:00 <cartron> #info Nico Cartron, community member
08:02:03 <ViGe> #info Ville Nummela - sailor@Jolla
08:02:04 <jpetrell> #info Joona Petrell, Jolla sailor
08:02:16 <flypig> #info David Llewellyn-Jones, sailor@jolla
08:02:22 <abranson> #info Andrew Branson, Jolla
08:02:28 <sledges> o/
08:05:13 <sledges> #topic Url aware .desktop file opening (15 min -- asked by Mister_Magister)
08:05:20 <sledges> #info <Mister_Magister> So I made merge request to libcontentaction that allows devs to specify url domain so that if user clicks link with domain that matches specified it will open said app.
08:05:30 <sledges> #info It's done extremely easy and extremely robust all i did was to in case of x-scheme-handler/https mimetype extract domain from url and convert it into x-url-handler/<domain> mimetype. Then apps can just add x-url-handler/youtube.com or x-url-handler/* in order to handle specific domains.
08:05:46 <sledges> #info That's it, all mimetype handling and everything is left as it was. I and other devs would love to see it in upstream. It doesn't break anything because if it doesn't find any x-url-handler that would match it just falls back to standard mode.
08:06:05 <sledges> #info <Jolla> We need better heuristics for sure, current way apps register for mime types it too rudimentary. Overall URL aware file opening sounds great, just need to take into account that the user may want to open Twitter and YouTube links with regular browser.
08:06:06 <Mister_Magister> This is a bit out of date, i'm in contact with jolla employee so this topic serves as nothing else than bringing atention
08:06:29 <cartron> so this will likely make it to a next update? cause that's a nice feature indeed
08:06:49 <jpetrell> sounds likely
08:06:52 <Mister_Magister> cartron: maybe not next, but probably will make it into sfos
08:07:13 <Mister_Magister> i've been working with pvuorela on all changes that needs to be done
08:07:15 <cartron> cool
08:07:23 <ViGe> next update == the update after 4.0.1
08:07:42 <Mister_Magister> maybe update after that
08:07:49 <Mister_Magister> or 2 updates after that
08:08:02 <cartron> yeah of course - i don't expect new stuff coming after 4.0.1's EA :)  good to know, thx
08:08:22 <Mister_Magister> because even if 4.0 is EA jolla already is preparing next release and making it ready… so release after next release
08:08:38 <Mister_Magister> if it gets merged ofc
08:09:41 <flypig> Mister_Magister, can app devs already start putting hints in their desktop files for when it does arrive?
08:10:01 <Mister_Magister> flypig: hell you can even test it, test lib is released on openrepos
08:10:21 <Mister_Magister> and yeah you can, its not like it will break anything
08:11:30 <Mister_Magister> flypig: thing is, if you need to catch specific url you wiill have to remove x-scheme-handler/http once it gets merged
08:11:52 <flypig> Okay, that's good to know.
08:12:02 <Thaodan> #info Björn Bidar - sailor @ jolla
08:12:11 <Thaodan> had connection issues..
08:12:26 <Mister_Magister> before its included you can just add that mimetype so that users that use my lib from openrepos can enjoy it
08:12:42 <sledges> is there a demo/video about this feature?
08:12:50 <sledges> so those reading minutes can have a visual
08:13:00 <Mister_Magister> there's a video https://twitter.com/Mister1Magister/status/1357839807301435392
08:13:05 <sledges> #link https://twitter.com/Mister1Magister/status/1357839807301435392
08:13:35 <Thaodan> I think it makes sense to test Mister_Magisters lib by the community for everything later down the line
08:14:13 <Mister_Magister> yep! i'll be more than welcome for any feedback
08:14:34 <Thaodan> IMHO this should go also to freedesktop.org since it extends the mime type handling which is part of that standard
08:14:45 <Thaodan> It would make sense for others to adapt that
08:15:29 <abranson> Well I think it's great. I wondered if it should have used x-domain-handler, but as the PR now talks about including fragments of the path after, url is fine.
08:15:43 <Mister_Magister> Well, from the talks with pvurela, functionality changed a bit and the additional mimetype will be just additional mimetype
08:15:57 <Mister_Magister> with conversion functionality
08:16:39 <Mister_Magister> abranson: greatest thing about this change is that its simple and robust and super easy to implement in apps
08:17:02 <abranson> btw, if you need to include things like forward-slashes in the second mimetype element, you could use quoted printable like when urls are encoded in others. / => %2f
08:17:17 <abranson> Mister_Magister: yeah. "elegant" is the word :D
08:17:45 <Mister_Magister> abranson: but urls can contain @2f
08:17:53 <Mister_Magister> aaand whole parsing goes bad
08:18:08 <abranson> %25 <> %
08:18:15 <Mister_Magister> for separator you need something that urls for sure don't have
08:18:16 <sledges> 2mins remain
08:18:18 <abranson> there are libs that can unmunge that for you
08:18:38 <abranson> it's the standard way to encode URLs
08:18:47 <Mister_Magister> not sure what u mean but you can leave feedback in mr
08:18:50 <Mister_Magister> https://git.sailfishos.org/mer-core/libcontentaction/merge_requests/18
08:18:58 <Mister_Magister> sledges: maybe we should link this^
08:19:14 <dr_gogeta86> maybe this is the reason other platforms use protocols intested of uris
08:19:23 <dr_gogeta86> or a mix and match
08:19:24 <sledges> #link https://git.sailfishos.org/mer-core/libcontentaction/merge_requests/18
08:19:25 <flypig> Anyone can link, I think, can't they?
08:19:29 <Mister_Magister> possible
08:19:34 <Thaodan> They also use uris
08:20:23 <sledges> time's up, anything else?
08:20:27 <abranson> yeah, we'd be able to integrate android apps with this
08:20:54 <dr_gogeta86> like bangood
08:21:17 <Mister_Magister> sledges: not from me
08:21:18 <dr_gogeta86> with sfos browser i dunno why tries to open their app url scheme
08:21:45 <sledges> ok, moving on, will re-discuss when MR shapes more
08:21:46 <sledges> #topic SFOS 4.0 UI element changes (10 min -- asked by KeeperoftheKeys)
08:21:52 <sledges> #info <KeeperoftheKeys> In SFOS 4.0.1.45 several QML UI elements have stopped working, so far for gPodder I found IconContextMenu and IconMenuItem to have stopped working.
08:22:00 <sledges> #info – Are these items being removed or will this be fixed before GA?
08:22:07 <sledges> #info – Where can we find a list of changes to QML UI elements?
08:22:15 <sledges> #info – What is the recommended new UI item to use that will allow the application to render properly both in SFOS 4.x and in old SFOS (the work around I have found for IconContextMenu does not render properly on SFOS 3.x)?
08:22:35 <sledges> #info <Jolla> We need to review your code to see what is broken. By IconContextMenu do you mean IconComboBox? IconComboBox and IconMenuItem make up a combo box variant that was just introduced after the last public release 3.4.0 so both are new components that haven't been documented yet.
08:22:54 <sledges> #info <Jolla> The new variant is currently only used in People app. There has not been changes to the two components after the initial introduction in internal release 4.0.0, though it is possible some component they depend on broke.
08:23:09 <sledges> #info <Jolla> We list UI Component area changes in OS release notes, but overall the release notes are not developer oriented so lack API level details. SDK release notes related to SDK, which is not directly bound to an OS so it is not good place to list API changes.
08:23:23 <sledges> #info <Jolla> We have recently discussed that we should write more about the new APIs in the Sailfish Forum, for example now about the new notification API and Silica TextField/TextArea API changes introduced in 4.0.1.
08:23:49 <sledges> KeeperoftheKeys looks AWOL :)
08:26:17 <sledges> since this looks a potential breakage, will need to chase the author through forum to analyse the code
08:26:33 <jpetrell> yeah
08:26:58 <sledges> haven't seen feedback from other apps breaking in this way though
08:27:50 <jpetrell> IconMenuItem and IconComboBox were introduced in 4.0.0, which was only accessible by CBeta
08:28:15 <jpetrell> I could not find IconContextMenu, so assuming IconComboBox was meant
08:28:59 <chriadam> (I assume you already checked, but could that IconContextMenu have been very old, e.g. 2.x.x days?  and since removed?)
08:29:34 <jpetrell> I checked 3.4.0, but not 2.x.x old
08:30:20 <fridl> I find it in the code here: https://github.com/gpodder/gpodder-sailfish/blob/e97804a98b21df934115280d072d80b54be500cc/qml/PodcastItem.qml#L28
08:30:46 <ViGe> https://github.com/gpodder/gpodder-sailfish/blob/master/qml/IconContextMenu.qml
08:31:33 <jpetrell> ah so it is name conflict
08:32:05 <jpetrell> IconMenuItem was introduced in Silica, Silica import overruled his local IconMenuItem
08:32:40 <sledges> #link https://github.com/gpodder/gpodder-sailfish/blob/e97804a98b21df934115280d072d80b54be500cc/qml/PodcastItem.qml#L28
08:32:44 <sledges> #link https://github.com/gpodder/gpodder-sailfish/blob/master/qml/IconContextMenu.qml
08:32:55 <sledges> #info IconMenuItem was introduced in Silica, Silica import overruled their local IconMenuItem
08:33:08 <jpetrell> that is always a risk unless you write import Sailfish.Silica 1.0 as Sailfish ... Sailfish.IconMenuItem to explicitly say what module the component should come from
08:33:14 <ViGe> well, it's easy for him to fix that :)
08:34:22 <jpetrell> We try to find intuitive, natural names for the new components so unfortunately these kind of risks hard to avoid
08:34:46 <sledges> #info looks like an easy fix, and tip for the future:
08:34:52 <sledges> #info to reduce name conflict risk, write import Sailfish.Silica 1.0 as Sailfish ... Sailfish.IconMenuItem to explicitly say what module the component should come from
08:35:06 <sledges> #info We try to find intuitive, natural names for the new components so unfortunately these kind of risks hard to avoid
08:35:26 <sledges> we're overtime on this one, i think it can conclude here
08:35:44 <sledges> #topic General Discussion (30 min)
08:36:54 <fridl> In discussion with some other Dev we discovered, that a qml CoverBackground{ } behaves unexpected: When setting transparent: false the cover is fully transparent, when setting transparent: true it looks "normal" with half transparent BG. Is that Expected or a Bug? And I would recommend either way to ad a line for that in the Documentation  way.
08:38:05 <ApB> am i the only one that expected more with SFOS 4 or no?
08:38:16 <Nico[m]> #info Nico, Community
08:38:17 <jpetrell> yeah it was a naming mistake we did. transparent covers should have glass backgrounds so transparent: true means "with glass background"
08:38:44 <jpetrell> you only set it off if you have your own background like how some covers are fully opaque
08:39:21 <fridl> jpetrell: Ok, so giving some hint in the Doku would be nice :-)
08:39:28 <jpetrell> indeed
08:41:01 <fridl> thanks :-)
08:41:28 <fridl> is there another EA-Release planed before the public one for 4.0.1?
08:42:09 <ApB> with all the bugs found its quite possible
08:42:21 <ApB> at least thats what has happened in the past
08:42:59 <ApB> i read a lot of comments in the forum about  bash. since gpl3 is problematic why not change the shell in something liek zsh?
08:43:04 <Nico[m]> Since Sailfish 4 removed statefs, only Qml provides an easy API to access context properties. A lot of those APIs are used in the backend usually, could you maybe add a C++ API back? Then applications could access network status and all the other properties even when they don't currently have a Window, which is useful for messaging applications and System monitors.
08:43:52 <sledges> about EA vs final -- good things come for those who wait;) (applies to other actualities, too:))
08:44:35 <ApB> sledges the community is not patient :D
08:45:07 <chriadam> ApB: I actually think that Sailfish OS 4 is a pretty huge milestone.  the fundamental building blocks for basic application sandboxing are in place.
08:45:21 <chriadam> the browser was updated significantly.
08:45:35 <flypig> Nico[m], was there something particular? There should be APIs for most/all things.
08:45:39 <chriadam> the contacts backend now supports properly separated addressbooks with full sync transaction support.
08:45:42 <Mister_Magister> i've also heard that my multicamera patches are picked up by mal and being worked on!
08:45:49 <ApB> chriadam while sandboxing is nice i feel that there are other more important issues to be fixed
08:46:07 <jpetrell> ApB: bash was replaced with busybox sh in 4.0
08:46:25 <chriadam> ApB: a matter of opinion, I guess.  I see security as the #1 topic that we need to work on, haha.
08:47:06 <Nico[m]> flypig: contextkit just has a much nicer API than calling 5 different APIs to access those properties
08:47:34 <ApB> jpetrell yes i know. but i've seen quite a few comments about bash and intalling it so i had to ask. anyway
08:47:44 <flypig> Nico[m], I can appreciate the convenience, yes.
08:48:01 <chriadam> Nico[m]: this is just a personal opinion, but I prefer there being "one canonical way" to do each thing, rather than having multiple ways including wrappers around other things, etc.
08:48:13 <ApB> chriadam we lack features at the moment.
08:48:31 <chriadam> Nico[m]: you know my mantra: reduce platform surface, reduce external dependencies ;-)
08:48:47 <chriadam> ApB: of course, I'd never dispute that
08:49:24 <Nico[m]> chriadam: Well, I would like to just always use the context properties on Sailfish, instead of using different APIs in Qml vs C++
08:49:24 <ApB> any updates on the API polls we run a few weeks back
08:49:31 <rinigus> Nico: how removed the statefs is in 4.0? can it be installed via pkcon install if it is needed?
08:49:39 <ApB> qt possitioning made it in but what about the rest that are high on the list
08:49:52 <Nico[m]> rinigus: No, afaik it is gone
08:49:55 <flypig> Nico[m], there's an opening for a community lib to pull the APIs together.
08:50:29 <Nico[m]> flypig: Fair enough :D
08:50:47 <rinigus> Nico: thanks. that's bad news for me. as collectd (pure C) is using it for stats
08:52:03 <Nico[m]> rinigus: Well, I only looked at the old contextkit-statefs stuff, that was removed, which provided a nice C++ Api around it
08:52:10 <flypig> Nico[m]: I don't mean to be flippant about it. All I mean is that, whoever needs the API is usually best-placed to formulate it.
08:52:34 <ViGe> ApB: Not much to update about the APIs. You can check the results of the polls yourself if you are interested. The results have been used in planning future work, but for most of the APIs the situation is that they will take a lot of work and time.
08:52:58 <Nico[m]> flypig: No, I just laughed because it could taken that way :3
08:53:12 <Nico[m]> I liked the C++ API, that got removed :3
08:53:45 <pvuorela> Nico[m]: something specific you'd need?
08:54:18 <ApB> ViGe yeah. i just wanted to know if there has been any work from jollas part
08:54:27 <Nico[m]> pvuorela: Just the contextkit Qml API accessible from C++ would be nice :3
08:54:32 <sledges> #info (discussing about statefs having been removed in SFOS 4 and [new] API alternatives)
08:54:35 <rinigus> ok, will have to see what was removed regarding statefs packages specifically when I get to 4.0.
08:55:02 <sledges> #info API poll concluded and it will be prioritised accordingly in the SFOS roadmap
08:55:10 <pvuorela> Nico[m]: i mean specific properties. lot of the things imght be accessible by other means and by more proper api.
08:55:39 <rinigus> pvuorela: would be great to have API (pure C) to access stats regarding battery, network, and such. so far, statefs was filling that role
08:56:35 <chriadam> where was statefs getting its data for those things from?  mce?
08:56:53 <pvuorela> for c++ the qtnetwork stuff might help.
08:57:05 <Thaodan> The pure c api would be /sys and /proc probably
08:57:21 <Nico[m]> pvuorela: I know, that everything is accessible via different APIs, contextkit just gives nice unified access to all og them, as I need them. I'm pretty sure it just uses dbus for all of that or so
08:58:01 <rinigus> chriadam: good question. don't know, looks like there are several providers involved: mce, power-udev, ofono
08:58:30 <Mister_Magister> you guys still going :O
08:58:39 <Nico[m]> This is purely for convenience :3
08:58:53 <rinigus> Thaodan: not sure I can get (as regular user) cell network signal strength from /proc or /sys, for example
08:58:58 <Nico[m]> (and symmetry with Qml)
08:59:28 <Thaodan> Not sure about cell network but everything else would be there
09:02:16 <rinigus> was something breaking in statefs or it is dropped to avoid maintenance? I wonder if we can just pull the source and build  it on OBS for those who are interested in using it?
09:02:53 <flypig> Nico[m], back in December you suggested we should do some periodic "community updates". We're looking seriously into going ahead with this.
09:03:31 <chriadam> rinigus: ask pvuorela ;-)  I think it was mostly the maintenance burden, and the tentacles / dependencies.
09:03:37 <chriadam> but I may be wrong
09:03:56 <chriadam> either way, I'm personally happy that it's gone haha.
09:04:04 <Thaodan> There was also duplication between contextkit
09:04:11 <Nico[m]> flypig: That would be lovely. I really enjoy doing updates for "This week in Matrix" already :3
09:04:21 <ViGe> rinigus: maintenance burded was probably the biggest reason. Way too much work for an API which was only used by two apps in Harbour.
09:04:23 <Thaodan> I only like the plan9 style filesystem
09:04:38 <Thaodan> api it provided.
09:04:45 <fridl> No one will answer me, if I would ask when we can officially expect, that the 10 II candidate really is the next device and tell us expected release date, right ;-)
09:05:01 <flypig> Nico[m], we already had a good discussion about it at a previous meeting, but any tips are appreciated.
09:05:10 <pvuorela> statefs was pain. often it was d-bus proxy for d-bus interfaces, code that was hard to maintain, context data requests by strings easy to typo, results and errors quite untyped.
09:05:18 <flypig> And please keep an eye out in the Platform Development section of the forum. I'll make a post there, and as was discussed previously, we'd love to get everyone's input.
09:05:25 <chriadam> fridl: I have no idea, sorry.
09:07:09 <Nico[m]> flypig: Well, I don't remember, if it was discussed, but TWIM in the Matrix universe does ig pretty well imo. You basically have one room, where everone posts their updates over the week with a TWIM prefix, and it gets picked up half automatically and then compiled and cleaned up for a blog post
09:08:01 <fridl> chriadam: sure ;-)
09:08:34 <flypig> Nico[m], I see your posts there. Neat.
09:08:41 <Nico[m]> This happens every friday, so of you want to see it in action, I suggest checking it out tomorrow
09:09:40 <sledges> fridl: currently it's tech. development which will move on to community joining forces on the overall Android 10 hw adaptations
09:10:01 <flypig> Thanks Nico[m], I'll check it out :)
09:10:23 <chriadam> half automatically?
09:11:01 <Nico[m]> Thanks for actually following up on that, I really like TWIM, it helps me motivate myself and advertise cool features :3
09:11:16 <sledges> #info back in December Nico[m] suggested we should do some periodic "community updates". We're looking seriously into going ahead with this. Subscribe to "Platform Development" forum section for new topics ;)
09:11:51 <sledges> we're 6min overdue:) let's press on brakes here
09:11:57 <rinigus> pvuorela: thanks for insider view on statefs :)
09:11:59 <sledges> #topic Next meeting time and date (5 min)
09:12:07 <sledges> Proposing Thursday 25th February at 8am UTC
09:12:13 <Nico[m]> chriadam: Basically benpa has a bot, that reacts to the TWIM message prefix or specific reactions, and automatically adds them to a lisy for a post. He then only needs to proofread and fix up issues.
09:12:44 <chriadam> sounds useful indeed
09:12:54 <chriadam> sledges: sounds fine to me, consider +1
09:13:06 <santhoshm> @ni
09:13:24 <santhoshm> Nico[m] TWIM looks cool.
09:13:31 <sledges> #info Next meeting will be held on Thursday 25th February 2021 at 8:00am UTC:  2021-02-25T08Z
09:13:44 <sledges> with 45mins to spare before lunchtime in Finland!
09:13:44 <Zyuc2G> I put in my question regarding GPLv3 too late for this meeting, please don't forget to it to the next one. Thanks!
09:13:56 <sledges> Zyuc2G: will address your topic in a fortnight
09:14:00 <Nico[m]> For reference: https://github.com/matrix-org/twim-o-matic is the bot
09:14:01 <Zyuc2G> thank you
09:14:02 <sledges> ah, you wrote too:))
09:14:19 <chriadam> thanks everyone
09:14:28 <sledges> give us at least 3 days next time with topics;) cheers!
09:14:46 <Zyuc2G> will do. Only occurred to me after looking at some git commits ;)
09:15:05 <sledges> #endmeeting