**** BEGIN LOGGING AT Sun Sep 24 03:00:01 2017 Sep 24 06:49:30 Morning! Sep 24 06:49:39 Herrie: https://github.com/shr-distribution/meta-smartphone/pull/33 updated, now my work is done :) Sep 24 07:54:09 Tofe: thnx, now just need to wait for JaMa. Sep 24 08:07:35 I got the changelog ready for 90% as well. Will finish it today and write up some release announcement as well Sep 24 08:16:53 ok great :) Sep 24 09:24:12 Herrie|Pre3: we'll need to have a little design discussion about the Settings app, before we start coding something Sep 24 09:26:11 I'm thinking about: how much modularity, what kind of general UI for the various sections, should be integrate more stuff in it (tweaks ? app settings ?), what about integration in JustType... Sep 24 10:44:21 Tofe: Agree Sep 24 10:44:42 You thinking about integrating Tweaks into the app? Sep 24 10:45:30 JustType sounds like a good idea. Very webOS-y to add them there. I.e. you search for Sound, Wifi, Bluetooh, Certificates and it would open the Settings for these. Sep 24 10:54:30 Actually 2.x and 3.x already do that Sep 24 10:54:51 Because they had separate apps for each Setting Sep 24 10:55:22 So when you would search for Sound or Wi-Fi it would find and open those apps Sep 24 10:55:36 We might want to introduce that somehow Sep 24 10:57:56 They don't need to be standalone apps per se, but we could do something as described in the issue tracker. Let me find the link Sep 24 10:58:41 I.e. have multiple appinfo.json files for each "Settings"-page. So 1 for Sound, 1 for Wifi with each their own icon Sep 24 10:59:12 And display these based on a Tweak value. I.e. 1 Settings app or multiple icons Sep 24 11:03:32 I.e. our current situation with a single icon or legacy with multiple. Most stuff for this already exists is Just Type and we have flags in appinfo.json to show icon or not for example. Sep 24 11:03:49 Changing Tweaks value would need to adjust this value Sep 24 11:08:33 It would still require some tweaking here and there to get this working but shouldn't be an awful lot I'd guess Sep 24 12:40:08 Morning! Sep 24 12:41:20 Herrie : I could not find anything in issue tracker related to "They don't need to be standalone apps per se, but we could do something as described in the issue tracker." Sep 24 13:03:53 MartinHov: Should be 1183-ish Sep 24 13:10:57 Herrie: thanks. I like the idea of having setting components (one per each area) and have the ability to combine them in one setting app. Sep 24 13:11:52 perhaps we would need two levels of settings: regular settings and advanced (Expert) settings - where later are in Tweaks today. Sep 24 13:14:02 each app could extend it's own setting menu with the system setting components that are relevant for the app. E.g. the audioplayer would reuse the audio setting component. Sep 24 13:30:31 MartinHov: thinking about the same lines, not a big fan of cluttered Settings like in Android Sep 24 13:31:56 ok, well, glad to read all this ) Sep 24 13:31:57 :) Sep 24 13:32:27 seems like xfce-alike settings have a good approval rate Sep 24 13:33:23 (in xfce, in the main menu, you can access all the settings categories directly, like if it was an app; but what you open is actually the settings app, already set to the chosen category) Sep 24 13:48:28 Not familiar with xfce will check later Sep 24 13:51:24 Herrie|Pre3: it's pretty much what you described above Sep 24 13:51:48 one icon per category, that one can launch directly Sep 24 13:52:12 but in the end, it's just a shortcut, there is only one settings app Sep 24 13:52:47 I quite like this approach, it fits everyone Sep 24 13:56:01 I can begin with switching the current little shell app into a little QtQuickControl2 shell Sep 24 13:57:21 It's just to prepare the field, because our design choices will have a big impact on the overall architecture of that app Sep 24 14:00:24 Herrie: do I have write rights on the settings repo ? how do I know ? Sep 24 14:17:52 Tofe: Create a new branch in repo? Sep 24 14:20:02 ok, I've got edit rights :) Sep 24 14:24:40 OK :) Sep 24 14:39:11 Ok let's go https://github.com/webOS-ports/org.webosports.app.settings/pull/82 Sep 24 14:40:07 As-is there is no modularity, and the UI mockup still need to be decided Sep 24 14:42:12 In addition, I hesitate to use luna-qml-launcher as a starter, instead of having a dedicated executable Sep 24 14:44:26 Tofe: You mean something like this for xfce: https://smdavis.us/2016/11/09/xfce-settings-4-13-0-released/ ? Sep 24 14:45:00 well, yes and no: I doubt this is adapted to a mobile UI Sep 24 14:45:12 Tofe: Why not use luna-qml-launcher? Sep 24 14:45:30 but you can start the "Appearance" setting directly from the main start menu Sep 24 14:45:42 Adding code there should be easier compared to duplicating & adjusting? Sep 24 14:45:49 oh, it's just that the C++ code for the standalone app is already there :p Sep 24 14:46:20 Ah ok.... Sep 24 14:46:52 Herrie|TP: there would be near to nothing to modify in luna-qml-launcher. We already proved that it works with the browser app. Sep 24 14:47:03 Well anyway we'd need to tweak somethings here and there.... I.e. have org.webosports.app.soundsettings launch org.webosports.app.settings for example Sep 24 14:47:31 That could be done by launchparams or some flag in appinfo.json I guess Sep 24 14:47:55 Herrie|TP: why the need for a flag ? Sep 24 14:48:09 Or something similar... Sep 24 14:48:24 I mean, with the current appinfo, it's already possible, isn't it? Sep 24 14:48:38 Tofe: I think you cannot have multiple icons in the launcher with same appid Sep 24 14:49:04 So we'd need to work around that Sep 24 14:49:45 Just changing the "id" in appinfo isn't enough? Sep 24 14:50:32 It would not reflect the appid of what it starts, but I guess it's not a big issue Sep 24 14:50:32 Or we could suffix somehow to make them unique. I.e. org.webosport.app.settings.wifi, org.webosports.app.settings.sound etc Sep 24 14:51:05 Tofe: Not a big issue but should be modified/developed Sep 24 14:51:18 Currently that bit doesn't work Sep 24 14:51:52 Herrie|TP: so currently "id" must match the appId of the launched app ? Sep 24 14:53:10 ah, yes, if we want to re-focus it using its icon, it has to be able to find it Sep 24 14:54:20 I like the suffix idea Sep 24 14:58:38 not sure i understand proposed idea: if user tap wifi app icon, and then e.g. bluetooth app icon, what would happen? two cards: wifi and bluetooth apps? Sep 24 15:00:39 For me it was still one app Sep 24 15:00:46 Tofe: field appToLaunch in appinfo.json could work too Sep 24 15:00:48 just possibility to have icons as shortcuts Sep 24 15:01:00 There are multiple ways anyway Sep 24 15:01:16 Herrie|TP: one more field I didn't know about :p Sep 24 15:02:13 nizovn: do you think there are user scenario were multiple setting cards are useful ? Sep 24 15:02:33 I rarely need to modify in parallel two settings Sep 24 15:03:21 Though if we want to support multiple cards, we could, that has also been done with browser Sep 24 15:03:43 not sure it would help much though Sep 24 15:05:58 in my opinion it's intuitive that icon launches a new card, and doesn't modify already opened.. Sep 24 15:08:26 nizovn: but then it would be separate apps ? to overall settings ? Sep 24 15:09:07 s/to/no/ Sep 24 15:10:00 Tofe: i don't see how to integrate both ways, i think it could be separate apps or one Sep 24 15:11:53 I think I prefer having one app Sep 24 15:13:19 And technically it doesn't really close the door for the other approach, if we realize the other one is better. Sep 24 15:14:20 i prefer multiple apps myself, but as i most probably won't be the coding person, i'm not strictly against :) Sep 24 15:14:41 but just type integration probably requires separate apps Sep 24 15:15:06 ah yes, good point Sep 24 15:17:24 nizovn: in that case, I vote for an app which is able to become any category that it has been launched as Sep 24 15:18:40 our settings app will then just be a shell for the selected category, and will be launched once per different icon Sep 24 15:19:22 I can code a sort of "super" setting app that allows loading any category, for testing purpose Sep 24 15:20:51 nizovn: from a coding perspective, it'll be quite similar anyway, as we want to have a modular and well structured code Sep 24 15:27:56 Tofe: ok, if i understand correctly, it would be a card for every category icon, and a "manager" app where category can be chosen? Sep 24 15:29:24 nizovn: in my latest thoughts, there would be an app instance for each category, and the "manager" app would just be for testing on desktop Sep 24 15:30:19 nizovn: let me detail a bit what I have in mind Sep 24 15:30:47 Tofe: ok Sep 24 15:31:03 let's say we have a basic QML frame, which does only load a given sub-qml file Sep 24 15:31:21 that sub-qml file for be here a category UI Sep 24 15:31:52 and for each appinfo, it would launch luna-qml-launcher, with the QML frame, and a parameter saying which category we want Sep 24 15:33:19 For testing, we can have another main QML file, which has a list of category, and is able to show the QML frame with the category we want Sep 24 15:34:15 that way we keep the settings code centralized, generic, easy to test for the various categories, and we have one app per icon Sep 24 15:35:19 (plus, the testing app could become a real app if we want to switch for a more centralized unique settings app) Sep 24 15:36:11 Tofe: this sounds good Sep 24 15:36:28 Herrie: ^ how does that look for you ? Sep 24 15:56:34 Tofe: Sounds similar to our current app where we have 1 js per panel basically :P Sep 24 15:56:48 But I like the separate launcher icons more personally Sep 24 15:56:55 + they work in Just Type :) Sep 24 15:58:10 Ok, let's do that then Sep 24 15:58:46 I'll begin with a technical mockup (the QML loader, plus the testing one), and then we'll fill in Sep 24 15:59:10 It also means we have to drop the C++ code and definitely switch to our qml-launcher Sep 24 16:01:58 I'm in favor of less c++ :p **** ENDING LOGGING AT Mon Sep 25 03:00:00 2017