10:00:26 #startmeeting SailfishOS, open source, collaboration, 13/May/2014 10:00:26 Meeting started Tue May 13 10:00:26 2014 UTC. The chair is Stskeeps. Information about MeetBot at http://wiki.merproject.org/wiki/Meetings. 10:00:26 Useful Commands: #action #agreed #help #info #idea #link #topic. 10:00:26 #info Please when adding topics to the piratepad, add your name and a small description of the topic (so we can ask for elaboration), it helps to prepare for meeting 10:00:38 #topic Quick introductions (5 minutes), prefix your info with #info 10:00:39 #info Carsten Munk, Chief Research Engineer @ Jolla 10:01:07 #info Aleksi Suomalainen Community Member 10:01:22 #info Basil Semuonov, developer 10:01:38 #info Steph Gosling, Community Member 10:01:40 #info Filip Kłębczyk, blogger about Jolla, maybe still Jolla community, whatever you want to call me 10:02:16 #info Lorn Potter, developer @ Jolla 10:02:31 #info Marko Saukko, worked with Nemo and Mer sometime ago. Now working for Jolla and contributing to Mer and Nemo when possible. 10:02:40 #info Aaron McCarthy, developer @ Jolla Location, Connectivity, Qt. 10:02:51 #info Mikko Ahlroth, software developer at Vincit Oy, developer of SailTime. Going to follow the discussion from the sidelines 10:03:10 #info David Greaves - Mer infra and chum. Also Jolla sailor :) 10:03:24 #info Carol Chen, community chief at Jolla 10:03:25 #info Eric Le Roux - Bugzilla & t.j.c admin 10:03:33 #info Iekku Pylkk�, head of developer affairs @jolla 10:03:41 #info Denis Zalevskiy, Jolla, middleware etc. 10:04:04 #info Giulio Camuffo, developer @ Jolla, qt, wayland, other stuff if needed 10:04:39 #info Simonas Leleiva, community member, Jolla sailor 10:04:43 #info Soumya Bijjal, sw program manager @ jolla 10:05:09 #info vgrade, community, adaptations 10:05:27 #topic Chum sync (lbt, basil, tbr) - 30 mins 10:05:27 #info This is more of a floor discusssion, lbt/Basil/tbr? - can we synchronise on what's been going on with Chum? 10:05:47 one too many 's'es there, but :) 10:07:03 Well, from my side I haven't progressed it much. Went to Embedded Linux Conference and then been catching up. 10:07:31 The next steps for me are to begin to assemble some boss validation steps 10:07:57 there's also been some work surrounding OBS upgrade in general? 10:08:06 as merproject.org OBS is an ancient version 10:08:14 correct 10:08:31 that's due to happen in the next few days 10:08:44 from my side: openrepos bridge to obs is completed. packages may be imported once builded, and if application is linked to obs, no manual rpm upload is allowed for that app. obs builded apps have own 'badge' that app is FOSS and builded on OBS infra. Warehouse by default can only show 'trusted' and 'obs foss' software, as safe for user. show all other packages can be enabled after warning banner 10:09:03 #link http://merproject.org/meetings/mer-meeting/2014/mer-meeting.2014-04-22-15.00.html minutes from last meeting where chum was discussed 10:09:13 BasilSemuonov_: cool 10:09:25 #info Next steps for lbt: Assemble boss validation steps 10:09:34 #info merproject.org OBS upgrade, as it's currently ancient 10:09:59 #info Basil has been working on openrepos bridge to OBS: packages may be imported once builded, and if application is linked to obs, no manual rpm upload is allowed for that app. obs builded apps have own 'badge' that app is FOSS and builded on OBS infra. Warehouse by default can only show 'trusted' and 'obs foss' software, as safe for user. show all other packages can be enabled after warning banner 10:10:04 I think we need to agree how QA will work too 10:10:05 not sure if warehouse sources can be reused (may be only packagekit bindings), since openrepos have own custom api (kind of api) 10:10:13 BasilSemuonov_: any problems you've encountered? 10:10:20 lbt: +1 10:10:35 lbt: might be good to study how maemo.org extras did it, learn from it's failures? 10:10:38 I need explicit rules in order to automate them - but this can include manual testing 10:10:59 Stskeeps: yes - and we did some planning for apps4meego too 10:11:01 no (-: this is just a way to spread apps builded on obs via openrepos, without manual reupload 10:11:17 Stskeeps, ^ this one for you 10:11:33 BasilSemuonov_: thanks, let me know if there's anything you'll need a hand with 10:12:07 Stskeeps, as lbt said, QA and policies are more important for chum at this point 10:12:10 regarding QA: there are repos in openrepos containing packages replacing Mer ones and resulting in some important apps beeing broken (like ssu). Such repos should not get into chum 10:12:38 deztructor: yes, that was discussed in last meeting 10:12:45 deztructor: I think we need to break up the QA criteria to explain/measure why not 10:12:52 deztructor: see bit about reusing openrepos client 10:12:58 ie 'does this replace a core package' 10:13:00 Stskeeps: ok 10:13:03 thanks 10:13:04 #link http://wiki.maemo.org/Extras-testing 10:13:11 ... apps4meego, hmm 10:13:16 i wonder if all that info was on the now dead meego wiki 10:13:40 yeah, it seems so - lbt, you had a copy? 10:13:59 yes, I think so 10:14:20 some Meego wiki stuff can be found on Internet Archive 10:14:29 If we're going to do this voting and promotion thing, can we do it much better than Maemo did please :) 10:14:31 fk_lx: indeed, just found similar 10:14:46 openrepos it self will move from 'per publisher repository' which need to be enabled, to 'per application repository', which will contain app itself and all needed deps based on stock firmware release. so enabling one huge repository will not replace(update) all apps you have installed from other sources 10:14:59 alterego: yes 10:15:12 trying to get at the QA rules 10:15:19 (like was with nielkd repository, when wget was pulled, but you havent installed it manually). 10:15:22 I remember hating begging people to try and vote my app .. 10:15:28 *bash, not wget 10:16:04 For apps that may be "unpopular" maybe just have a gestation period of a couple of weeks and it gets auto-published? 10:16:11 At least for FOSS apps. 10:16:44 alterego: I don't see the need for voting as-such. I would rather we had general testing/reviews 10:16:59 #action stskeeps to dig up copy of apps4meego qa material 10:17:30 lbt: requires manpower, can we make a digital cryptographic currency and pay people to test for us? :) 10:17:46 haha ...I was typing ... : I would also be interested in rewarding diligent testers 10:17:50 Stskeeps, app pulled from obs to testing. votes+comment at testing, on 5(or 10) votes, app pulled to stable. 10:18:31 lbt: voting might end in result, that someone who doesn't like me might on purposes not vote on good apps. Testing should be based on clear and as much non-subjective rules. 10:18:35 I guess maybe an initial small group of SWAT testers would be all that's required. 10:18:44 A couple of hours of testing random apps a day, voting them up. 10:18:50 alterego: I also recall the concept of 'super-tester' where apps which waited too long were boosted 10:18:55 Yeah 10:19:11 That was useful, but not well utilised, I don't remember them ever helping me for instance .. 10:19:26 was that a maemo thing? or apps4meego ? 10:19:26 BasilSemuonov_: any way that openrepos client could theoretically pull down a few apps for testing, if you participate in tester program? 10:19:30 there just should not be negative votes (with explanation of reasons, of course) 10:19:37 might also be a good way 10:19:39 Maemo thing was Maemo Extras 10:19:45 "here's a new app, help test it" kind of thing 10:19:56 Stskeeps: +1 that would be great. 10:20:18 We could have a simple "Sailfish Tester" app that recommends apps for testing when you've got a spare few minutes. 10:20:28 +1 10:20:29 Stskeeps, access rules can be devided into groups with custom access to certain apps. basis for that is completed 10:20:31 alterego: +1 10:21:18 sorry for the late 10:21:40 alterego: deztructor: Stskeeps: I think one think we need to do is prepare (and justify) the packaging rules 10:21:42 vote (app is tested and worked) can be uploaded to openrepos itself, what about push back to obs infra? 10:22:18 is possible to get piratepad url for this session ? 10:22:23 lbt: indeed, that can get messy very quickly :) 10:22:49 dr_gogeta86: https://lists.sailfishos.org/pipermail/devel/2014-May/004152.html 10:23:08 lbt, isnt that(packaging) handled by obs? 10:23:32 BasilSemuonov_: no - OBS builds whatever you give it 10:23:35 BasilSemuonov_: he means rules, things like requires, provides, those messy parts that are likely to break things. 10:23:47 lbt, 'packaged against target os release' 10:23:57 lbt: some tool additional to rpmlint (does not have plugin?) 10:23:57 alterego, ah 10:24:34 deztructor: tooling is boss (maybe using rpmlint) ... but we need to state policy 10:24:55 eg no Requires == version 10:25:23 (10 minutes left) 10:25:41 lbt, 'Requires ==' is a good decision if any app targets exact version of sfos? 10:26:18 BasilSemuonov_: and when there's an sfos update and the app prevents the lib version from changing? :) 10:26:27 that may be hard to avoid 10:26:48 imagine I publish apps depending on something that is gone on future release 10:26:53 all apps should have lower priorities than system packages. on update you should be promted: 10:27:05 hi ! 10:27:08 actually that brings in the other side - I'd like to see what can be done to tag apps in the rpm db so the resolver can prefer to remove non-system/jolla apps 10:27:12 BasilSemuonov_: yes 10:27:13 'update, and this 12 packages will be removed', or 'stay as is' 10:27:15 pkgmgr will also prevent update (at least in current versions) 10:28:05 lbt, i.e. core package/system package/optional package 10:28:12 lbt or Stskeeps I was wondering if there is a sort of metapackage in SFOS to check what's the current SFOS version 10:28:37 BasilSemuonov_: +1 for idea to ask user 10:28:40 #info It would be nice to support package priorities in rpmdb for resolver decisions. eg: 'update, and this 12 packages will be removed', or 'stay as is' 10:28:40 would be easier than making a dep on another system package ? 10:29:21 I'd really prefer if the pkgmgr could be made "flexible" more than having a strict set of rules for pkg deps 10:29:33 there is the risk that one ends up with harbour-style rules. 10:29:39 SK_work: not afaik yet 10:30:05 another question is, should chum be able to provide packages which alter system packages (but not core, if there willl be diff between core and system packages) 10:30:20 javispedro: maybe it is better to start with strict rules and then loosening 'em 10:30:22 i'm talking about patchmanager for example, lipstick-qt5 10:30:30 SK_work: that too may help us. ie if an app is tied to a certain sfos version then maybe that metapkg would be removed and remove all apps depending on it 10:30:39 before an os update 10:30:40 BasilSemuonov_: in the ideal world we wouldn't have to do tricks like that.. 10:30:42 Aard: ^^ 10:30:56 BasilSemuonov_: IMO too dangerous 10:30:57 BasilSemuonov_: ideally we should be able to contribute to system packages and have things improved that way 10:31:21 BasilSemuonov_: even if experience has proven that lipstick-qt5 change didn't break updates not anything 10:31:32 BasilSemuonov_: I would say 'yes if QA approves it' but also 'not initially' 10:32:09 (3 minutes left) 10:32:19 lbt: we've been thinking for a while to use sailfish-version dependency. migt not be required, though, as we seem to be capable of figuring out where the package works based on abi compatibility. it's something we're looking into, but quite complex topic 10:32:34 re: re-using src code: could Warehouse for Sailfish politely gradually replace all open repos to OBS ones, and offer apps from there? 10:32:58 (i liked the idea of foss badge already etc) 10:33:18 Aard: *nod* ... such a thing may provide a more understandable (but blunter) interface for apps 10:33:31 sledges, this can be done, since source reporitory url is known 10:33:44 and encourage devs to go OBS 10:34:18 sledges, the only thing is about deps, all package deps should be at this repository. 10:34:20 as warehouse is already popular 10:34:39 cum is built against sailfish 10:34:41 *chum 10:34:51 it can offer flexible hierarchy 10:34:59 (add more repository paths to build against) 10:35:01 like chum-mw 10:35:08 thanks to OBS 10:35:21 #topic More closed source discussion (Carsten) - how can the community help - 30 minutes 10:35:31 #info There was a bit on unclarity from my last meeting on what hat I was wearing, so I'm repeating it here with a Jolla hat. 10:35:34 #info Silica is not open source currently. State is that there's no exception granted (see policy for open source contribution listed in the other meeting) for open sourcing the current codebase, which is BSD-licensed QML and closed source C++, but there is a desire. Work to get that exception is ongoing. 10:35:39 #info This is more of a Q&A discussion, please ask some questions, let's see if we can answer right away, or need to get a better understanding and get back to the question 10:35:46 sledges, warehouse cannot guess about such paths, only manually entered, or importing predefind hierarchy 10:36:07 there was no description together with the question, so i'm a bit in the blind about what it's about exactly 10:36:07 BasilSemuonov_: I'll take a look into warehouse src 10:36:46 as closed source is one of those things where it's hard for a community to really help in, in it's own nature 10:37:14 as it relies on choices made due to business reasons; or maybe it's closed source 3rd party bits we use, like hardware adaptation, etc 10:37:53 Stskeeps: it wasn't unclarity, you said you were hat-less (so without any, including Jolla, hat) 10:38:16 fk_lx: yep, the word 'unclarity' is wrong, but in practice, i should have stated it was with a hat in that particular sentence 10:38:25 so i need a better word than unclarity 10:38:46 who was it that proposed the question on the etherpad? if present 10:39:09 the question is if moderator should wear any hat, otherwise it confuses people 10:39:17 :nod: 10:39:19 valid concern 10:40:19 but any way to triage connections problem 10:40:25 so, who should represent Jolla in this part ? 10:40:28 in my opinion if someone is a moderator, should not take any (hat) statements in discussion, otherwise it's not a neutral moderator 10:40:33 till now without writing anything 10:40:42 dr_gogeta86: those parts are all open, iirc 10:40:43 some wifis are unable to use 10:40:45 fk_lx: +1 10:41:04 i don't say connmann 10:41:13 i say sailfish os 10:41:24 i didn't find any reference 10:41:27 What prohibits a moderator from being neutral. 10:41:28 neither into filesystem 10:41:34 fk_lx: i think we'll take cybette as moderator for next time, so i can take on topics where i need to (provided cybette doesn't have some topics), you're right, it does cause some oddity 10:41:39 dr_gogeta86: don't think that this is the best place to discuss here though 10:41:51 dr_gogeta86: so, it is partly closed source related 10:42:11 we aren't talk about the closed part of things 10:42:11 dr_gogeta86: it goes into the settings and connection selector, which are not open source 10:42:11 ? 10:42:32 Stskeeps: +1 for a moderator that will be only moderator 10:42:42 and present the UI configuration, where the implementation for let's say, enterprise wlan isn't implemented in 10:42:48 the factual work happens in open source components 10:42:56 connectionagent -> connman -> wifi driver, ofono 10:43:17 the UI configuration is somewhere where it would help a lot if was somehow pluginable 10:43:45 Stskeeps: can any contributions even be accepted due to copyright non-assignment? 10:43:45 lpotter: you're awake by chance? 10:43:55 Stskeeps: since the patching issues seems to be addressed, I wanted to go slightly further: some patches (not those changing ui a lot, but those adding more functionnalities) could be interesting, even for Jolla 10:44:11 lbt: we're looking into that particular case on how it can be, as stated in the patching session 10:44:14 just an example: vibrating when phone communication is established 10:44:20 it just needs some legal clarity 10:44:34 (I should maybe ask if there are issues due to copyright and closed license - where it is and isn't relevant - eg smaller patches) 10:44:36 one way around it is using SK's patcher 10:44:43 (maybe it's patented though) 10:44:59 lbt: IANAL :) 10:45:15 Is that an Apple product? 10:45:31 Stskeeps: so maybe an action to provide community with guidelines? 10:45:44 lbt: yes, i think it was already brought up when the patching stuff was discussed 10:45:47 both 'today' and eventually as they change 10:46:08 dr_gogeta86: does this explain a bit about how the connectivity part of sailfishos functions/where you'd need to work in? 10:46:51 dr_gogeta86: we've recently made some big changes to Mer git and contribution side so that should now be easier too 10:46:56 dr_gogeta86: connman itself and other open components need love to get rid of connectivity issues 10:47:41 deztructor: isn't Tizen helping too for connman ? 10:47:50 i'm a pretty noob 10:47:56 tizen does have some patches, yes 10:48:09 but i've found 3 areas were sailfish os laks 10:48:14 *lacks 10:48:30 Captiveportal open wifis in public areas 10:48:40 Hidden Network with 802.x 10:48:58 Some strange Wpa2 10:49:09 dr_gogeta86: we've been working to get a newer connman going that helps a major amount of issues, but, it's not in an update yet 10:49:18 i know 10:49:34 captive also relates to interpreting http 204 stuff i think 10:49:34 Any estimate on the new connman going in Sailfish? 10:49:56 I wanna contribute fro fields tests 10:50:12 *for 10:50:23 i got those crappy things at home 10:50:41 Stskeeps: I'm wondering how can community help in the non-open source part too: it's pretty easy to write patches in the QML files, but it would be better if they could be integrated directly in the next SFOS update 10:50:46 SK_work: yeah 10:50:49 I know that there is a need of review and guidelines 10:50:56 maybe some work in this side for Jolla ? 10:51:09 dr_gogeta86: so, again, open components available to be used in developer mode 10:51:24 (and legal, like signing a contract, or licensing patches in a specific license that allow Jolla to use them) 10:51:30 SK_work: :nod: 10:51:53 NSA-Rep: not in next update, only connman+some fixes, it wasn't stable enough yet 10:51:58 rapidily improving though 10:52:38 Next you mean May not June i believe 10:52:51 deadlines flow a bit so whatever is coming out next :) 10:53:45 Stskeeps: BTW, do you think that, at some point, QML could be available without the need of patching some libs ? 10:54:00 Ok its just the we wait for a may update in a few days. 10:54:05 I'm thinking about lipstick of course, but also the music player (for example) 10:54:13 SK_work: lipstick is the patching you're doing at the moment 10:54:15 ? 10:54:20 Stskeeps: yes 10:54:38 this is ok, but thrills you when there is a sys update 10:55:06 I was too brave to did it whitout disable any 10:55:08 :-D 10:55:13 SK_work: i can't really say that in practice until it has happened, but you might argue (my own personal opinion) what the worth is to embed qml into a binary when it's extractable with ease 10:55:45 I thought it loaded faster 10:55:47 Stskeeps: maybe speed 10:56:10 this can be accepted as a reason for homescreen 10:56:12 lbt: I think when I benchmarked ages and ages ago it was actually a bit slower, but I didn't look into it much, or the why 10:56:21 less, for a media player 10:56:24 (9 minutes left) 10:56:31 w00t: ok - good 10:56:42 (especially that media player don't seems to have much love given) 10:56:54 w00t: it should be able to load faster :) 10:57:04 SK_work: ah, i didn't know media player had embedded qml too 10:57:10 lbt: so you'd think :) 10:57:24 Stskeeps: but I think that it's for technical reasons too 10:57:37 (not speed but plugins, it seems ...) 10:58:40 when we speak about closed source there's always a group of people of people who're interested in replacing closed components with open ones -- are there anybody here who are looking at alternatives? not necessarily jolla bits 10:59:01 how are the Jolla roadmap email side of things? (cc: bijjal ) 10:59:23 sledges: +1 10:59:56 bijjal's on the other side of the world on bad connection, so if she's not answering and shortly after ping timeout, that's why 11:00:18 Stskeeps: I would say that rebuilding stuff is rather hard, when we already have something built 11:00:20 sledges: we are on it, there will be an email during this week 11:00:25 bijjal: \o/ 11:00:36 even if I'm checking locusf's progress on #nemomobile :) 11:00:40 imap idles is implemented ? 11:01:04 VDVsx: might know something about it 11:01:12 Stskeeps: it's usually much easier to continue working on something existing (Jolla people understood that ;) ) 11:01:45 (4 minutes left) 11:02:59 #info reply on sailfish-devel: Stskeeps: when we speak about closed source there's always a group of people of people who're interested in replacing closed components with open ones -- are there anybody here who are looking at alternatives? 11:03:36 #info re: Jolla roadmap publishing: sledges: we are on it, there will be an email during this week 11:03:53 dr_gogeta86, we need to implement some changes to our accounts first, MW is ready 11:04:07 #action organisers for us to have an independent non-hat wearing moderator for each meeting 11:04:08 ok 11:04:09 we want to release all changes at once since some redesign is needed 11:04:11 (just getting that one along) 11:04:52 next frontier ... but is a desiderata are sieve filters ... and saifish become most friendly imap mobile client 11:04:57 :-D 11:05:26 Stskeeps, personally i like how do you manage 11:05:29 SK_work: what progress ;p ? 11:05:33 #topic Accepting graphical contributions by community - 25 minutes 11:05:33 #info Could somebody explain what this is about? 11:05:39 locusf: :D 11:05:47 .. if anybody suggested this topic on the etherpad, please elaborate :) 11:06:16 maybe you should make it obligatory to provide a description for topics on etherpad so you don't always need to ask around 11:06:18 Sounds a good topic though, but the scope is a bit large 11:06:30 Nicd-: yeah, i've done that and remarked in the start now :) 11:06:41 don't want to change rules out of the blue, so 11:07:10 Yes. Thje quetsion is a bit about customization. Is there something that can be done from jolla to have graphics contributions by the community. Ie. there are icon themes floating around in TJC and no easy way of installing them 11:07:26 I can also add about ambiences customization 11:07:34 eg: black ambience for instance 11:07:55 NSA-Rep: that can be done via openrepos (and eventually - chum) 11:07:58 just like kbd layouts 11:08:01 just like system patching, changing theme / ambiences is not that hard, but there is no infrastructure to host them easily 11:08:09 sledges: host would include how to change them 11:08:10 And not only for the app icons. System icons too. The icons on SFOS wasn't Jollas design team finest hour 11:08:23 NSA-Rep: hmm, it's a bit of a tough question :) a jolla device/OS has it's own design, but, people still customize their devices -- there's no functionality to really select a new icon theme. Have you considered using SfietKonstantin's patching for such a thing? 11:08:27 it seems you can change the icon theme (just like in harmattan), if the engine is similar 11:08:54 Havent looked into it and i am no coder to be honnest. 11:08:55 icon themes are a bit of a headache in case you have to directly 'support' them in a OS, so 11:09:07 Stskeeps: icons are in a specific subfolder of /usr/share/meegotouch (iirc), this sounds like as if the same engine is used from N9 11:09:08 SK_work: just provide a new theme under /usr/share/theme/NAME/icons and provide its inherits bits etc 11:09:15 and on N9 you could change theme 11:09:25 sledges: missing the theme switcher 11:09:36 Is something like: install from shop and use uninstall and go back to default possible? 11:09:45 and don't know if there is a hardcoded path or not in Jolla side 11:09:45 as in, how do you make sure that all systems keep working after a upgrade, when icon themes are installed 11:09:49 so more pointers welcomed 11:09:57 SK_work: switcher is missing yes, but that's for the last bit to think about 11:10:14 sledges: my biggest fear is harcode 11:10:15 so that's why it might be difficult to put it in let's say, harbour 11:10:40 Stskeeps: why the system would stop working if you have different icons ? 11:10:47 SK_work: think 'missing icon' situation 11:10:47 things breaking after update applies to anything we sideload (OR, chum, ;) 11:10:57 SK_work: may or may not work 11:11:01 or that the icons become confusing 11:11:04 Stskeeps: add fallbacks ? 11:11:12 Stskeeps, SK_work they are even not different, they are *additional* 11:11:30 Stskeeps: IMO the user choose the icon theme, if it's confusing for the user, then he/she won't choose it 11:11:41 iekku: could you make a note to investigate how we feel about icon themes? 11:11:43 in harbour 11:11:55 also, as an idea, custom ambiences 11:12:09 i presume there's a lot of people who might want to contribute CC-licensed artwork, for example 11:12:12 + technical aspects (switcher / hardcode in paths to search icons / having fallback etc.) 11:12:26 Stskeeps: +1 11:12:45 #task iekku to investigate how to handle icon themes in harbour + custom ambiances 11:12:59 SK_work: I think this kind of stuff could be prototyped out in chum where community can explore what APIs are needed to provide theme support 11:13:05 NSA-Rep: are there other artwork areas that could need some thought? 11:13:08 so yes, i take that, hopefully having something to share next tuesday 11:13:22 speaking of tuesday.. 11:13:38 #action iekku to investigate how to handle icon themes in harbour + custom ambiances 11:13:44 lbt: true 11:13:45 oops :D 11:13:57 i am not a fan of some sailfish ellements (ie the button) but i have no idea what can be done from outside jolla 11:14:00 lbt: (need to know how chum works though) 11:14:03 sledges, thanks mate 11:14:12 SK_work: mainly so community can tell Jolla "this is what we need" 11:14:15 NSA-Rep: you can patch via PM, and break everything 11:14:18 lbt: +1 11:14:23 iekku: cheers :)) 11:14:32 sound themes? 11:14:32 :P 11:14:38 (doctor who ambience, anybody..?) 11:14:39 ;) 11:14:46 Stskeeps: harder maybe ? 11:14:54 special's screaming Jolla ? 11:15:02 Stskeeps: me! 11:15:08 lbt: isn't lpotter 's ? 11:15:11 iekku would it be possibel to share on TJC? 11:15:24 custom component sets is a cool idea, but unless applications are written with support for run-time varied imports (eg, via the File Selector APIs which were added to QML in 5.3) they can't really be supported in SFOS imo 11:15:24 I would love to have Jolla give us a feedback on "light ambiences": black fonts, white background 11:15:27 oops 11:15:53 chriadam|meeting: you think so ? maybe you can Component.create all the components ? 11:15:56 SK_work: do you have a screenshot of that not working nicely? 11:16:02 very painful, but why not ? 11:16:07 or better yet, a tjc thread. . :P 11:16:09 NSA-Rep, not a bad idea at all. i assume it might be better forum than sailfishdevel mailing list 11:16:11 lbt: yes that's my screaming jolla when you drop it :) 11:16:16 Stskeeps: quickly: a lot of icons are white instead of black 11:16:22 SK_work: ok 11:16:26 the code is here to support them, but not propoerly written 11:16:33 lpotter: :) 11:16:42 SK_work: not without ugly, difficult-to-maintain code. Plus we'd lose a lot of a gains we currently get from preloading imports to generate process-sharable compiled typedata. 11:16:56 + the ambience blurring algo is needed 11:17:07 chriadam|meeting: +1 11:17:25 chriadam|meeting: I'm against custom components though 11:17:28 Stskeeps: https://www.dropbox.com/s/etdyot2g2un2qov/tardis.png 11:17:41 at best, patch some of them, but a full set of new ones sounds not good 11:17:59 SK_work: well, either is a recipe for disaster tbh ;-) but it's a cool idea "in theory" 11:18:29 in theory ... 11:20:37 chriadam|meeting: what is the file selector API you speak? a file selector widget? or sth else -- do you have link? 11:20:49 Regarding design stuff there are quite a few threads in TJC marked with ui ux tags that the Design team can take a look at. 11:21:00 #info Regarding design stuff there are quite a few threads in TJC marked with ui ux tags that the Design team can take a look at. 11:21:12 #info Light backgrounds: quickly: a lot of icons are white instead of black 11:21:34 javispedro: http://qt-project.org/doc/qt-5/qqmlfileselector.html but probably best to watch Alan Alpert's DevDays presentation on them 11:21:55 chriadam|meeting: interesting, ty. 11:21:56 (9 minutes left) 11:22:04 And we don't know waht the design team thinks about the TJC suggestions. I don't think they have commented on anything 11:22:34 javispedro: they're super new, and we won't support them for quite some time, IMO, so it's not something which can be meaningfully considered for SFOS in the short term. 11:23:40 NSA-Rep: :nod: i'll make a note about that, at least, i know they've been participating before 11:24:28 in that regard 11:25:01 The software team seems more active :P 11:25:08 +1 11:25:15 we probably have 'free time' ;) 11:25:20 designers work really hard 11:25:33 Code compiling :P 11:25:36 i wanna have a jolla that rocks 11:25:36 #info a lot of jolla guys are stuffed inside a room on next time for this meeting, we might have to limit topics/move some to another day 11:25:39 for summer 11:25:47 NSA-Rep: nah - sharpening their crayons :D 11:25:52 ahahaha 11:25:58 I wouldn't say all software members are responsive, some of them even ignore and abuse 11:26:13 (4 minutes left) 11:26:20 abuse? who? 11:26:27 i think 11:26:27 that's unacceptable imo 11:26:30 chriadam|meeting: me 11:26:35 lol 11:26:37