09:00:04 <Jaymzz> #startmeeting Sailfish OS, open source, collaboration – 14th November 2019
09:00:04 <merbot> Meeting started Thu Nov 14 09:00:04 2019 UTC.  The chair is Jaymzz. Information about MeetBot at http://wiki.merproject.org/wiki/Meetings.
09:00:04 <merbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
09:00:20 <Jaymzz> I am the meeting’s chairperson today, and will be doing my best to keep time and order. Please behave, respect the timings and be gentle.
09:00:30 <Jaymzz> #topic Brief introduction (5 min). Please prefix your name/handle with # info
09:00:38 <Jaymzz> #info James Noori - sailor @ Jolla
09:00:56 <jwalck> #info Jonatan Walck - community lurker:)
09:01:12 <ViGe> #info Ville Nummela - sailor @ Jolla
09:01:17 <Jaymzz> #info Meeting information and agenda can be found here: https://lists.sailfishos.org/pipermail/devel/2019-November/008910.html
09:01:36 <ExTechOp> #info Otto Mäkelä - community
09:02:19 <Nico[m]> #info Nico - community
09:02:23 <dcaliste> #info Damien Caliste, community
09:02:23 <flypig> #info David Llewellyn-Jones - sailor @ Jolla
09:02:34 <Mister_Magister> #info Mister_Magister - community
09:02:39 <sledges> #info Simonas Leleiva - privateer for Jolla
09:03:00 <KeeperoftheKeys> #info KeeperoftheKeys - community dev
09:03:10 <Thaodan> #info Björn Bidar - community dev
09:04:14 <minodesign> minodesign / J-D blogger, designer
09:06:04 <Jaymzz> quite many atendees today! lovely
09:06:16 <adantes> it's gaining traction
09:06:22 <Mister_Magister> Jaymzz: there were more
09:06:27 <KeeperoftheKeys> long list of subjects
09:06:44 <Jaymzz> 1st topic coming up
09:06:49 <Jaymzz> #topic SSH connectivity (Asked by KeeperoftheKeys – 10 min)
09:07:02 <Jaymzz> #info It is not clear to me how exposed SSH is on the phone, netstat tells me SSH is listening on all interfaces, and though I recall that there was some mention of SSH being locked down a bit in some previous release I haven't been able to find it. SSH is reachable over both USB and wireless which is OK (though for wireless maybe a 'trusted network' flag would be nice) however it may actually also be reachable over the cellular con
09:07:02 <Jaymzz> nection which is far less welcome definitely considering the use of a standard username.
09:07:30 <Jaymzz> KeeperoftheKeys: here comes the answer so you can discuss if you want ->
09:07:46 <Jaymzz> #info Restricting access to SSH from cellular network was released in 3.0.2 using a firewall. Even though you see sshd listening on all interfaces it's only connectable from Wifi or USB. You can find the rules for this in /etc/connman/firewall.conf and its associated firewall.d directory (though USB is configured separately). There's currently no way to lock SSH down to only 'trusted' WiFi networks; it's a nice idea. There are the s
09:07:46 <Jaymzz> tandard SSHd config options to use only keys and prevent password access, and to restrict access from specific IP addresses (for example see: https://debian-administration.org/article/685/Restricting_SSH_logins_to_particular_IP_addresses ). Both reduce the attack surface and help protect against opportunistic scanners.
09:07:57 <Jaymzz> #link https://debian-administration.org/article/685/Restricting_SSH_logins_to_particular_IP_addresses
09:08:45 <adantes> passwords and keys are not enough anymore?
09:09:33 <KeeperoftheKeys> Excellent
09:10:30 <KeeperoftheKeys> the reason I ended up asking was that I recalled wifi was also supposed to be blocked and ssh over wifi was/is very flaky
09:10:31 <Mister_Magister> you can make ssh available to key only login isn't that enough?
09:10:42 <Mister_Magister> or change port or other things you do on server
09:10:42 <Nico[m]> I think having something like coderus' SSH access confirmation baked in would be nice, although that package works on its own right now
09:11:02 <KeeperoftheKeys> Changing the port is security through obsucirty no good for nothing
09:12:10 <KeeperoftheKeys> key auth is an excellent option and ssh is generally a fairly secure package but even sshd has regular security issues and if it were exposed to cell that would be a bad idea (at least for people like me with always on cell-internet)
09:12:41 <flypig> There's not much benefit to SSH over cellular either.
09:13:17 <flypig> Somewhat separate issue, but probably most networks restrict device-device connections anyway, I'd have thought.
09:13:30 <KeeperoftheKeys> Where I am cell is CGNAT so yeah useless except for someone who wants to attack the phone
09:14:22 <KeeperoftheKeys> Do you rely on how secure your provider makes you? because that is secure enough for the good people not for people with bad intentions
09:14:26 <Jaymzz> KeeperoftheKeys: time is almost up, 3 min left. Do you need a few extra minutes?
09:14:30 <jlaakkonen> There are some operators that give a public IP for mobile network as well.
09:15:30 <KeeperoftheKeys> once IPv6 is common I expect everyone will get public IPs but atm we're not there yet
09:15:33 <sledges> KeeperoftheKeys: check that the phone is not in a suspended state when you observe ssh over wifi being flaky
09:15:53 <adantes> most ways of hacking/cracking ssh are bruteforce; how about use 16+ chars passwords, it probably takes 2/3 years to crack, and with a key, passwords are rejected. Even the correct one
09:16:04 <adantes> Is this a real issue?
09:16:20 <KeeperoftheKeys> when the screen turns off it suspends or only after that? and should it if a remote user is logged in?
09:16:32 <abranson> that 'keep display on while charging' option in the display settings is good for keeping the device awake while SSHing
09:16:36 <ViGe> jlaakkonen: Some operators even give you a static public IP if you give them enough money ;)
09:16:54 <sledges> abranson: it does not suspend while charging
09:17:06 <jlaakkonen> ViGe: also that :)
09:17:14 <KeeperoftheKeys> ok I'll check that
09:17:14 <sledges> KeeperoftheKeys: there hasn't been much work done in that area
09:18:10 <sledges> KeeperoftheKeys: you can experiment with the "ServerAliveInterval 60" ssh config for better results over wifi
09:18:36 <KeeperoftheKeys> adantes - the device by default ships with password auth, so that is what you need to deal with, if the default was generating a key etc (even when you set a password) then you could argue it was less of an issue, though still services need only be exposed for good reasons
09:18:47 <Jaymzz> KeeperoftheKeys: time is up. I'll give you 5 extra min
09:19:00 <jlaakkonen> But I agree that there could be some setting to explicitly select the WiFi networks to allow for incoming SSH.
09:19:07 <Jaymzz> #info 5 extra minutes added to this topic
09:20:13 <Thaodan> jlaakkonen: maybe firewall rules that can restric the wifi networks you can connect from?
09:20:22 <KeeperoftheKeys> If there was such a flag it could potentially be used for more - any service you would only want to expose on a trusted net
09:20:54 <KeeperoftheKeys> You could have different rules applied based on what network you are on
09:21:11 <jlaakkonen> Thaodan: no, I was thinking more of a WiFi setting toggle, and a plugin to connman, that, whenever a Wifi goes up it checks if ssh is allowed and then applies the rule for the duration the wifi is online
09:21:28 <Thaodan> Could we restrict the sshd service via systemds sandboxing?
09:21:32 <Jaymzz> KeeperoftheKeys: try to wrap it up soon. won't be able to give you extra time after this. It's packed today!
09:21:39 <sledges> KeeperoftheKeys: you can check when device is actually suspended by observing the suspend_time value in `mcetool --get-suspend-stats` (install mce-tools package)
09:22:05 <KeeperoftheKeys> I think the SSH question was aswered sufficiently
09:22:23 <Jaymzz> ok so the rest can be talked about during general discussion
09:22:30 <Jaymzz> we shall move on
09:22:46 <Jaymzz> ApBBB: your topic coming up
09:22:56 <Jaymzz> #topic Design elements of SFOS that started to show their age and UX/UI issues. (Asked by ApBBB – 20 min)
09:23:09 <Jaymzz> #info SFOS is some years old now and certain elements (ie app icons, indicators etc) have started to show their age. Is there going to be a redesign anytime soon??? Also there have been consistency issues (small and most likely easily fixable) i the UI/UX noted by the community for quite a while now that haven't been addressed. Anything jolla plans to do?
09:23:49 <Jaymzz> #info We are gradually upgrading our asset. We appreciate all the feedback to identify existing problems. Helping the development team with a detailed list of the known occurrences of the problem is always invaluable.
09:23:57 <Jaymzz> the answer^^
09:25:06 <Jaymzz> unfortunately ApBBB can't reply over here because the channel requires registration. He is talking to me in DM, so I'll be pasting what he says over here
09:26:08 <sledges> lbt: could that be fixed somehow? ^
09:26:10 <Jaymzz> He just wrote to me that he has nothing more to add and the answer is sufficient. Does anyone else have anything to add here? Otherwise we can move on
09:26:12 <sledges> (just logging for the record)
09:26:20 <abranson> can we drop that requirement now the spam storm is over?
09:26:30 <Jaymzz> abranson: I think we should
09:26:39 <sledges> we removed the -n param, but it still requires registration
09:27:11 <minodesign79> registration is somewhat awkward
09:28:11 <Thaodan> Its a hurdle especially for webui users that want to connect spontanius
09:28:47 <minodesign79> you can't do it on the go
09:29:25 <KeeperoftheKeys> agree
09:29:39 <minodesign79> (you have to read a wiki only to perform the command lines)
09:30:29 <Jaymzz> We can take this registration issue on general discussion as well. Moving on in a second
09:30:47 <Jaymzz> minodesign79: your topic coming up
09:30:49 * lbt has a look
09:31:06 <Jaymzz> #topic Enable/fix bluetooth 4 for Android wearable apps (asked by minodesign79 – 5 min)
09:31:17 <Jaymzz> #info It seem that Android wearable apps are not able to connect with their related devices. An example are the MI Bands: the MI Fit app, is downloadable and working, but can't pair with Mi band 3 on XA2 because of a 'no BT 4 error'. If it's not a security breach it would be nice open the access for Android apps, or check/update BT drivers on Android side. (There are some duplicated request on TJC)
09:31:25 <Jaymzz> minodesign79: It's TJC btw not TJT ;)
09:31:50 <Jaymzz> And here is the answer:
09:31:54 <Jaymzz> #info It is not supported at the moment and there is no ETA to when it will be. Unfortunately giving Android Apps access to Bluetooth is not as simple as allowing it to access the hardware directly since then Sailfish OS and AlienDalvik would interfere with each other, what complicates the situation is that android APIs (bluedroid/fluoride) and Sailfish OS APIs (bluez5) differ quite a lot so a direct translation is also not easy to
09:31:54 <Jaymzz> implement.
09:32:02 <minodesign79> typo 😬
09:32:57 <r0kk3rz> it should be easier with bluebinder right?
09:33:03 <minodesign79> ok I supposed there was a tech reason
09:33:18 * lbt notes registration block is removed
09:33:49 <minodesign79> even earphones BT are involved? (I didn't checked)
09:33:55 <Jaymzz> lbt: fantastic!
09:34:12 <r0kk3rz> all BT
09:35:06 <Thaodan> bt phones aren't directly exposed
09:35:32 <flypig> BT earhpones work okay with Android apps in my experience.
09:35:39 <mal> headphones should be handled by sailfish
09:35:41 <r0kk3rz> the audio is routed yeah
09:36:04 <abranson> r0kk3rz: a bit, but those hw binder interfaces expect only one client. still can't really be shared.
09:36:28 <r0kk3rz> abranson: sounds like a thing that could possibly be managed, poorly
09:37:10 <Thaodan> Imho bluetooth device shouldn't directly be exposed.
09:37:11 <abranson> r0kk3rz: yeah, it's still a lot of work to get anything usable. always has been.
09:37:14 <schmittlauch[m]> Could it be a workaround to temporarily grant Aliendalvik exclusive BT hardware access? That's not sufficient for longer-running connections, but fine for short data transfers.
09:37:20 <minodesign79> ok. So there may be a basic audio function working, and other non working
09:37:27 <Jaymzz> minodesign79: time's up :) do you want extra minutes? we have some left over from the last topic
09:37:43 <Thaodan> schmittlauch[m]: No that would break the OS an apps that use them.
09:37:50 <minodesign79> depending on the earphone / app involved
09:38:03 <Thaodan> Those would disconnect if everything is ok.
09:38:04 <minodesign79> nope. No need for this
09:38:23 <minodesign79> topic
09:39:09 <Jaymzz> ok moving on then'
09:39:15 <abranson> must mention that there are a couple of smartwatch/fitness band community apps out there already
09:39:40 <abranson> for e.g. the amazfit and the defunct pebble ;)
09:39:55 <Jaymzz> #topic UI topic: Bold/accessible mode (asked by minodesign79 – 5 min)
09:40:05 <Jaymzz> #info I noticed the absence of 'boldness' on SF OS UI typography. This topic is not about a graphic discussion, it's more about accessibility: it would be nice an Option like "Make test bolder" that modifies All the fonts on UI with the source pro Bold (or the bold variant of font used).
09:40:29 <Jaymzz> #info  We have also identified the need to improve legibility on Sailfish OS. Some enhancements have already been introduced in the current Sailfish version, for example light ambiences have slightly thicker fonts to improve legibility. Improving accessibility options to have different typefaces is a possibility we are considering. While we have ongoing tasks to improve this area, it may be good to share some light on the complexity
09:40:29 <Jaymzz> of the problem. At the moment Sailfish uses several different fonts for different languages, in addition we have different input systems implemented. We have also created custom glyphs for certain symbols and letters for our main font Source Sans Pro Light. Nevertheless as said, we believe that legibility can and should be improved.
09:41:22 <Jaymzz> minodesign79: anything to add? :)
09:41:29 <minodesign79> Yes. Probably an accessibility area is out of time
09:42:00 <minodesign79> (I am studying some accessibility lectures and this inspired me to topjc)
09:42:20 <minodesign79> Also there is the app from
09:42:26 <minodesign79> itsamefra
09:42:47 <minodesign79> on openrepos which can change fonts, I remember
09:43:23 <Jaymzz> yeah
09:43:37 <minodesign79> maybe also
09:43:49 <minodesign79> (going graphically)
09:44:17 <minodesign79> consider the usage of Bold to highlight some heading
09:44:28 <minodesign79> or create differetiation
09:44:45 <Thaodan> Maybe change the font in a accesabity menu depending of the type of the disability that the user selects.
09:45:11 <minodesign79> ...the font (Source Pro) is distinctive
09:45:31 <minodesign79> and I see some variant online. (Used on site)
09:45:37 <Jaymzz> #info ideas: create differentiation in the fonts for an easier understanding based on the user's disability.
09:45:45 <KeeperoftheKeys> Just out of curiousity how accesible is SFOS to color blind people? I can imagine that at least some of the ambiances are completely unuseable to them
09:45:49 <Jaymzz> #info ideas:  Maybe change the font in a accesabity menu depending of the type of the disability that the user selects.
09:46:11 <Jaymzz> jpetrell: Are you available for a moment to look at these ideas? :)
09:46:19 <Thaodan> Thanks Jaymzz for taking me suggestion :)
09:46:27 <Jaymzz> Thaodan: anytime!
09:46:33 <KeeperoftheKeys> maybe also a high contrast ambiance
09:46:51 <Jaymzz> #info ideas: a high contrast ambiance
09:47:13 <minodesign79> ideas:
09:47:21 <Thaodan> KeeperoftheKeys: Or add warning for ambiences that don't work very good with the selected disablity
09:47:34 <minodesign79> I see on an old oneplus a button to Invert colours
09:47:47 <Thaodan> Like the red stock ambience because of the color.
09:47:48 <elfio> It would be nice to be able to use an smaller font size. Maybe this could be an option?
09:48:23 <minodesign79> (that said, design for usability is a tough question, and need time)
09:48:28 <elfio> Sometimes I feel like font is too big. Compared to my Moto G running Android, default font size in SFOS is bigger than android's
09:48:45 <Jaymzz> #info idea suggestion from ApBBB: a black and white ambience
09:49:14 <flypig> Yes, it's interesting, I think fonts on Android and iOS have been getting smaller as screen sizes have been increasing.
09:49:26 <jpetrell> KeeperoftheKeys: we have color blind people working in Jolla, ambiences don't use many colors so not being able to differentiate between two colors is less of an issue. as such not all ambiences need to be perfect for all people, some ambiences can have more contrast, others more visually striking
09:49:26 <Jaymzz> minodesign79: I don't think jpetrellis available right now to take a look at these, but I will remind him to take a look at the logs later on
09:50:03 <minodesign79> 👍
09:50:27 <Jaymzz> :D the exact same second!
09:50:38 <elfio> flypig: actually the phone I'm using for comparison is a 2013 Moto G :)
09:50:46 <elfio> 4.5" of screen
09:50:58 <KeeperoftheKeys> jpetrell: good to know :)
09:51:37 <elfio> Smaller font size allows to increase information density or make UI clearer keeping the info density constant
09:51:53 <jpetrell> elfio: yes the font could be smaller. we support dozen different scale variants, sometimes device falls in between two size variants, but we cannot maintain own variants per device
09:52:20 <minodesign79> elfio yes I think Sailfish OS was designed on 4"
09:52:32 <minodesign79> then it's scaled to XA2 plus
09:52:33 <jpetrell> there is possibility to override each geometry and icon size per device, which we did for Jolla Tablet
09:52:52 <elfio> My suggestion would be to make it available in settings so users could switch from default to smaller font size
09:53:12 <minodesign79> I seen. JT was sailored
09:53:33 <minodesign79> this will be fine for Xperia 10,
09:53:47 <minodesign79> where Androis instead is too tiny
09:53:53 <minodesign79> with 5 rows
09:54:31 <Jaymzz> minodesign79: FYI we are way over time on this one. So try and wrap it as soon as you can so we can have time for the rest of the topics too
09:54:34 <elfio> That's it. I didn't want to hijack the topic :)
09:55:00 <minodesign79> Done
09:55:02 <jpetrell> elfio: we support making font size larger than the base, required touching 50+ projects and making hundred small fixes.  scaling down from the base configuration similarly requires non-trivial work effort
09:55:04 <Nico[m]> Having a small font in the display setting would be nice, I agree
09:55:11 <jpetrell> but yes would be nice indeed
09:55:33 <Jaymzz> #topic "Swipe Down" gesture behavior (asked by minodesign79 – 5 min)
09:55:35 <elfio> jpetrell: I see. Well, it's just my opinion :)
09:55:47 <Jaymzz> #info Adding an option under 'Gestures' where the user can activate the old school "Swipe down to close". A lazy solution could be to place an option to chose from: "Available also on apps", and "Only from home view".
09:55:58 <jpetrell> elfio: some day :)
09:56:04 <Jaymzz> #info We are very much aware of the topic, and for this reason we have also studied the behaviour. In addition we should not forget that we have repeated feedback that many users struggled with the old swipe down to close gesture. Creating an option is something that we prefer to avoid. Options can increase the complexity of the software and result to higher maintenance effort. As a reminder, the Sailfish 3 has a "Swipe down to clos
09:56:04 <Jaymzz> e app" gesture near the corners and it seems to work fairly well with the top menu access that many people expect from the top center.
09:56:08 <minodesign79> for the nostalgic
09:56:17 <elfio> jpetrell: yay!
09:57:48 <Jaymzz> minodesign79: anything to add?
09:57:59 <Mister_Magister> i bet there's gonna be patch for that :P
09:58:06 <schmittlauch[m]> IIRC the "swipe to close" gesture in the corners is even advertised with one of the tutorial overlays, so it should be discoverable.
09:58:06 <Thaodan> Maybe add an option to change the trigger radius.
09:58:15 <adantes> I guess the swipe down to close, like it's implemented in sfods 3 is perfect
09:58:30 <minodesign79> yes there are patches 😋
09:58:37 <Thaodan> I noticed that the border is sometimes to small
09:58:56 <Thaodan> *s/border/area
09:59:04 <Mister_Magister> Thaodan: it's even worse with rounded screen
09:59:12 <Mister_Magister> where edges don't count
09:59:17 <schmittlauch[m]> Thaodan: As they said, gestures are complicated. But maybe the radius should be differenmt per device?
09:59:20 <Thaodan> rounded screens are weird
09:59:45 <schmittlauch[m]> So is the same radius (fixed or relative) used over all devices and screen sizes?
09:59:48 <jpetrell> would then increase the gesture trigger area a bit instead of making it configurable by user
09:59:49 <Thaodan> thats probably because the edges are on the corner or have no touch.
09:59:58 <jpetrell> we could perhaps make it configurable per device
10:00:05 <Thaodan> jpetrell: yes and yes
10:00:11 <minodesign79> other options
10:00:29 <mal> per device config would make sense
10:00:42 <schmittlauch[m]> jpetrell: Is it a relative (% of width) or fixed radius currently?
10:00:43 <elfio> maybe it makes sense to add a preview while the user is configuring it, like picturing the zones that are for each gesture
10:01:16 <Venemo> I think we even have gesture hints for this
10:01:54 <jpetrell> schmittlauch: would need to check but I guess relative to scaling ratio, i.e. physically the area should be roughly the same between displays
10:02:12 <schmittlauch[m]> Because for smaller devices we need to ensure that each segment is large enough to trivially trigger, while at larger devices the screen middle might be unaccessible.
10:02:36 <schmittlauch[m]> at least when using the device single-handedly
10:03:04 <Venemo> I think the area is just right on the XA2
10:03:08 <jpetrell> personally I am missing an easy gesture to blank the display, I think we should get it back somehow
10:03:25 <Venemo> jpetrell: good idea
10:03:38 <jpetrell> to be useful it should 1. Be available no matter where you are in the system 2. Always work the same way 3. Be easy to perform, but not too easy to avoid accidental triggering 4. Not happen surprisingly, but initially show some indication and hint so new users won't get surprised
10:04:15 <Thaodan> jpetrell: there's a patch that enables this by registering a small swipe down as screen of and a large as top menu.
10:04:15 <Venemo> we still have a couple of corners that are not yet used by any gesture
10:04:28 <minodesign79> not that sure about screen indicators...
10:04:35 <jpetrell> Thaodan: cool
10:04:40 <minodesign79> or corners
10:04:54 <schmittlauch[m]> jpetrell: Closest we have so far is Top menu -> lock. I'd suggest the lock symbol to automatically be triggered, similarly to what Thaodan suggested.
10:05:12 <schmittlauch[m]> That'd be true to the pulley menu concept
10:05:20 <jpetrell> yeah could work like pulley, you drag and release when lock is highlighted
10:05:29 <jpetrell> exactly
10:05:44 <Thaodan> jpetrell:  that was the patch https://openrepos.net/content/eugenio/patch-restore-swipe-lock
10:06:04 <Thaodan> With a bit of tuning this could be adopted as is.
10:07:38 <schmittlauch[m]> We'd obviously need some visual hints then, signalling whether the lock or the top menu is going to be activated.
10:08:21 <Jaymzz> minodesign79: big discussion on this one. Do you reckon we need more time? It's almost 10 min over time now
10:08:28 <Thaodan> thats why I said it requires tuning and some visual improvement.
10:08:33 <dcaliste> Gesture to blank officially back would be great! Having it like a pulley is fine and the lock blinking a bit after activation by pulley may signal that blanking will occur.
10:08:53 <minodesign79> yes!
10:09:21 <Thaodan> dcaliste: like a visual indicator if the gesture was performed like intented?
10:09:21 <dcaliste> About the close gesture on the edge, it's fine like that, but on portrait device like tablet, the area to close is really to small compared to the area for top menu.
10:09:37 <minodesign79> the issue is that swipe down to close is best action when done from center
10:09:53 <minodesign79> (remembering N9 habits)
10:10:20 <sledges> blank screen - when swiping the top edges from Home Screen (currently they do nothing from Home or Events, and could re-use swipe-to-close functionality)
10:10:35 <dcaliste> Thaodan, exactly, you begin the top menu gesture, it highlight or blink the lock icon if you stop on it and blank the device, if you continue to pull the nmenu continue to appears.
10:10:47 <Jaymzz> #info 10 min over time - adding 5 more minutes due to hot discussion
10:11:44 <Mister_Magister> why discussion dieded just now
10:12:37 <Thaodan> Adding some information where SFSOS could hint the user to use certain features could also be good. For example for a feature like this.
10:13:10 <Thaodan> I remeber blizzard doing something like this for their user interface addons in WoW
10:13:15 <Jaymzz> messgage from ApBBB: we shouldnt make gestures more complicated in any way. we already have two things that happen from the same direction (top, menu from center, close app from edge) and this is more than enough.
10:14:14 <Jaymzz> Seems like the discussion has died down a bit, we need to move on as it's lunch time in Finland and we have 2 more topics to get to
10:14:15 <KeeperoftheKeys> TBH I usually use the power button to blank and top-menu + tap on lock is also not a hassle...
10:14:23 <schmittlauch[m]> minodesign79: I think it's really a matter of taste. Just because of your N9 muscle memory there's no need fot adapting Sailfish to that.
10:14:26 <minodesign79> walking
10:14:26 <KeeperoftheKeys> that being said please lets move on
10:14:38 <Jaymzz> #topic Refining the Ambiences, Ambiences as file (asked by minodesign – 10 min)
10:14:46 <Jaymzz> #info Ambiences were a very nice, idea at beginning. What about making possible to export, and share own Ambience through a file? In this old Tjc thread I mentioned an Ambience free store, but there are copyright flaws. The ability to export and send privately an ambience to another SF phone can remain...
10:14:50 <dcaliste> ApBBB: the suggestion from sledges make sense in that direction to add blanking when applying the close on edge gesture in the home screen.
10:14:52 <Jaymzz> #link https://together.jolla.com/question/181188/make-ambiences-great-again-feature-request/
10:15:06 <Jaymzz> #info Cool idea. Since an ambience is mostly about content (wallpaper, ringtones) shouldn't require coding skills to share and upload ambiences out of the device. Polished ambiences need more control than device UI currently provides.
10:15:12 <Jaymzz> answer^^
10:15:33 <Thaodan> I think something like kde-look.org for SailfishOS would be good.
10:16:00 <Mister_Magister> it could be simple zip that gets extracted. here, your job is done
10:16:17 <Thaodan> the file could be just a tar.gz with the theme data and a json file with the settings that the ui can import
10:16:24 <Mister_Magister> it's literally 5 minutes job
10:16:29 <minodesign79> nice...
10:16:32 <Mister_Magister> Thaodan: we have same thinking xd
10:16:44 <Thaodan> Mister_Magister: there
10:16:57 <Thaodan> there's a saying for that in German..
10:17:02 <Thaodan> Maybe you know it :D
10:17:06 <Mister_Magister> nah :P
10:17:34 <Thaodan> Zwei Dumme ein Gedanke - two fools one thinking
10:17:40 <Mister_Magister> xd
10:18:08 <Mister_Magister> but seriously give me source, cup of coffee and one day and it's done. it's really simple to do
10:18:29 <Mister_Magister> so i see why jolla wouldn't do it
10:18:34 <Mister_Magister> can't see*
10:19:33 <Nico[m]> My guess would be, that they don't have a clear idea of how to deal with copyright of ambiance assets
10:19:38 <Jaymzz> minodesign79: what would you suggest as the owner of the topic?
10:19:45 <KeeperoftheKeys> ambiances ship as rpms at the moment no?
10:19:57 <minodesign79> just do it
10:20:01 <minodesign79> ahah
10:20:23 <minodesign79> In old times I dreamed about a ambiences store
10:20:27 <minodesign79> but
10:20:31 <Mister_Magister> Nico[m]: doubt, if it's user defined ambiences it's not their care about copyrights
10:20:41 <minodesign79> there are clear copyright issues
10:20:57 <Mister_Magister> not if we exclude jolla ambiences
10:21:01 <Thaodan> KeeperoftheKeys: rpms work as they work for other platforms like KDE but the are to much overhead and can't b created easily on the device.
10:21:37 <ljo> KeeperoftheKeys: Yes, and there are also ambiences in warehouse
10:21:41 <Mister_Magister> jolla doesn't care if you export your own ambience that has copyright issue
10:21:47 <Mister_Magister> store is different story
10:21:59 <KeeperoftheKeys> Mister_Magister: there are absolutely copyright issues with any ambiance, you create a store for them you need to start policing the content uploaded for copyright violation and have takedown policies
10:22:01 <Nico[m]> Mister_Magister: they would need sone way to respond to take down requests because of stolen images or audio files
10:22:08 <minodesign79> yes
10:22:13 <Mister_Magister> KeeperoftheKeys: store is different story
10:22:27 <minodesign79> I think that a bare option to export a file is ok
10:22:29 <Mister_Magister> i'm talking about import/export
10:22:45 <Mister_Magister> as a store we can just use openreops :P
10:22:53 <minodesign79> I remember on N9 sending contacts via nfc/bt
10:22:56 <Nico[m]> True, just the export/import stuff shouldn't be an issue
10:23:40 <minodesign79> and a pulley menu option to send for the user
10:25:07 <minodesign79> like a share
10:25:23 <Mister_Magister> Jaymzz: so what does the jolla say? :P
10:26:23 <Jaymzz> Mister_Magister: I think this topic should be continued later during our next meeting. That way we will have time to generate a good answer for it. It's a rather long discussion
10:26:44 <schmittlauch[m]> So the ideas are properly layed out, what do we make out of them?
10:26:51 <Thaodan> 👍
10:27:03 <Mister_Magister> Jaymzz: well just saying that export/import is too simple to not do it
10:27:13 <minodesign79> ok
10:27:59 <Jaymzz> Mister_Magister: sure, and I still have the same suggestion that we take this next time :D everything is logged anyway so there's nothing to lose
10:28:13 <Jaymzz> minodesign79: time is up though, I shall move on in a moment
10:28:26 <minodesign79> 👍
10:28:59 <Jaymzz> #topic Developer forum (by ViGe – 10 min)
10:29:04 <Jaymzz> ViGe: the stage is yours
10:29:08 <ViGe> thanks :)
10:29:35 <ViGe> So, we are planning to open a new discussion forum for developers
10:29:51 <ViGe> The plan is to use discourse as the platform
10:30:19 <ViGe> Now, we would like to get some feedback/ideas from the community about the structure of the forum
10:30:31 <ViGe> i.e. what kind of categories should we have?
10:30:48 <elfio> just out of curiosity, who is we?
10:30:55 <ViGe> We = Jolla :)
10:30:58 <elfio> cool!
10:31:19 <Mister_Magister> Category Other would be useful :P
10:31:29 <KeeperoftheKeys> Bug reports
10:31:48 <elfio> QML, Python and Qt (c++), maybe?
10:31:49 <ViGe> You can give your ideas right away, or later on via irc or email (I can be reached via ville.nummela@jolla.com)
10:31:57 <KeeperoftheKeys> Sections based on languages - QML/python/C++
10:32:01 <Mister_Magister> separation by the part of system. is it super low end is it apps, is it overall gui, is it lipstick
10:32:01 <Thaodan> ViGe: no "direct" categories but tags that can be viewed as sub forum
10:32:03 <elfio> o/
10:32:23 <schmittlauch[m]> Platform APIs
10:32:31 <elfio> Also, specific subforums or whatever for supported devices
10:32:31 <ViGe> Lot's of good ideas already :)
10:32:45 <elfio> you know, sometimes hardware makes the difference
10:32:49 <Nico[m]> I really like the idea, although I don't really like discourse. I think such a forum would really need a 'New developers' and 'Guides' section, for people that have trouble setting up the SDK and their first app as well as guides for popular topics
10:32:49 <KeeperoftheKeys> Thaodan: so that we have an unstructured mess where finding anything is hard like TJC? they might as well not add anything then
10:33:09 <minodesign79> see you!
10:33:12 <Mister_Magister> and ofc category for ports (that gonna be biggest :P)
10:33:15 <schmittlauch[m]> App Development vs Platform Development vs HW Adaptation
10:33:25 <elfio> tags for SFOS version would be nice as well
10:33:56 <Nico[m]> I.e. how to do background apps correctly, use alternative compilers, build systems, etc
10:33:59 <ViGe> Yeah, tags can definitely be added for sfos versions etc.
10:34:14 <schmittlauch[m]> ViGe: Is that forum supposed to replace the mailing list?
10:35:16 <Thaodan> if yes maybe use mailman3 which has forum web ui
10:35:19 <elfio> maybe you can organize a coding competition for the opening, just like old maemo ones
10:35:25 <Thaodan> (hyperkitty)
10:35:28 <ViGe> message from fridlmue:  My suggestions: This is a great Idea! I would like a Beginners Categorie, of course a General Help, But I would also like to see a category for how to use infrastructure (obs etc.), how to use the tool-chain and one category where "openSource"-Projects can present and ask for help.
10:35:52 <ViGe> schmittlauch[m]: Probably
10:36:31 <elfio> I would suggest not over dimension in advance. It will be clear when new subforums are needed
10:36:34 <Mister_Magister> ViGe: what about user's apps? like whole category for them and one topic for every app or smth like that could be useful
10:36:40 <schmittlauch[m]> Thaodan: Discourse has a mail interface as well
10:36:42 <KeeperoftheKeys> Bug reports - since we don't have access to the bug tracker and reporting bugs on TJC sadly seems to border on the useless (multiple EA 3.2.0.12 bugs were reported, yet 3.2.0.12 was released as is without even an acknowledgement from Jolla that these bugs were filed)
10:36:43 <Nico[m]> Will we be able to login with our jolla accounts?
10:36:50 <ViGe> elfio: That is also an excellent point
10:37:56 <ViGe> Nico[m]: That is the plan
10:38:11 <Nico[m]> Neat
10:38:16 <ExTechOp> Excellent.
10:38:57 <elfio> Wow! SFOS app would be very nice
10:39:08 <elfio> or public API
10:39:23 <Mister_Magister> oh yeah API to allow app creation would he hell of a yes
10:39:38 <elfio> What would happen to together jolla?
10:39:48 <elfio> ViGe: ^
10:40:02 <ViGe> discourse has API: https://docs.discourse.org/
10:40:05 <elfio> Also, maybe Nemo section? :)
10:40:24 <Nico[m]> Maybe a meta forum/topic would be good for discussing needed sections and anything regarding the orgainzation of the developer forum
10:40:36 <Jaymzz> ViGe: just FYI the time is up :)
10:40:37 <ViGe> elfio: That (the future of together.jolla.com) is probably something that we should have another discussion about later on
10:40:40 <Mister_Magister> ViGe: but the api key is needed so we are talking about some public api or at least giving some users key
10:40:53 <Thaodan> elfio:  please just Sailfish OS FOSS or something. The different naming hurts the ecosystem.
10:41:06 <elfio> :+1:
10:41:44 <ViGe> Jaymzz: Yeah, I think we got enough feedback already and we can move on :)
10:42:15 <ViGe> Thanks everyone, this really helps planning this thing!
10:43:17 <Jaymzz> Alright for the next topic I'll have to remove some minutes since a lot of topics went over time and we can't afford that :D
10:43:26 <Jaymzz> #topic general discussion (10 min)
10:43:29 <ViGe> If you still have more ideas, please send them to me via email: ville.nummela@jolla.com
10:43:38 <Kaffeine> Hi everyone. I'm sorry for extending the discussion, but I don't obligate you to answer right now. The only thing I need is to have some more attention for my two questions:
10:43:46 <Kaffeine> 1. Can we have more conventions about external (not MER own) projects packaging (especially about the repo layout) at https://sailfishos.org/wiki/Software_Packaging?
10:43:53 <Kaffeine> In some repos (e.g. libmediaart) we have `rpm` and `upstream` directories, the last one is a git submodule.
10:43:58 <Kaffeine> In others (e.g. maliit-framework) we have the two above and plus <package-name> directory with the unpacked upstream sources with messed-in patches.
10:43:59 <Nico[m]> Please keep us updated, ViGe :D
10:44:00 <Jaymzz> #info If you still have more ideas about the mentioned forum, please send them to me via email: ville.nummela@jolla.com
10:44:15 <ViGe> Nico[m]: will do! :)
10:44:16 <Kaffeine> Some projects (e.g. telepathy-qt) use git subtrees in different forms.
10:44:23 <schmittlauch[m]> jpetrell: Is the alt-tab gesture still being worked on? If yes, is it just lie priority or do you expect to fix the browser issue e.g. with Qt update?
10:44:25 <Kaffeine> Some packages, such as qtgraphicaleffects, demonstrate all the variety of approaches and has tarball+spec in the `master` branch, rpm + <package-name> directory with submodule in `mer-5.6` branch and just the upstream source code in `mer-5.9` branch.
10:44:33 <Kaffeine> As far as I understand, the modern approach is "rpm + <package-name> directory with submodule" (used e.g. in `extra-cmake-modules`, packaged a year ago).
10:44:42 <Kaffeine> I want you (Jolla) to approve and document it. Just a few lines will prevent devs from further disorder and let other developers help you to clean up the current packaging stuff.
10:45:12 <Kaffeine> I have also one wish/request, partially based on the first one:
10:45:29 <Kaffeine> 2. Please review my merge request for telepathy-qt: https://git.merproject.org/mer-core/telepathy-qt/merge_requests/5
10:45:33 <Jaymzz> from ApBBB: since is general discussion. i have a question. Firefox was "blocked" because of an old gcc version. this has been updated recently i think. what are the blockers now??
10:45:34 <Thaodan> Kaffeine:  they were some mer docs about this maybe they should be updated and extended.
10:45:39 <Kaffeine> The PR is build-proved by OBS. I converted the repo back from subtree to submodule (as it been a few versions ago). It became easier to manage MER changes with submodule, so I picked a few of them to the upstream TelepathyQt project and released v0.9.8 with a number of other fixes and enhancements.
10:46:00 <Kaffeine> Please consider to work with the upstream (me), I'm open for patches, questions, suggestions, bug reports and feature-requests. :)
10:46:04 <KeeperoftheKeys> Concerning my point earlier - with ifup/down there is an option of running scripts so having different firewallscripts associated with different wifi ssids may be an option though with a quick search I have not found a connman way to do this.
10:46:23 <Jaymzz> Kaffeine: I'm starting to wonder if it would be better to make this a topic for the next meeting
10:46:35 <Kaffeine> Just to let you know, I (still) work on Telegram and other clients for Telepathy. It is "a long hard road", you know :) I have a slow yet constant progress.
10:47:10 <Hummer12007> did jolla publish the statement on xperia x+ad future yet btw?
10:47:21 <Jaymzz> Hummer12007: not yet :)
10:47:25 <Jaymzz> but it's coming
10:47:33 <Hummer12007> no eta?
10:47:40 <dcaliste> Kaffeine, ping someone in gitlab as a commen, maybe your MR was not seen. Maybe pvuorela, he was the last commiter.
10:47:52 <ExTechOp> Kaffeine I'd really like to see that stuff, integration of different protocols into one framework has been a very nice feature of Sailfish and its predecessors
10:47:54 <Kaffeine> Jaymzz: I don't know if it needs a discussion; maybe you already decided to use "rpm + <package-name> directory with submodule" approach and there is nothing to discuss, only to document.
10:47:55 <Hummer12007> thanks for the info, thoug
10:47:58 <Nico[m]> Hummer12007: I wanted to ask that too :D
10:48:05 <Hummer12007> heh
10:48:05 <schmittlauch[m]> Kaffeine: but XMPP support isn't moving, right?
10:48:07 <KeeperoftheKeys> topic I will probably bring to next meeting is kernel updates - I understand it is hard but it cannot be that Jolla/SFOS profiles itself as secure etc. while leaving old usupported kernels on our devices (while newere versions exist)
10:48:18 <Jaymzz> Hummer12007: No proper eta but before the end of the year :)
10:48:39 <Jaymzz> Kaffeine: okay you decide on that then :)
10:49:06 <flypig> Kaffeine, I think it's worth making this a discussion. Even if you only get that answer, at least it will have been seen by the right people.
10:49:11 <schmittlauch[m]> Jaymzz: You once promised us a roadmap. It's ok if it has been cancelled, but then please communicate that fact.
10:49:12 <ExTechOp> Kaffeine Support for Hangouts as a separate module would be cool (hoc Jolla)
10:49:34 <KeeperoftheKeys> *Jolla 1 we probably have no choice, but Xperia X has new supported kernels
10:49:47 <Thaodan> KeeperoftheKeys: usally patches from Linux stable are applied, like it happens for the XA2(nile) and Xperia 10(ganges)
10:50:02 <Kaffeine> flypig, Jaymzz: you're right. I'll submit this (packaging repo layout) topic for the next meeting.
10:50:08 <Jaymzz> schmittlauch[m]: True, I did that, but since then a lot of difficulties came our way regarding that. I'm unsure if it's cancelled at this moment but I can surely take a look at the status.
10:50:11 <Thaodan> KeeperoftheKeys: not on the specific Android base
10:50:22 <KeeperoftheKeys> Xperia X runs 3.10 instead of 4.x or 5.x kernel, it is no longer supported and not being patched
10:50:26 <Jaymzz> Kaffeine: I think it's the right thing to do and get a proper discussion out of it
10:50:53 <Mister_Magister> KeeperoftheKeys: jolla patches kernel itself
10:50:57 <KeeperoftheKeys> and backporting kernel patches is probably waaaay beyond Jolla resources (understandably)
10:51:21 <Jaymzz> 2 min left on this one
10:52:03 <KeeperoftheKeys> So we need to hear constantly how there is no time for doing meaningful stuff because engineers are spending all their time on backporting to kernel 3.10 I find that hard to believe
10:52:07 <Kaffeine> schmittlauch[m]: Yep, and XMPP support is going to have some improvements.
10:52:47 <ExTechOp> Kaffeine looking forward to it!
10:53:03 <Thaodan> KeeperoftheKeys: Android is tied to the specific kernel version depending on the vendor.
10:53:23 <Thaodan> like 4.14 for Android 10
10:53:56 <Jaymzz> aaaand time is up. need to move on
10:54:08 <Jaymzz> #topic next meeting time and date (5 min)
10:54:14 <Kaffeine> ExTechOp: I'm sorry, I have no time to work on everything. I work on whole Telepathy stack + Jolla telepathy + KDE Telepathy + Telegram support + XMPP support + Matrix support... there is too many of everything to see real progress in reasonable time :-(.
10:54:39 <Kaffeine> I have a job and can work on telepathy only in some spare time. I would like to also try voice calls for Telegram :)
10:54:44 <Jaymzz> So the next meeting will be held a month from now as the bi-weekly agenda will clash with our next internal planning day
10:54:47 <Jaymzz> so..
10:54:47 <ExTechOp> Kaffeine Knowing what a horrible mess Hangouts really is, I'm not surprised.
10:54:51 <Jaymzz> #info Next meeting will be held on December 12th 2019 at 09:00 UTC
10:55:07 <Jaymzz> Everyone on board?
10:55:26 <KeeperoftheKeys> not bi-weekly?
10:55:36 <Mister_Magister> +1
10:55:38 <Jaymzz> KeeperoftheKeys: only next time
10:55:56 <Jaymzz> we have internal planning days coming up. Hence the next meeting is postponed.
10:56:06 <KeeperoftheKeys> ok
10:56:08 <Jaymzz> then we will be bakc to bi-weekly
10:56:14 <KeeperoftheKeys> just this was *very* long...
10:56:31 <schmittlauch[m]> Kaffeine: Good to see that telepathy isn't dead
10:56:38 <Jaymzz> KeeperoftheKeys: indeed. It took way longer than expected too. That's why I'm rushing it in the end
10:56:49 <Jaymzz> but let's see how we manage the next one
10:56:59 <Jaymzz> Thanks all for attending. This was very fruitful!
10:57:01 <Kaffeine> schmittlauch[m]: Yep, I named the new release "still moving" :D
10:57:08 <Jaymzz> ending :)
10:57:10 <Jaymzz> #endmeeting