15:00:08 #startmeeting SailfishOS, open source, collaboration: 9-September-2014 15:00 UTC 15:00:08 Meeting started Tue Sep 9 15:00:08 2014 UTC. The chair is Stskeeps. Information about MeetBot at http://wiki.merproject.org/wiki/Meetings. 15:00:08 Useful Commands: #action #agreed #help #info #idea #link #topic. 15:00:11 #info Welcome to another week of SailfishOS OSS and collaboration meetgin ;) 15:00:23 #info Meeting info and agenda: https://lists.sailfishos.org/pipermail/devel/2014-September/004996.html 15:00:30 I'm the meeting chair for today and will be keeping time and order. Please behave and show mutual respect, and let's have a productive discussion! 15:00:37 #topic Brief introductions (5 min), prefix your information with #info 15:00:47 meetgin :D 15:00:52 #info Thomas B. Ruecker, community member, works on push notifications and Chum community repos 15:01:04 * tbr has his meetgin right here, see twitter 15:01:13 #info Aleksi Suomalainen, community member 15:01:15 #info Simonas Leleiva, community sailor 15:01:20 #info Siteshwar, community member 15:01:41 #info Andrea Bernabei, nemomobile contributor and community member 15:01:49 #info Kimmo Lindholm, community member, toh-tailor 15:02:06 #info Alfred Neumayer, Community maintainer of SailfishOS for Galaxy Nexus port and GNU/Linux enthusiast 15:02:16 \o meetgin ! 15:02:21 #info Lewis Rockliffe, resident australian and community member 15:02:37 #info Val�rio Val�rio, Sailor, community member 15:02:40 #info Steph Gosling, community 15:02:47 #info Carol Chen, community chief @ Jolla 15:02:52 #info Bob Summerwill, (new) community member, working on Mono for Sailfish 15:03:31 #info Iekku Pylkk�, developer community + developer care @ jolla, community member, mer & nemo community member 15:03:44 welcome bobsummerwill 15:03:44 #info David Greaves : Mer guy and Sailor 15:03:47 bobsummerwill: welcome! glad to see you here :) 15:03:49 bobsummerwill, welcome 15:03:58 #info Martin Kolman, community member, modRana developer 15:03:59 Thanks, guys! 15:04:58 #info Mohammed Hassan, FOSS hacker and Jolla sailor (Mostly listening) 15:05:08 #info Michael Demetriou, community member 15:05:48 #topic App settings integration for third party applications (10 minutes) 15:05:49 #info Fabio Isgro' enthusiast , community 15:06:28 Some details about the topic: Currently it is not possible for third 15:06:28 party applications to integrate their settings into the official 15:06:28 settings page of the settings system application if they are published 15:06:28 via Harbour. 15:06:28 Additional Q by kimmoli: How about settings for iconless apps, like 15:06:30 daemons (e.g. toholed) ? 15:06:38 Armadillo_ ? Also noted on item optionally tbr or SK_Work? - if you'd like to introduce the topic further? 15:06:41 so, is the guy who proposed it here? if not sk or me can help 15:07:00 whois says 'nicht da' :) 15:07:06 :) 15:07:41 ok, well it's pretty clear already, some jolla statements said it would be possible in the future, it's time to revisit 15:07:48 how's status, is it going to happen? 15:07:54 this is a feature I would also like to see happen, in fact i'm surprised that its not part of the design 15:08:42 seems like a perfect, standardised way to locate app settings without clogging up user interfaces in the apps themselves 15:08:54 do we have an explanation of why it's not just done 'out of the box' ? 15:09:08 afaik its a permissions issue 15:09:10 r0kk3rz: I think it's one of those "oh, yeah, damn, but we can't do this because needs $permission" things and then it dropped through the priority floor 15:09:22 it's been planned from the beginning and per se possible already, but we wanted some protection for system settings before third party settings get supported. 15:09:23 (and all soil is there: all 3rd pty apps are simply greyed out..) 15:09:32 I suspect it's to do with running app provided QML/js code in a core jolla application 15:09:33 lbt: there is an TJC item, something about "settings has privs that it shouldn't have" 15:09:47 e.g. running the third party side on separate containers. 15:10:03 jolla-settings gets run as privileged. 15:10:04 (ah, topic is about slots in System/ ;P that looks already cluttered up imho) 15:10:15 nah, in applications/ 15:10:20 which is nice ui to show it in 15:10:27 you know the greyed out application grid 15:10:39 which nobody uses and nobody knows about because nobody uses it 15:10:43 18:06 <@Stskeeps> settings page of the settings system application if they are published 15:10:57 better to show just enabled/ suppported 15:11:11 IIRC it was already almost the same situation with Harmattan 15:11:18 yeah 15:12:03 just speaking on a very technical basis, couldn't tapping there strictly speaking call a .desktop file with a different command parameter to launch settings of an app? not sure if it would be good ui 15:12:10 IMO I would drop that "applications" page altogether 15:12:24 there we go 15:12:27 qwazix: where would the settings live? 15:12:28 it just seems pointless to have a whole section of the settings menu for 6 apps 15:12:45 stephg: where they already do, in apps 15:12:50 app settings belong inside the apps, and now that it's already inconsistent, it's easier for jolla to move the settings of the 4 apps into the apps than the other way around 15:12:55 stephg: because nobody can use the proper settings 15:13:15 manipulating the desktop icon would not be very discoverable 15:13:20 qwazix: I'm sure some designer will scream murder over this :) 15:13:25 Stskeeps: possible, yeah, but if that's not a good ui then it's nothing. 15:13:42 Stskeeps: that may be a way to make it work quickly 15:13:46 but i guess this also shows into a wider problem anyway, plugins into let's say, messaging, etc 15:13:46 How about instantiating the 3rd party QML in its own "qml context"? 15:13:49 or other places 15:13:57 i quite like the idea of splitting it up, settings are usually things that you dont look at very often, if ever 15:13:59 and then to extend that api to a more integrated one in future 15:14:01 .. and i don't want to dive into nested wayland compositors ;) 15:14:04 QQuickContext (or whatever it is called) 15:14:08 MSameer: needs to be a separate process. 15:14:26 tar, I'm also sure, after all if Apple does it it must be the Right Thing, but I still believe it's stupid 15:14:31 tbr* 15:14:34 MSameer: qml runs arbitrary c++. 15:14:37 i could live with separate "settings app" etry in .desktop (as i dont have main app) 15:14:43 we're running out of time 15:14:55 so there is no statement from jolla? 15:14:58 well, it worked fine on the N900 for the various daemons 15:14:59 we could solve 90% of the use cases by calling /usr/bin/harbour-app --settings for those which advertise support 15:15:12 so there are two questions it seems: drop privs in settings or drop the whole Applications thing from settings altogether 15:15:29 lbt: +1 15:15:43 lbt: +1 15:15:44 I think it was a good Idea to have settings centralized on the apps page 15:15:53 tbr: in practice it hasn't moved on, but we haven't gotten as far for the security aspect as we would have wanted. 15:15:56 Applications in settings seems good to me - it's just a little sparse atm 15:15:58 stephg: the question was if jolla has done anything or plans to do anything. the answer is "couldn't be arsed, had different priorities it seems" 15:16:02 the problem seems very real 15:16:05 I could do that very easily in modRana 15:16:13 as i can imagine it makes 3rd party apps inconsistent 15:16:29 stskeeps +1 15:16:32 Stskeeps: provide a template settings page 15:16:40 #info 18:09 < pvuorela> it's been planned from the beginning and per se possible already, but we wanted some protection for system settings before third party settings get supported. 15:16:42 tbr: nice summary 15:16:46 s/provide/jolla provides/ 15:16:52 consistency is the key 15:17:02 cybette: it's far more important to info what Stskeeps said 15:17:05 #info 18:15 <@Stskeeps> tbr: in practice it hasn't moved on, but we haven't gotten as far for the security aspect as we would have wanted. 15:17:12 beta channel for store haven't been getting done as fast as we thought, so it most propably will delay from original estimate ie autumn 15:17:18 cybette: as pvuorela just described the status quo already known 15:17:22 when we have it in place it might help a bit 15:17:32 anyway we exceeded the timeslot by 2min 15:17:34 as beta would be a way to integrate more experimental apis as well.. 15:17:38 tbr: just providing more info for people reading about this in minutes :) 15:17:43 tbr: just out of interest - what would we stop working on to work on this ? 15:17:50 yeah.. i think 10 mins isn't enough for this topics 15:17:51 let's move on 15:18:01 tbr: tbd later? :D 15:18:03 lbt: show me your backlog and I will tell you 15:18:07 ;) 15:18:12 i'll propose to take kimmoli's question in the wrapup 15:18:19 we need another slot for this :) 15:18:35 #topic Close vs open parts, why is there closed middleware ? (SK_work) 15:18:45 i don't see Sfiet.. 15:19:03 obvious enough, let's still have it? 15:19:26 yeah - Chris Adams posted a good post at 15:19:26 do we have any examples ? 15:19:30 #link https://lists.sailfishos.org/pipermail/devel/2014-September/005002.html 15:19:34 I could inject the question for opening bits of the UI where there is significant interest 15:19:44 e.g. the message app 15:20:00 it doesn't support multi-user and other things, underlying frameworks do 15:20:06 . o O ( please media ) 15:20:08 eg. com.jolla.mediaplayer 15:20:11 there is community interest 15:20:17 regarding the specific case mentioned in https://lists.sailfishos.org/pipermail/devel/2014-September/004996.html 15:21:18 #info interest in opening bits of the UI where there is significant interest: message app - underlying frameworks support multi-user, app doesn't 15:21:29 #info community interest, too 15:22:26 general comment, it is a bit hard to talk in a wide scope but we try to avoid closed middleware, it causes more trouble than worth, we've had some cases of it and it's getting improved with things like sociald going out 15:22:51 also if I read this accounts would also be important. e.g. I will probably need an account plugin for the push notification framework 15:23:11 it comes down to a case by case basis and one of them (sailfish.accounts) got discussed a bit by chriadam in link above 15:23:40 can we list the closed middleware so we're on the same page? 15:23:46 yeah, trying to find my own list 15:23:59 (sorry for confusion of hats, this is kinda my area..) 15:26:16 ambienced is one middleware that's still closed, tohd, 15:26:26 Test message, to see if my lost connection is back. 15:26:27 the store 15:26:56 and the 'Sailfish" components QMLs.. which is a bit quirky if it's considered as middleware or support libraries 15:27:05 as they can change at any time 15:27:33 i'll export a png so people can check for themselves, but we have 3 more minutes to discuss about it 15:27:58 as an action point we can take it up regarding messaging as an example where we could have a benefit of opening up further/frameworkising it 15:28:18 depending on whether jolla-gallery or ambienced does the actual cropping of background wallpapers, we might need a fix anyhow for black textures on custom wallpapers (non pre-shipped self created ambiences) 15:28:21 #action to look into messages and see how we can open or further frameworkise it to make it possible to add new technologies 15:28:40 #info still closed middleware: ambienced, tohd, store, 'Sailfish' components QMLs (middleware or support libraries?) 15:28:57 geoclue plugins? 15:29:05 +1 15:29:15 yes, geoclue but that was over in hw adaptation ;) 15:29:19 and a qmf oauth2 plugin 15:29:45 http://releases.merproject.org/~carsten/non-oss.png is a quick look at non-oss 15:29:46 I don't think geoclue-provider-here can be opened 15:29:55 -here can't, -geoclue can possibly 15:29:55 (not sure) 15:29:58 err 15:29:59 hybris 15:30:05 -hybris :) 15:30:19 #link http://releases.merproject.org/~carsten/non-oss.png is a quick look at non-oss 15:30:24 hw adaptation not included 15:30:29 sociald was since published 15:30:37 okay, next topic.. 15:30:50 #topic Party time? (15 minutes) 15:31:01 kimmoli: and i guess cybette from jolla side? 15:31:08 \o 15:31:20 * tbr proposes something in Tampere, Devaamo happy to help 15:31:26 #info https://together.jolla.com/question/42121/first-one-year-party-27-nov-2014/ 15:31:34 tampere meh 15:32:06 but yes, i had this blink that we could gather together in 1-year anniversary of 1st-one/launch day 15:32:23 kimmoli, :D tampere isn't meh :P 15:32:51 think also for non finns 15:32:54 i'm not myself a party-organizer, so if this is going to happen, lots of love is needed 15:33:02 I can help with the organizing 15:33:09 kimmoli: somehow the people inside ring-3 consistently suck at organizing open source and sailfish events ;) 15:33:11 cybette, iekku do Jolla plan anything (that you can talk about) for an anniversary? 15:33:25 tbr: i know. 15:33:34 for the record if there were a thing I'd travel .fi 15:33:39 stephg: not at the moment :) 15:33:45 dr_datacenter, there's several lowcost airlanes coming to tampere. but yeah, it's not the easiest place to reach 15:33:50 that you plan or that you can talk about ;) 15:33:53 I suggest we can organize something globally as a community 15:34:07 video streaming!!! 15:34:09 not from Rome 15:34:13 e.g. local meetups and google hangout to connect everyone 15:34:15 hangout party? *snerk* 15:34:23 tbr: great minds ;) 15:34:23 irc party? 15:34:24 * Stskeeps ducks 15:34:32 IRC FTW! 15:34:38 everybody on their own sofas 15:34:41 or hangover 15:34:49 ? 15:34:56 no pants 15:34:56 dr_datacenter, that will be then 28th party ;) 15:34:58 it has been suggested Mbar close to kamppi 15:35:03 but seriously, for f2f, the tampere offer stands 15:35:06 sledges +1 15:35:08 place for HKI 15:35:46 we can use the TJC post https://together.jolla.com/question/42121/first-one-year-party-27-nov-2014/ and put locations for each city as separate answers 15:36:06 #info we can use the TJC post https://together.jolla.com/question/42121/first-one-year-party-27-nov-2014/ and put locations for each city as separate answers 15:36:15 #info suggested mbar close to kamppi by kimmoli 15:36:37 or damourti at TJC it was 15:36:38 #info tbr suggests devaamo happy to help with tampere 15:37:06 I hope there are some other sailors in Vancouver. Or indeed in North America as a whole! 15:37:15 i've heard of jolla users in canada 15:37:31 yeah me too 15:37:38 äh... Congratulations, you have received a badge 'Stellar Question' 15:37:46 kimmoli: :D 15:37:50 bobsummerwill: or those who put sailfish on their nexuses;) 15:37:53 (some people have working LTE on rogers, or something like that..) 15:38:42 are you plan jolla in canada? 15:38:48 but decentralized it is. Jolla presence is "sailors at will" ? 15:39:30 That is VERY interesting. I'm on Rogers, but assumed from what I had read that not even 3G was possible with the existing hardware. eBay time! 15:39:45 kimmoli: yes for now let's plan it this way 15:40:06 +1 15:40:11 it's more community then 15:40:11 (5 minutes left) 15:40:35 let's spread the word and continue the discussions in irc/tjc regarding timing and venues. when we get enough interest we can discuss about hangouts or video conf 15:40:46 i'll edit tjc post a bit 15:41:03 I can help with planning in Helsinki/Tampere (will probably attend Tampere one ;) 15:43:46 tbr: I think there's also interest for a devaamo/Sailfish hack day in tampere soon (from last meetup) 15:44:00 cybette: ok, let's do it! 15:44:35 uu! hope i can participate too finally 15:44:45 tampere is the happening place ;) 15:44:52 ...urf... 15:45:07 agreed tampere > helsinki :P 15:45:13 #topic Wrapping up, any other business, next meeting 15:45:15 kimmoli: no worries, we'll get something going on in HEL :) 15:45:30 but some roadmap, next update 15:45:35 so maybe we should just wrap up kimmoli's question from first topic 15:45:37 eleroux: i can jump to tampere (but coming back is the issue) 15:45:40 and other crunchy things 15:45:55 I just wanted to talk about BlueZ for a few mins, if there is time? 15:45:59 regarding daemon-level stuff such as toholed, would it still belong in 'applications' as such? bit academic when we can't offer it in harbour but.. 15:46:16 i'd kinda consider it more as a part of the system somehow 15:46:34 yes, it is tricky creature... 15:46:39 Stskeeps: I think we can give bobsummerwill few minutes for BlueZ? 15:46:45 mono 15:46:48 cybette: yes 15:46:48 so toholed settings (daemon) could be in settings/system -cat? 15:47:00 let's just wrap existing topics out 15:47:03 not in settings/apps..? 15:47:06 kimmoli: i'd think so but i'd ask a designer.. :) 15:47:51 Stskeeps: ok, point me a designer and i'll poke 15:47:53 so maybe a third-party section in settings ? 15:47:57 as a general comment we need to 2x the time indicated on a topic in wiki and add 5 minutes to make sure we have enough time to talk about things, it gets a bit stressed else 15:48:10 +1 15:48:13 ie 10 minutes is too short 15:48:15 with apps and services sub-sections ? 15:49:11 yeah usually I estimate and add more minutes to the proposed ones. due to the nature of irc meeting, sometimes people underestimate time needed 15:49:22 :nod: 15:49:25 +1 15:49:27 M4rtinK: perhaps 15:49:34 this category could be free- for- all basically 15:49:36 ok, i got my direction now. (but for apps .desktop file [settings} section exec=harbour-app --settings or harbour-app-settings 15:49:41 yeah i think this one is really up to the designers, there is no clear existing place for daemon settings in the gui 15:49:44 #action to look at how background 'daemons' could fit into settings u 15:49:45 i 15:49:46 #action to look at how background 'daemons' could fit into settings ui 15:50:06 the more linux thing to do would be to have daemons with text file configs, but thats not very user friendly 15:50:07 #action general to estimate topics as more than proposed longer 15:50:18 if harbour is not considered, daemons can already create their own settings under system. 15:50:21 r0kk3rz: openvpn settings ... 15:50:43 well, the daemon might store the settings in a text file :) 15:50:46 lbt: +1 (and their ilk) 15:50:48 cybette: do i remember wrong or did we discuss bluetooth in a earlier meeting? 15:50:56 pvuorela: is that know-how public ? 15:50:57 just to have a #link 15:51:06 having a GUI for that does not preclude thay 15:51:13 *that 15:51:24 lbt: not documented, but there are examples for our system settings on the device. 15:51:32 Stskeeps: we did, and I shared that meeting with bobsummerwill as well 15:51:35 oki 15:51:36 anyhow, bobsummerwill, tell us about bluez :) 15:52:03 pvuorela: maybe send a post to ml to suggested one to look at as a simple/sane example ? 15:52:13 A month or so back I started chatting with Javier on Twitter about BlueZ, because he had tweeted something along the lines of “Wow. Tizen has a really complete BLE implementation”. He then started digging into the code, because it had all happened within the black box of Samsung’s work on Tizen 2.x. I started a dialog with some Intel architects on whether there was “good stuff” which we needed to pull into Ti 15:52:25 bobsummerwill: you got cut off at "we needed to pull into Ti" 15:52:28 Tizen 3.x is using BlueZ5. 15:52:29 the system settings need just .json file telling where the entry belongs etc. 15:52:41 The question I have is “who is driving BlueZ for Mer/Sailfish/Jolla?”. 15:52:54 Because if we’re sticking with BlueZ4 for the time being, there looks to be “good stuff” to steal from Tizen, which was never upstreamed. 15:53:10 There is a whole longer mail-thread for this, which we could either just post to the mailing list 15:53:27 Or of that is too spammy, could just be directed to somebody appropriate to triage 15:53:43 i think mailing list would be good, the guy from our side is hannu mallat, our tree is at https://github.com/mer-packages/bluez 15:54:19 OK - thanks. Will do mailing list post and follow-up with Hannu. 15:54:24 the challenge is bluez moving forward in general, it's quite problematic that bluedroid is what a ODM will deliver for a device, and not a ready-ish bluez setup 15:54:59 Do you have insight into the background to the Bluedroid switchover? 15:55:20 From reading the BlueZ mailing list, it seems it was a bit of a surprise to them, where Google just "made their own" 15:55:27 from what I heard at ELC that wasn't a major problem at the driver level 15:55:29 not a lot. but i have a hunch lgpl/gpl was involved and that bluez wasn't ready for challenges of today's devices 15:55:42 / moving too slowly, but that's my private opinion 15:55:57 It looks like they have done a LOT of work in the last few months, but it might be too late. 15:56:34 See http://www.bluez.org/additional-features-of-bluez-for-android/ 15:56:47 not to mention that a lot of the required bluez5 things are done on mainline, whereas most devices shipping today are 3.4 reference kernels.. 15:58:00 Anyway - I have no real investment in any particular stack. I just want to have good BLE support, so I can do cool self-hosting stuff. 15:58:16 :nod: i think there's a few people interested in BT LE in the sailfishos community 15:58:23 I just happened to be in the middle of the Tizen and Sailfish communities, and was able to tie some people together. 15:58:25 +1 15:58:37 okay, does anybody else have anything they'd like to discuss while we are at it? 15:58:51 before moving on to discussion on next meeting and chair of next meeting 15:59:11 vpn supports via connman? 15:59:14 python in store ? :) 15:59:25 wasn't that discussed last meeting? (python) 15:59:26 #info some BlueZ info will be coming soon to mailing list, thanks to bobsummerwill :) 15:59:55 sure, but if there are any updates/timelines 16:00:17 dr_datacenter: given the challenges we have in connectivity in general and getting the rodeo horse connman can be once in a while under control, it'll probably be sometime after that 16:00:19 purely out of interest, the beta launcher for android 16:00:58 i think stabillity should be priority for conman rather than featue creep 16:01:11 +1 16:01:22 stephg: i don't think we have any news on that today 16:01:58 kk, no worries 16:02:15 M4rtinK: hmm, wasn't it coming with next update? i may remember wrong 16:02:21 it's in the old meeting logs :) 16:02:35 IIRC it is a store infra issue ? 16:03:05 in other news, mer-nemo merge is finally happening: https://build.merproject.org/project/show/mer-core:i486:devel - help to sort out GCC 4.8 build issues very welcome 16:03:18 this is on build level at first, git repos merge afterwards 16:03:29 btw: I recently built connman from source and am rather happy with the improvements 16:03:39 19 failures with gcc4.8/new glibc 16:03:46 nemo mw, to be precise 16:03:51 wifi used to die a lot, randomly at home. now it happens rarely 16:04:13 \o/ on nemo+mer 16:04:33 helping out may also get you a better toolchain faster ;) 16:04:53 #info mer-nemo merge is finally happening: https://build.merproject.org/project/show/mer-core:i486:devel - help to sort out GCC 4.8 build issues very welcome 16:05:28 okay.. next meeting, i would propose 2 weeks from now, in the 10 UTC slot? 16:05:44 +1 16:05:46 +1 16:05:55 fine by me 16:06:02 +1 16:06:17 I'll chair, as Stskeeps has too many hats to let go of them all ;) 16:06:23 please advertize the 10UTC fact aggressively with people in .au .nz and hong kong 16:06:26 nod 16:06:57 #info Next meeting 23 September 2014 at 10 UTC, cybette as chair 16:07:15 are there many au/nz sailors? 16:07:25 r0kk3rz: there's certainly HK ones coming 16:07:34 for sure 16:07:42 thanks everybody for coming to this meeting, feel free to join #jollamobile and #sailfishos afterwards for further conversation 16:07:50 r0kk3rz: lpotter is from .au 16:07:50 thanks Stskeeps for chairing! 16:07:55 thank you everuone 16:07:58 everyone 16:08:06 #endmeeting