[Devel] Preferences and Persistence design 0.3.0

[Philip Withnall]

Hi Suma,

On Fri, 2016-01-08 at 10:13 +0000, Suma Shanbhog (RBEI/ECF4) wrote:
> I need clarity ont his topic:
> " So instead I propose a new solution (which is not in the current
> version of the design): write preference UIs in code, but Apertis
> should provide a widget which can auto-generate the UI for a specific
> set of preferences from the GSettings schema for the application.
> Let’s
> call the widget ApertisSettingsList.
> 
> This means that version 1 of the application above would implement
> its
> preferences UI in a small amount of code to instantiate
> the ApertisSettingsList widget for its two boolean preferences.
> Version
> 2 would keep this widget, and add additional widgets to the UI for
> the
> new, complex, preferences."
> 
> Suma Shanbhog : For an app maybe this is possible. However what about
> services which have settings? Consider Newport which might have a
> setting for download location. Newport is not aware of any UI . In
> microecore, it may not be built with lightwood or any such UI
> library.
> So, where can it find ApertisSettingsList?

This is unchanged from the current design, as far as I am aware.
Either:
 • Newport provides a small UI (as a separate program from its daemon
program) which implements its preferences UI; or
 • the system preferences application hard-codes a UI for download
preferences.

i.e. There has to be a program //somewhere// which implements a
preferences UI for Newport. Either it’s a separate program in the
Newport git repository, or is part of the system preferences program,
or the code is placed somewhere else. It doesn’t have to be part of the
Newport daemon process though.

Philip

