Hi Andre,
On Fri, 2016-01-08 at 16:40 +0000, Barkowski Andre (CM-CI1/PRM1) wrote:
-----Ursprüngliche Nachricht----- Von: Philip Withnall [mailto:philip.withnall@collabora.co.uk] Gesendet: Freitag, 8. Januar 2016 11:04 An: Barkowski Andre (CM-CI1/PRM1) Andre.Barkowski@de.bosch.com; dev el@lists.apertis.org Betreff: Re: AW: [Devel] Preferences and Persistence design 0.3.0 The design currently gives a couple of options for how those sub- pages are implemented, but the differences are technical rather than user- facing. In all cases, the intention is that the preferences application lists applications, the user selects one, and all the preferences for that application are displayed. Andre: the difference is responsibility & deployment. The settings App belongs to the system chrome, gets defined by the OEM and we expect to write (by us) one new implementation per product. But we keep the Apps out of that scope. They are not ruling how it looks like (by providing the UI implementation aka look & feel), they are only defining the data. In a model/view/control pattern, their focus is limited to the model. However, no general rule w/o exception, we would like to keep the flexibility for special topics/data, which may need some more complex interaction to gets defined. But this doesn't change the overall approach, it only extends it. This would mean for very special entities (a very small quantity and with that an exception and not the rule of thumb), Apps can provide a UI which gets used to modify a value (e.g. like a wizard). For this part we again think about how to customize it to the maximum degree, but we accept limits.
I see. I think we could handle this using much of the same code as suggested in my previous e-mail (i.e. the ApertisSettingsList widget), but have that code written by the OEM as an application which takes the name of a GSettings schema as a parameter, and automatically generates and displays a UI for all the settings in that schema. For clarity, let’s call it oem-settings.
Each application’s manifest could contain a key which gives the name of an executable to run to display that application’s settings. For the common cases, that would be: oem-settings com.appauthor.MyApp i.e. it would run the OEM’s settings application to generate a settings UI for the application (com.appauthor.MyApp).
For the uncommon cases, where the application needs a particularly complex settings UI, the manifest key would be set to a settings program provided by the application developer. This could use a combination of ApertisSettingsList and custom widgets, as suggested in my previous e-mail, to build whatever UI the developer needs. It could also launch the application itself, with a special argument to show the settings dialogue, if that’s how the developer has implemented their settings.
In these uncommon cases, the OEM will be able to control the appearance of the application’s settings dialogue to a certain extent by setting the CSS of ApertisSettingsList. However, as you say (lower down in your e-mail, I think), the OEM won’t be able to control everything. I don’t think there is a way to reconcile this other than through app store validation of the code for the settings UI. If the application developer is allowed to execute //any// code in order to build the settings UI, they can (if they try hard enough) flaunt the OEM’s desired look and feel.
For all cases, the system settings application would initially present a list of all applications which have this key set in their manifest — I guess as an icon against the application name, as in iOS. When the user selects an application, the settings executable given in the manifest would be executed — whether that be the oem-settings application, or something provided by the application developer.
Does that fit better with what you have in mind?
Where the design currently differs from this is that it advises //against// automatically generating the preferences UI from the GSettings schema file. This is advice borne out of the experiences of various of us, who have seen and worked with auto-generated preferences UIs. They are almost universally not a pleasure to use, unless they list a very small number of very simple preferences (on the order of a couple of checkboxes, for example). You can think of this as a model–view–controller split: in all such patterns, it is rarely possible to satisfactorily generate the view from the model. Andre: yes, I see, but I don't share this recommendation against it. Its not black or white, the majority is very simple and on top we provide flexibility for the exceptions and last but not least we have the need for OEM customization.
I see.
Instead, it advises creating preferences UIs using code. This allows for ultimate flexibility in how the UI works, which can make for a much more pleasant user experience. Andre: again, I see but don't share it because it does not fit to our business model. Which user experience is pleasant decides the OEM, even if we find it very disappointing. With that we are talking about different kind of "flexibility". Since the majority of preferences is quite easy, the "flexibility for Apps" is only important for some special entities, but since we adopt the look&feel of each and every product accordant to the OEM interest, we do need "flexibility for OEM". And therefore we restrict flexibility for Apps. However, for parts with very good reasons, we will provide it, but not as a rule of thumb. And implementing it using code is not the issue what I am talking about, the responsibility is the topic. The system chrome application providing the UI for the App settings (which has been created based on code) will be done by the product team, not the App Developer. With that we keep the maximum level of flexibility for the settings app (belonging to the system chrome) in our own hands (i.e. the product team, out of the App Developer hands) And like said a new implementation will be done for each new product. Its the same for the App-Launcher, the status bar / Home screen, etc.. But its not based on code to provide flexibility for the configuration, its based on code to provide flexibility for the OEM, even for the standard / easy stuff. The complex, very App specific stuff can not realized outside the scope of the App responsibility, so we keep this in their hands with limitations in customization (even though we push also the limits as much as possible to enable customization for that part to a maximum degree) However, the approach which I explain is not going for one way without enabling the other one. So we have to enable both, minimize the part which is in the hands of the App Dev and maximize the part which is out of their scope.
OK. Thank you for the clear explanation.
- An OEM can decide to remove configurable parts in his product, so
that only a subset gets published to the user for a specific
device. This is already handled by the vendor lockdown system supported by GSettings. Applications can check whether a preference is locked down by calling the g_settings_is_writable() method. I will mention that in the document. Andre: "can" check is not sufficient. We need to deliver the product w/o contacting the App-developer to adopt this part. Again, it’s a matter of responsibilities. So the code is in responsibility of the product team to the maximum degree. For the remaining stuff we try to push the limits as much as possible, so "can" would be ok for that.
I should clarify here: GSettings will not allow a setting to be changed if it is not writable. If a vendor has used the vendor lockdown system to fix the value of a specific key, that key will no longer be writable. An application should use g_settings_is_writable() to check whether to display that key in the UI; but even if it fails to check that, any edits it makes to the key will fail.
Any Apertis-provided widgets like ApertisSettingsList would check g_settings_is_writable(), so this is only relevant to the minority of application developers who are writing their own settings UIs, and it could be something which is checked as part of app store validation.
Often there are "configurations" which modifies the App behavior
but
used by the system-integrator at point in time of product creation. By intention, they are not transported to the Used for
configuration.
It limits the capability of the User, but also reduces complexity. Its maybe used for variant handling. However, it is highly OEM specific, since another OEM my decide differently which
configuration
capabilities to provide to the User.
This is already handled by the combination of vendor lockdown and vendor overrides, as provided by GSettings. Andre: I am not talking about the GSettings capabilities, I am talking about the code responsibility for the presentation, and who will change what in case an OEM adoption is running into issues. The Settings App / UI shall be in the responsibility of the product team to the maximum degree and interact with the OEM for adoption, but not with each and every App developer to check if its Code has issues with the new presentation solution.
As above.
In addition, there could be a sequence needed to ease the input of values, e.g. a wizard (e.g. to configure an email account). This should be provided by the App-Developer. An isolated executable (Agent), using some PopUp-Sequence and finally set the key-value pairs shown in the settings App. With that, the Wizard gets shipped with the App, but launched by the Settings Apps.
The wizard, as you describe it, is effectively what we have in mind for all preferences UIs — you could think of them as similar to one-page wizards. Andre: yes, but only for very special cases, not as the general approach.
Agreed.
Philip
-----Ursprüngliche Nachricht----- Von: Devel [mailto:devel-bounces@lists.apertis.org] Im Auftrag von Philip Withnall Gesendet: Freitag, 27. November 2015 13:05 An: devel@lists.apertis.org Betreff: [Devel] Preferences and Persistence design 0.3.0
Hi all,
Please find attached version 0.3.0 of the Preferences and
Persistence
design, plus a document showing the changes between version 0.2.3
and
0.3.0.
This version includes more background research, some alternative designs for the system preferences application (§5.1.5) and clarifications of recommendations for storing secrets and
passwords.
Is this one OK to upload to the wiki?
Philip