07:00:00 #startmeeting Sailfish OS, open source, collaboration -- 15th October 2020 07:00:00 Meeting started Thu Oct 15 07:00:00 2020 UTC. The chair is sledges. Information about MeetBot at http://wiki.debian.org/MeetBot. 07:00:00 Useful Commands: #action #agreed #help #info #idea #link #topic. 07:00:11 #info Meeting information and agenda can be found here: 07:00:14 #link https://forum.sailfishos.org/t/community-meeting-on-irc-15th-oct-2020/2425 07:00:24 I am the meeting's chairperson today, and will be doing my best to keep time and order. Please behave, respect the timings and one another. 07:00:27 Today we have a smorgasbord of questions, there might be no time left for general discussion, but feel free to have a chinwag after the meeting with whoever's still around! 07:00:41 #topic Brief introduction (5 min). Please prefix your name/handle with #info 07:00:47 #info Simonas Leleiva - privateer for Jolla 07:01:09 #info Otto Mäkelä - community 07:01:29 #info Jussi Maaniitty - Sailor at Jolla 07:01:32 #info Anton Thomasson - purveyor of shitty apps, killer of trees (just watching from afar) 07:01:36 #info Andrew Branson - sailor @ Jolla 07:02:05 #info Ville Nummela - Sailor @ Jolla 07:02:33 #info Chris Adams - developer @ Jolla 07:04:38 #info Nikita Ukhrenkov - sailor at Jolla 07:05:15 I hope those who posted topics will turn op, so far not one:)) 07:05:26 i am here 07:05:35 good, please introduce?:) 07:05:58 #info ApB - community 07:06:13 awesome, moving on 07:06:14 #topic harbour library policy (20 min -- asked by KeeperoftheKeys) 07:06:19 #info some details about the topic: In light of Jolla just breaking any app using python3 sqlite bindings by seperating the bindings from python3 into a separate package the whole "claim to carefully curated guaranteed to be stable" allowed dependencies in harbour is a fallacy, 07:06:26 #info at this time we can’t even fix our apps by adding a dependency for python3-sqlite since that is blocked by harbour, 07:06:33 #info it took me several hours of back and forth on the forum to even get an internal bug on the subject opened. 07:06:39 #info a. This is a pretty bad slip up, I only figured it out by digging in the changelogs, that should have been pointed out ahead of time. 07:06:46 #info b. If "accepted" libs get broken you might as well allow the "unaccepted" libs too. 07:06:51 speaking of the devil:) 07:06:55 hey 07:06:56 Here comes the short and sweet answer: 07:07:02 #info python3-sqlite was broken on the Early Access release. The early access releases should be considered as beta. Their purpose is to find exactly this kind of bugs. 07:07:45 I guess what we need to improve is our handling of the issues raised on the forum 07:07:45 absolutely, but it shouldn't take us a day of work to convince Jolla that there is a bug 07:08:08 though after he was convinced @ville was very fast 07:08:45 and also this whole story in general casts the whole issue of what libs we can and can't have and the reasoning behind it in a big question mark 07:09:20 KeeperoftheKeys: Well, that is already a completely different question 07:10:28 and lastly though EA is indeed meant exactly for this at least for my feeling a very large part of users are EA users thus it places us the devs in a very uncomfortable situation where our users are complaining and we're scrambling 07:10:53 *sorry @ViGE 07:11:16 we have cbeta users group, and could ask them to test apps as well 07:11:54 well you have to understand that EA can break. its not jollas fault that many users feel adventurous 07:11:59 KeeperoftheKeys: regarding the wanted libraries, I suggest you ask for the libraries that you want/need. It always helps if you can tell us why a library is needed. And it helps if the library (or at least the API) can be considered stable. 07:13:41 mpris 07:13:56 is high on the list of all multimedia app devs as far as I know 07:14:02 has worked for ages 07:15:22 yes, that's still a candidate for support, but it's too flakey to be supported as it is. 07:15:31 it needs a couple of problems sorting before it can be approved 07:15:33 KeeperoftheKeys: The impression that most of the users are EA users is simply wrong - I do understand how one gets the idea that most users use EA though - it seems quite a large percentage of forum commenters are indeed EA users 07:16:13 it could be that we are the vocal minority 07:16:16 yes, mpris is indeed in our list of APIs that we know developers want 07:16:55 +1 for mpris 07:17:07 I would probably help if we discouraged casual users from joining EA. It's tempting and easy to join it to get the update sooner, but many aren't prepared to deal with the problems it can cause 07:17:25 the stuff/libs needed are an ongoing and painfull subject. 07:17:49 i'll remind again that we cant have native mapping with the restrictions 07:17:55 which is sad :/ 07:17:58 indeed it is 07:18:06 the simplest tone would work: "hey, your app is broken!" vs "hi, could you please fix your app before public release?" 07:18:59 but I had a complaint of non working gPodder before my phone ever notified me that there was a new version (and I am in the EA program) 07:19:05 time's up folks 07:19:56 ah, another 5mins:) 07:21:05 it would definitely be cool if Jolla would ping us when they make a change that breaks backward compatibility, but under current store restrictions that anyhow is unwise since there is no way to release a package that has both the old dependencies and new dependencies 07:21:32 also RPM does not have a sailfishOS version symbol as far as I can tell 07:23:06 As a "casual user" on EA, I'm kinda resigned to being a beta tester, and try to do my best to report problems before the final release. The release notes should try to say "things that depend on XXX will break", so people can better tell what non-workingness needs to be reported? 07:23:45 #info about additional libs: allowing mpris is on Jolla's list, but abranson mentioned there might be couple of flakey problems to sort out in mpris first 07:24:13 iirc it doesn't deal with multiple apps very well 07:24:20 For the libs outside the store, I think it'd be impossible to list all the things that might break. For the things in the store, I'm sure the plan is that things will never break. 07:24:24 Warning about breakage is a bit difficult before we know about it ourselves 07:24:30 I don't quite get that sentiment... nothing "should break", yet somethings do... it's common for all distros 07:24:51 flypig: +1 07:24:57 maybe we need to recruit more of you guys to cbeta :) 07:25:46 why would you open 2 media player apps at the same time? 07:26:04 #info for the record, please be patient when raising issues on forum, Jolla is responding in forums as a company via its sailors, and the reaction time can't be within the same day, as internal discussions or other activities take place 07:26:05 Also, I would also suggest that people should not install EA before they have read the release notes. We had first bug reports before we had released the release notes... 07:26:41 KeeperoftheKeys: switching to another one when the first one is paused or stopped. 07:27:34 #info in future early breakages should hopefully get improved via the cbeta testers (pre-EA) as long as the apps are concerned 07:27:58 ok, time to cut it, as the cornucopia of topics is waiting:) 07:28:02 #topic Consistency of SFOS UX/UI across apps (15 min -- asked by ApBBB) 07:28:12 #info Lately -and as SFOS progresses- more and more examples of apps (jolla ones like email, camera) that are included in the OS “break” the SFOS UX by choosing traditional taps/buttons instead of swipes and gestures. 07:28:17 #info So is jolla trying to move away from the gesture paradigm, is it just that the devs (aurora os people???) have no idea what they are doing and don’t care about consisteny, and what jolla will do to fix this and make the OS consistent everywhere. 07:28:31 the response is: 07:28:32 #info The short answer is that we try to maintain and nurture the gesture paradigm. This is not simple though, as you've seen. Being different of mainstream requires balancing and sometimes we need to do compromises to accommodate problems we've identified in our user studies. 07:30:01 For the record, i like the concept of the new pick-up screen... the graphical design could have been a bit better still 07:30:02 yoohoo Joona joined:) we've just started discussing UX/UI consistency across apps 07:30:42 hi :) 07:30:44 the user studies argument is kind of weak and i explain: you have to deal with people that are used to the tap/tap paradigm. thats all the people that have ever used a phone and i doubt that a user study will ever find someone that hasnever used a phone to test wit him 07:30:56 yeah Sailfish OS user experience is not any static thing, but evolves over time 07:31:41 we are not deliberately moving away from the gesture paradigm, effortless gesture usage is still very important for us 07:32:26 (didn't say before - sorry for being late, am busy at work) 07:32:46 There have been little inconsistencies throughout the OS itself all along, eg. Settings / Accounts has a ersatz-button "Add account" instead of a pulley menu item as one would kinda expect. 07:33:02 the changes that break the UI seem to come from aurora people. are those people familiar with the os or they do whatever 07:33:11 Dumping ambience support when introducing the buttons in the email client does make such statements ring a bit hollow, since that surely wasn't necessary 07:33:40 "Add account" is due to historic reason of account listing being part of app views with pulley reserved for other use cases 07:33:56 could use pulley yes, good catch 07:33:56 jpetrell_ as the designer do you have a say on what aurora people are doing?? 07:34:47 we are working together with Aurora design. we review carefully that all contributions align with the platform style 07:35:19 another example is the new phone answering. not the gestures but the graphics. who thought that thing looked nice with the rest of the UI?? 07:35:27 but sometimes we need to let some inconsistency in since fixing all use cases at once is such too much work 07:35:31 such = just 07:35:56 jpetrell_ are these going to be fixed?? 07:36:18 with the larger and larger screens single handed gestures also aren't getting any easier 07:36:32 i suspect that if the QML stuff are published and users can contribute many of these will be fixed by the community. 07:36:33 please spare me with double quatation marks, I don't want us shout 07:37:15 I have been drafting forum post about the incoming call redesign, to give a bit of background and rationale behind the changes 07:37:21 not finished but hopefully soon 07:37:59 the UI controls are a bit small, we should make them a bit bigger. though Sailfish OS is airy, can have air around the components 07:38:01 #info a forum post from Jolla's UX chief Joona is in the works, explaining incoming calls redesign rationale 07:38:58 jpetrell_ :) 07:39:13 I like the new incoming call dialog though sometimes it mixes answering and swiping left/right to get to the unlock screen up which is mildly annoying since the only way back seems to be to unlock 07:39:15 correct me please, but isn't the switch to gecko in emails is the main cause of buttons? i think browser also technically cannot have pulleys in the web engine rendering view due to the same constraints? 07:39:23 personally I like the subtle animations of phone handle wiggling on the new design, and arrow indications animating, mimicking user's finger 07:39:41 sledges, that's my understanding too. 07:39:46 or more likely, was it text selection that prevents pulleys 07:39:56 the phone handle looks like nothing SFOS related. 07:40:08 the actual graphic i mean 07:40:29 3min remain 07:40:52 sledges havent users already patched it to work with pulleys?? 07:41:01 saw some stuff in openrepos and in forums 07:41:06 we can talk about design endlessly (next topic too), i remember when i used facebook, each of its Web UI facelifts was met with anger and rage, always from different groups of users:) 07:41:22 ApBBB would be good to know more 07:42:34 was mainly talking of the top of my memory:) 07:42:55 sledges https://forum.sailfishos.org/t/3-4-0-22-ui-inconsistences-in-email-client/2354/43 no idea if that broke something 07:43:21 ok thanks, moving onto the next UI topic 07:43:22 #topic UI (15 min -- asked by Sefriol) 07:43:26 #info Old SFOS Case Study: 07:43:29 #link https://together.jolla.com/question/195283/sailfish-os-ux-case-study/ 07:43:32 #info Broader topic, but in general SFOS has from the start been about one handed ease of use and intuitive gesture control. Latest “major” update was the inclusion of tabs. 07:43:38 #info However this is also something that highlights one of the “problems” with current gesture controls: horizontal swipe. It needs to be really precise when there is vertical content. 07:43:44 #info Example of using natural “arc swipe”: 07:43:47 #link https://t.me/SFOSFanclub/40662 07:43:59 #info Also with the inclusion of top menu, official supported devices start to get taller and taller, making it harder to reach. Maybe allow to customize UI so that you could get it from the bottom instead? 07:44:08 yes we had technical limitations with integrating gecko and pulleys together, but also pulleys work best with only few actions and on email app views you often a lot 07:44:08 ApBBB: good luck trying to patch that :D 07:44:25 Sefriol doesn't seem to be around, but here's the answer 07:44:26 #info Tweaking of touch parameters is definitely area that should get more focus, there are already known touch issues with e.g. Keyboard, Camera and Gallery (also reported by community in the forum). We are also aware of regression in one-handed usage due to the growth of average phone display dimensions. 07:45:07 jpetrell_ i just saw it. didn't try ti. neither know if it works 07:45:51 pulley activation is always tricky, as it depends on the current scroll location in the view, also. 07:45:54 hopefully the iphone 12 mini will become a huge success and other mfgs will start making sanely sized phones again. and jolla can support those. :P 07:46:15 and we will be able to use SFOS one handed like normal people 07:48:03 yeah these super tall displays are one-handed nightmare 07:50:10 but there is a plethora of things to improve: mid-screen notifications, sticky app grid, gravitate top menu contents towards the bottom, pull (stretch) down the top of the list to access topmost items 07:50:29 call-ending dialogue was a good step forward 07:51:56 sledges it would look better in the middle of the screen IMO. 07:51:57 retaining the UI elegant (not bottom-heavy/empty-at top) is a challenge though 07:52:04 not that its bad or something 07:52:46 yeah system dialogs in general should appear lower on the screen. on Jolla 1 you could reach e.g. WLAN hotspots in connection dialog without problems, but nowadays you need two hands 07:52:50 ApBBB, the idea with it being at the bottom is that it's easier to access for one-handed use. 07:53:47 problem showing content at the bottom where your thumb naturally lies is that you can accidentally perform actions 07:53:56 flypig yes i get it. but i am also picky with my HW choices so i can still reach stuff :P 07:54:20 thats why i said i hope the iphone mini becomes a hit 07:54:51 ApBBB :) Yes, I see your point. These things (phone hardware sizes) do seem to go in cycles, so let's see. 07:54:57 latest firefox for android dropped their url bar to the bottom (the resemblance is uncanny:) abranson was the first to spot this:)) 07:55:36 3mins remain 07:55:40 sledges SFOS does many stuff right 07:56:57 our browser issues were alway functionality related 07:57:00 i know people using 5 year old phones because they can't find new ones small enough 07:57:01 or engine 07:57:27 abranson there aren't many sadly 07:58:22 and with SFOS its even more difficult 07:58:30 engine is now esr52 going on esr60 :) 07:58:35 ok, next topic is a quick one 07:58:43 #topic QML component separtion (5 min -- asked by Sefriol) 07:58:47 #info Separating QML components from closed source and publishing them to git: 07:58:50 #link https://forum.sailfishos.org/t/separating-qml-components-from-closed-source-and-publishing-them-to-git/1894 07:58:53 #info Maajussi promised to take a look. Any updates on this front? 07:59:01 #info No news available at the moment to share. Need to come back to this later. 07:59:09 so we can move on:) 07:59:33 #topic Overlay apps in 3.4 and later (15 min -- asked by coderus) 07:59:39 #info 3.4 update has broke overlay apps utilizing window category properties. Launching such apps produce black screen. Problem was reported internally long before 3.4 update came out, but no action/suggestion was taken. 07:59:52 #info 3.4 update obsoleted some useful applications and “bricked” devices of some users. Jolla position was: “we never officially supported this kind of hack for overlay apps, so it’s your own fault”, in my opinion it looks very frustrating, my apps was allowed and published to Jolla Store with no problems. 08:00:05 #info Just tell if proper/replacement API is/will be available for making overlay apps? I need to decide the future of my applications. 08:00:12 and the answer is 08:00:26 #info Looks like the system considers your window to be full-screen (fully opaque) if the background drawing gets disabled. Commented to the forum topic some ideas how your app could be fixed, let's continue the discussion there: 08:00:30 #link https://forum.sailfishos.org/t/3-4-bug-lack-of-opacity-for-overlayed-window/1449/10 08:00:46 is coderus around? 08:01:34 sledges: hi 08:01:43 you pointed to private stuff :) 08:01:56 i want this issue to be more public 08:02:49 tl;dr: none of suggested approaches worked, overlay is not functioning 08:02:53 the topic talks about apps in plural, could we list the apps here so we can try to see what is broken 08:03:24 jpetrell_: me and users commented in forum topic of meeting 08:03:55 #info list of overlay apps: 08:03:57 #link https://forum.sailfishos.org/t/community-meeting-on-irc-15th-oct-2020/2425/10 08:03:58 https://forum.sailfishos.org/t/community-meeting-on-irc-15th-oct-2020/2425/10?u=coderus and down 08:03:59 Maybe it's useful to list them here for the logs too. Things like Battery Overlay, ScreenTapShot2, Edge mode in Aliendalvik Control, okboard, taskswitcher. 08:04:23 thanks :) do they all use the same hack? 08:04:27 #info Battery Overlay, ScreenTapShot2, Edge mode in Aliendalvik Control, okboard, taskswitcher 08:04:27 (I just stole all those from the forum) 08:04:30 phonehook 08:04:41 Tint Overlay as well 08:04:45 #undo 08:04:45 Removing item from minutes: 08:04:46 #undo 08:04:46 Removing item from minutes: 08:04:50 jpetrell_: yes same hack 08:05:00 #info Battery Overlay, ScreenTapShot2, Edge mode in Aliendalvik Control, okboard, taskswitcher, phonehook, Tint Overlay 08:05:15 ok sounds like we should provide a proper mechanism that won't break the next day 08:05:32 jpetrell_: thats the only point of my question here 08:05:39 current solution uses internal properties in a way not even internal use cases do 08:07:05 one issue is that badly behaving overlay app can brick the device, if we provided that kind of functionality in stable API we would make sure user is in control and cannot be blocked from going other tasks 08:07:05 thanks, we can move to the next question 08:08:52 #info in the light of many actual apps use an overlay hack, a need for stable API is augmented 08:09:36 indeed, even apps that aren't using it may want to use it once an API is available 08:11:24 jpetrell_: but since we just rolled out 3.4.0, the status quo is there to stay unfortunately, is Jolla able to prioritise the stable API effort? 08:11:36 finally a good application of the rage-shake gesture - hide all overlays :) 08:11:48 :D 08:13:32 sledges: I cannot say before discussing internally other than we will look into it 08:13:54 but I think we can get some kind of fix pretty easily if not yet stable 3rd party API 08:13:54 perfect, thank you. just wanted a message (of any nature) to all of those apps' users 08:13:55 (Some time ago, I asked about Motorola-style shake gestures, eg. for switching the flashlight on and off) 08:15:09 with the slippery material choices mfgs use this sound like a really bad idea. :P 08:15:13 #info regarding the stable API work prioritising, Jolla cannot say before discussing internally other than we will look into it 08:15:21 as per above, moving on 08:15:31 #topic Improving the calendar design (10min -- asked by Raymaen) 08:15:37 #info It would be great to get an official Response from Jolla designers to this topic and if there are plans to make the calendar app more useful for business purposes and get a better overview over the appointments. even if it is somehow similar to my draft: 08:15:43 #link https://forum.sailfishos.org/t/improved-calendar-design/1579 08:16:07 Raymaen said they mightn't be about, so will just answer this: 08:16:12 #info We are constantly working on calendar app, recently more on the bugs than design. The minimal main calendar flows could (should) definitely be improved. 08:17:36 Maybe I can also take the opportunity to shout out dcaliste for his great work on the calendar. 08:18:01 yes, definitely. 08:18:07 and not only there 08:18:14 massive thanks to dcaliste for his ongoing hard work and great help 08:18:20 +1 08:18:21 #info a shout-out to dcaliste for his great work on the calendar (community member contributing internally, yes it's possible, apply herein;) 08:18:54 +1 yeah he is superb 08:20:15 ok, we've time to move to a shortened General discussion 08:20:23 #topic General Discussion (5mins) 08:21:03 what are the chances of Jolla selling a license for Android on devices that are not "officially supported" 08:21:04 3.4.0 was a huge update, checkout https://blog.jolla.com about it 08:21:17 flypig is contract comming to the store when its ready or it uses not allowed stuff?? 08:21:29 ApBBB, not allowed stuff, I'm afraid. 08:21:36 i hope 3.4.0 hotfixes (since the first EA) ironed out the most of pain-points 08:21:37 meh :/ 08:21:56 #link https://blog.jolla.com 08:23:11 KeeperoftheKeys: let us catch up breath after the release:) but the biggest issue with such licences is when there's money involved, people automatically expect nothing to break (correct me if i'm wrong, maybe you have other linuxy examples where this works well) 08:23:21 BTW with all these user changes. will/are you able to use a normal user name instead of nemo when you set up a device?? like you do on a normal distro 08:23:39 since Jolla is currently only supporting models that don't supersede the Xperia X and also has not provided a decent update to Android on the Xperia X 08:23:57 KeeperoftheKeys the less android the better 08:23:59 :P 08:24:15 Isn't "nemo" a bit like "pi" on Raspberry Pi's, an operating system default? 08:24:16 Though on an ideological level I agree with you 08:24:46 on a practical level if I want SFOS to be my daily driver I need the ability to run certain Android apps 08:25:07 ApBBB: on clean 3.4 install it is defaultuser already 08:25:15 the username thing is great, high time 08:25:16 maybe nemo is still in ports 08:25:19 ApBBB: you can rename the main admin user (the internal name is nemo, or if you reflash, it's 'defaultuser', but friendly name can be changed in the UI) 08:25:38 thanks. 08:25:52 If I understand correctly, the additional (non-admin) users have a name that depends on what the user chooses. 08:25:55 sledges: I think you mean "you can NOT rename".. 08:26:04 we can't have a "real" internal username? 08:26:09 i'd like to rename the actual username... but that's not possible? 08:26:13 default users are terrible (security wise) 08:26:17 ViGe: yes you cannot rename the low-level username, but "Default User" friendly name can be renamed 08:27:17 low level you mean as the one you use on a normal distro when you crete a user 08:27:23 #info One participant just said "the less android the better", and this tweet just backs it up (I hope Fernschreiber receives a lot of contribs as it's FOSS!) 08:27:26 #link https://twitter.com/Ygriega/status/1307765659619725312 08:27:38 ApBBB: yes 08:27:48 ok. 08:27:57 will this be possible in the future ? 08:28:36 ie you install > you choose a name and a hostname as on a normal distro 08:28:54 systemd-homed is really cool doing stuff like that in case you havent played with it 08:28:59 that would become too complicated for non-techies 08:29:13 On e.g. Pinebook (PRO) you use tools to rename the user after the fact 08:29:27 ok, time to move on 08:29:29 NotKit, you will know better, but previously nemo was baked into the image. I thought defaultuser was not. 08:29:34 #topic Next meeting time and date (5 min) 08:29:38 Proposing 28th October at 7am UTC 08:29:55 what about a real update for the Xperia X has that ship completely sailed or will something be done after all the backlash on the subject? 08:30:35 BTW Fernschreiber is a toungue twister if you are not german :P 08:30:53 ApBBB, agreed :) 08:31:09 We should have a halloween themed meeting on the 28th. 08:31:20 cool one less app that requires Android, but WhatsApp still blocks 3rd party 08:31:39 And much though I dislike FB it's practically a work tool for me 08:31:43 just call it Fern:) 08:32:06 sledges the dev should do that 08:32:19 ok you tell 'em :D 08:32:23 no objections, so 08:32:23 #info Next meeting will be held on Thursday 28th October 2020 at 7:00am UTC: 2020-10-28T07Z 08:32:30 Thanks! 08:32:50 halloween theme means all smileys are like ":["? 08:33:04 turn your unanswered questions into topics for that meeting! 08:33:08 Perfect! :[ 08:33:10 chairs everyone! 08:33:16 #endmeeting