> -----Original Message-----
> From: Devel [mailto:devel-bounces at lists.apertis.org] On Behalf Of
> Philip Withnall
> Sent: Friday, January 08, 2016 3:34 PM
> To: Barkowski Andre (CM-CI1/PRM1) <Andre.Barkowski at de.bosch.com>; dev
> el at lists.apertis.org
> Subject: Re: [Devel] Preferences and Persistence design 0.3.0
> 
> Hi Andre,
> 
> Sorry for my delayed response. Instead of diving straight into
> updating
> the document, I feel this topic (§5.1.5, user interfaces) needs a
> little more discussion. I think we are broadly on the same page,
> although your e-mail has introduced a couple more use cases which the
> design currently doesn’t cover. I will try to explain below.
> 
> In various places below I have said that the design covers a
> particular
> point. On re-reading the design when writing this e-mail, I realise
> there are places where it could be restructured to be clearer. I will
> try to do that.
> 
> On Mon, 2015-11-30 at 16:18 +0000, Barkowski Andre (CM-CI1/PRM1)
> wrote:
> > Enclosed my feedback. 
> > - secrets & passwords ==> move to security paper
> > Its ok for me to move this scope to the security paper, with that
> > we
> > can also add more context to it like discussed in another thread.
> > (see enclosed email).
> > But please do not forget a reflection of rollback and its impact
> > the
> > "user secrets and password" approach and where to add this
> > reflection
> > (this paper - e.g in chapter 5 approach - or the security paper -
> > which I feel would may fit better). 
> 
> OK, I will expand the section on this in the Security design. I will
> leave the current section in the Preferences and Persistence design
> as
> a pointer to the Security design.
> 
> > I have the feeling we are not on the same page so far. To make it
> > easier to understand, let's call it "an iOS like" solution. There
> > is
> > a settings App, bundled with the system like an App-Launcher
> > Application - providing the preferences to the User. An App carries
> > stuff to be configured in some way, e.g. a manifest, this gets
> > interpreted by some "Settings App" and shown to the User in a
> > consistent way. 
> 
> This is actually quite similar to what we have so far in the design:
> a
> GSettings schema (‘manifest file’) which specifies all the
> preferences
> for a given application. The design assumes some central preferences
> application, like iOS, which has sub-pages for each application.
> 
> 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.
> 
> 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.
> 
> 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. The amount of code needed does not
> need
> to be large at all: there are various GSettings convenience APIs
> which
> mean binding a particular setting to a particular widget is typically
> 1
> line of code.
> 
> I think the main attraction of creating preference UIs using code,
> rather than auto-generating them is that it provides a simple
> progression path: if version 1 of an application has a couple of
> boolean preferences, it makes sense to auto-generate the preferences
> UI
> for them. However, if version 2 adds some more complex preferences
> which cannot have their UI auto-generated, the application developer
> has to reimplement the entire preferences UI in code, including the
> old
> preferences.
> 
> So instead I propose a new solution (which is not in the current
> version of the design): write preference UIs in code, but Apertis
> should provide a widget which can auto-generate the UI for a specific
> set of preferences from the GSettings schema for the application.
> Let’s
> call the widget ApertisSettingsList.
> 
> This means that version 1 of the application above would implement
> its
> preferences UI in a small amount of code to instantiate
> the ApertisSettingsList widget for its two boolean preferences.
> Version
> 2 would keep this widget, and add additional widgets to the UI for
> the
> new, complex, preferences.
> 
> Wizards could be implemented as a similar progression.
> 
> > - A user do not has to step into an app and to search for it to
> > configure it, it’s at a central place. 
> 
> This is already handled in the design.
> 
> > - We also do not have to coordinate all the different kinds of
> > possibilities to incorporate it within Apps (at different places
> > and
> > in different way) 
> 
> The design already covers this by specifying a standard way for an
> application to be launched so that it shows its preferences
> immediately
> (§5.1.5¶2; ActivateAction).
> 
> > - 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.
> 
> > - An OEM can also change the look and feel of the Settings-App and
> > it
> > keeps consistent, no need to change the App
> 
> This can be handled by applying CSS classes to the preferences
> windows
> in applications, which allows the OEM to override the CSS for that
> class and have the changes be applied to all preferences windows
> without needing to modify applications. This is something covered by
> the UI Customisation design. I will mention that in this document
> too.
> 
> > - One can optionally re-organize / combine  configurations of same
> > kind over all Apps into one view (e.g. similar like "privacy"
> > settings)
> 
> This should be possible for the simple preferences supported by
> ApertisSettingsList by creating a new view which instructs that
> widget
> to display the desired preferences from //several// GSettings
> schemas.
> 
> Note that it would not be possible for preferences whose UIs cannot
> be
> auto-generated.
> 
> > - We can easily add Search capabilities (over all Apps), to help
> > Users to find the topic of interest independent of their
> > organization 
> 
> This can be implemented by searching the summaries and descriptions
> of
> installed GSettings schemas.
> 
> > 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.
> 
> > But to be honest, settings configured by the central Settings App
> > are
> > not covering all App internals. There are settings changed
> > dynamically during usage, e.g. Sat-View/Hybrid-View/Standard-View
> > in
> > a Map, routing parameter like fast/short/eco etc or even stored
> > Favorites. This will be done App-internally, and typically spread
> > over the App-UI to be at the place where it is needed (instead of
> > collected and presented all together at a single place). These App
> > internals are managed by the App itself. Also for this the prepared
> > (preferences & setting) services can be used by the App-developer,
> > and we provide prepared basic widgets, to keep the UI consistent
> > and
> > to customize it easily (and we should have some words about it in
> > the
> > document) but when I say we have to have a central App for the App
> > settings, then I am talking about the "static" ones. 
> 
> Indeed, the design recommends that preferences are integrated into
> the
> application UI where appropriate. This is definitely a use case we
> want
> to support.
> 
> > For that we use some basic data structures like "bool", "int",
> > "string" etc and provide widgets as visual representation of it.
> > Lets
> > compare it with the iOS way.
> 
> Since I haven’t mentioned it so far, both the iOS approach and the
> Android approach are relevant here (and I will include them in the
> document as background research):
> 
> iOS uses settings bundles, which are lists of preferences from which
> a
> UI is auto-generated. They support very simple data types, and can be
> loaded by the application or by a central preferences application.
> 
> Android uses preferences fragments, which are implemented in code as
> part of the application, and are launched by the preferences UI when
> needed, using a special launch argument to get the application to
> display that fragment (or present it as a separate Settings
> Activity).
> 
> Both approaches result in roughly the same user experience.
> 
> So as it stands, our design is aligned more with the Android approach
> than the iOS approach.
> 
> > 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.
> 
> > Once we do have both mechanisms - the wizard together with the
> > standard key/value types - , we have a great tradeoff between the
> > 80%
> > of easy to use Standard stuff and the 20% complex parts not fitting
> > well into the standard patterns. And being well prepared to handle
> > it
> > in a central App, we can easily cover a look & feel where it
> > behaves
> > like bundled to each App (for example a dedicated "Settings Hard
> > Key", which shall show only the Settings of the App (in Foreground
> > at
> > the point in time of key press), by initiating a flip Animation and
> > showing the App-Settings at the Back-Side of the current App
> > Screen.
> > That said, from a solution for central handling we can derive a
> > decentralized setup, but not as easy vice versa. So lets go for the
> > one covering the wider scope.
> 
> I will add the settings hard key to the document as a requirement and
> figure out how to integrate it into the design.
> 
> > However, even if we support the central solution, an App developer
> > may decide not to use it. In this case, App settings - which still
> > exists but not exposed centrally - are somehow internally handled,
> > in
> > an app-specific way. Its not consistent, etc, but its possible. And
> > we shall support this too. Its like different levels of
> > integration,
> > similar like with the different level of prepared UI elements (from
> > basic widgets via container to complete views/templates) - we
> > recommend the deepest integration but if the App developer decides
> > not to use it he can go for it but then he has to take the burden
> > for
> > build in functionality. So for "settings", we may expose a
> > "settings
> > key pressed" signal to the App for the case it does not participate
> > on the central handling. Or the OEM customization in look&feel but
> > also in scope. Or the "search settings" functionality. An App
> > Developer can even decide not to use our low level services to
> > handle
> > key-value pairs and uses its own. In this case, he has to take care
> > about under voltage etc, 
> 
> OK.
> 
> > With that in mind, I do have the feeling that the explanations on
> > page 26, like 
> > - disadvantages
> > - ways to embed UI from an application (A) into the system
> > preferences app (B)
> > are not perfectly fitting.
> 
> Hopefully this e-mail has managed to clarify my reasoning behind page
> 26 a little more. At the moment I am leaning towards recommending
> ‘alternative model 2’ as the default recommendation. 
> 
> > Could you please reflect the things said above
> > - different kind of App settings (which ones are in-app handled,
> > which ones are central)
> > - going for the widest scope solution (central handling,
> > incorporation of wizards)
> > - flexibility in tailoring for a specific product (customization,
> > de-
> > centralized setup)
> 
> I will ensure those are covered in the next iteration of the
> document,
> but would appreciate your thoughts on my explanations above first, to
> make sure we’re on the same page.
> 
> > And also 
> > - reflect the iOS User Interface approach for presenting the App
> > settings
> 
> Will do (and the Android one).
> 
> 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/20160108/091221d2/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/20160108/091221d2/attachment.bin>