[Devel] Preferences and Persistence design 0.3.0

[Philip Withnall]

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 at collabora.co.uk]
> Gesendet: Freitag, 8. Januar 2016 11:04
> An: Barkowski Andre (CM-CI1/PRM1) <Andre.Barkowski at de.bosch.com>; dev
> el at 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 at lists.apertis.org] Im Auftrag von
> > Philip Withnall
> > Gesendet: Freitag, 27. November 2015 13:05
> > An: devel at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 213 bytes
Desc: This is a digitally signed message part
URL: <http://lists.apertis.org/pipermail/devel/attachments/20160111/6307cb32/attachment.sig>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5445 bytes
Desc: not available
URL: <http://lists.apertis.org/pipermail/devel/attachments/20160111/6307cb32/attachment.bin>