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
Hi Philip, thx for the Update and all the valuable background information added for the approaches in current solutions. 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). The remaining topic to concentrate on is - 5.1.5 user interfaces 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. - A user do not has to step into an app and to search for it to configure it, it’s at a central place. - 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) - 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. - An OEM can also change the look and feel of the Settings-App and it keeps consistent, no need to change the App - One can optionally re-organize / combine configurations of same kind over all Apps into one view (e.g. similar like "privacy" settings) - We can easily add Search capabilities (over all Apps), to help Users to find the topic of interest independent of their organization 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. Its all central, consistent, it focus on User (minimize distraction) and OEM (enable customization and scope definition). 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. 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. 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. 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. 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, 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. 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) And also - reflect the iOS User Interface approach for presenting the App settings Rgds Andre -----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
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@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
Hello Philip, 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? Best regards Suma L RBEI/ECF Tel. +91(80)6657-4464 -----Original Message----- From: Devel [mailto:devel-bounces@lists.apertis.org] On Behalf Of Philip Withnall Sent: Friday, January 08, 2016 3:34 PM To: Barkowski Andre (CM-CI1/PRM1) <Andre.Barkowski@de.bosch.com>; devel@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@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
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@lists.apertis.org] On Behalf Of Philip Withnall Sent: Friday, January 08, 2016 3:34 PM To: Barkowski Andre (CM-CI1/PRM1) <Andre.Barkowski@de.bosch.com>; dev el@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@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
Ok that's correct. Just that the program that implements the settings UI for services will be a part of the "variant". And the services itself will provide a GSettings schema file. If this is concluded, we would like to start working on it. Best regards Suma L RBEI/ECF Tel. +91(80)6657-4464 -----Original Message----- From: Philip Withnall [mailto:philip.withnall@collabora.co.uk] Sent: Friday, January 08, 2016 3:50 PM To: Suma Shanbhog (RBEI/ECF4) <Suma.L@in.bosch.com>; Barkowski Andre (CM-CI1/PRM1) <Andre.Barkowski@de.bosch.com>; devel@lists.apertis.org Subject: Re: [Devel] Preferences and Persistence design 0.3.0 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@lists.apertis.org] On Behalf Of Philip Withnall Sent: Friday, January 08, 2016 3:34 PM To: Barkowski Andre (CM-CI1/PRM1) <Andre.Barkowski@de.bosch.com>; dev el@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@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
I will wait for Andre’s thoughts on the new suggested design, then update the Preferences and Persistence design document accordingly. For the moment, it seems we are all agreed on using GSettings as the schema basis for settings, but perhaps are not agreed on the UI implementation yet. Philip On Fri, 2016-01-08 at 11:09 +0000, Suma Shanbhog (RBEI/ECF4) wrote:
Ok that's correct. Just that the program that implements the settings UI for services will be a part of the "variant". And the services itself will provide a GSettings schema file. If this is concluded, we would like to start working on it.
Best regards
Suma L RBEI/ECF
Tel. +91(80)6657-4464
-----Original Message----- From: Philip Withnall [mailto:philip.withnall@collabora.co.uk] Sent: Friday, January 08, 2016 3:50 PM To: Suma Shanbhog (RBEI/ECF4) <Suma.L@in.bosch.com>; Barkowski Andre (CM-CI1/PRM1) <Andre.Barkowski@de.bosch.com>; devel@lists.apertis.org Subject: Re: [Devel] Preferences and Persistence design 0.3.0
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@lists.apertis.org] On Behalf Of Philip Withnall Sent: Friday, January 08, 2016 3:34 PM To: Barkowski Andre (CM-CI1/PRM1) <Andre.Barkowski@de.bosch.com>; dev el@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@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
Hi Philip, please find my comments enclosed in green Rgds Andre -----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>; devel@lists.apertis.org Betreff: Re: AW: [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. Andre: ok.
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. Andre: ok. 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. 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. 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. 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. Andre: great. 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. Andre: see above, its not black or white as also the flexibility for App Developers is not the first/only priority in our business environment. 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. Andre: like said, I do not have an issue with realizing the settings based on code, the topic is the responsibility of code as also the differnent kind of flexibility. I would like to go for a solution, where the majority of flexibility / code is in the hands of the product team, which adopts it accordant to OEM interest, and the minority is in the hand of the App developer. In your sample above, its still too much responsibility in the scope of the App-developer. The "ApertisSettingsList" is not able to cover enough customization from my point of view, we would need more like a a setings applications, complety in the responsibility of the product team, providing an implementation of all the easy / standard stuff accordant to the OEM interest, and hook to Apps for special entities, which then gets limited customization capabilities based on widget customization.
- 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. Andre: ok
- 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. 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.
- 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. Andre: like said above, this is sufficient for the special cases but not enough flexibility for the general one.
- 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. Andre: see above
- 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. Andre: yes, GSettings is not an issue.
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.
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. Andre: yip, but it looks like the iOS approach is fitting better to our business needs.
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.
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. Andre: yes, thx for that. However, it doesn't convince me and I hope you see why in our OEM business flexibility for App Developers is not the only driving goal.
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@lists.apertis.org] Im Auftrag von Philip Withnall Gesendet: Freitag, 27. November 2015 13:05 An: devel@lists.apertis.org <mailto: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
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
Hi Philip, it sounds to me that your proposal is fitting to the "responsibility" split (OEM vs App developer), so from that perspective my answer to your question "Does that fit better with what you have in mind?" would be yes. But let me reflect from other perspectives, the packaging & deployment & control & seamless integration I prefer, that the "code" implementing the OEM-settings is deployed with the OS (essential software) outside of the App-package. With that, all code included in the App-package belongs to and gets provided by the App-Developer. Customization within Apps gets realized based on using prepared widgets / css scheming / etc, all in scope of the OS. With that oem-setting app belongs to the OS (essential software), and the App is only providing some data/model to it. But we do not have to adopt _all_ packages to replace the OEM specific settings implementation included in them.
From my point of view it looks like your proposal fulfills that (since there is an application "oem-settings", created and distributed with the essential software), are we on the same page ?
From "control" point of view, I would like to "enforce" the central solution, the using the exception only the complex parts. Launching the "oem-settings" application - instead of using some homegrown App internal solution w/o need - should _not_ be delegated to the App. It should be part of the system software (essential software) to launch it and to cover all common use-cases. Again, are we on the same page, its _not_ the App who decided/launches the oem-settings on the first hand (but the OEM settings App, who implements the umbrella) ?
In regard to seamless integration, the "uncommon cases" should be go down to a granularity of a single entry within the settings. So some common, one 1 or more uncommon, again 1 or more common and so forth. I would not like to have a black or white decision, either all are common or the get replaced completely by a proprietary implementation. This is why I referred to Wizards. Its one entry in the settings app, but instead of modifying its value within the App based on an easy standard type, a dedicated executable is used for it. However, finally its seamless included into one view. Again, I have the feeling your proposal fits to that, but like to be on the same page. If we are on the same page in regard to the 3 scopes mentioned above, I don't have any issue with the proposal. Hope you are also happy with the outcome. And thanks for your clarification that GSettings will not allow a setting to be changed if it is not writable. That’s good to know. Also the recommendation to check is as part of app store validation. I fear we will forget all this valuable hints for store validation, because at least I do not collect this hints in a structured way. Hope you are doing that in some way. Since from my point of view the topics mentioned above covers open areas from the mail below, I haven't embedded any further feedback into the mail below. Rgds Andre -----Ursprüngliche Nachricht----- Von: Philip Withnall [mailto:philip.withnall@collabora.co.uk] Gesendet: Montag, 11. Januar 2016 15:12 An: Barkowski Andre (CM-CI1/PRM1) <Andre.Barkowski@de.bosch.com>; devel@lists.apertis.org Betreff: Re: AW: AW: [Devel] Preferences and Persistence design 0.3.0 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
Hi Andre, On Mon, 2016-01-11 at 15:20 +0000, Barkowski Andre (CM-CI1/PRM1) wrote:
it sounds to me that your proposal is fitting to the "responsibility" split (OEM vs App developer), so from that perspective my answer to your question "Does that fit better with what you have in mind?" would be yes. But let me reflect from other perspectives, the packaging & deployment & control & seamless integration
OK.
I prefer, that the "code" implementing the OEM-settings is deployed with the OS (essential software) outside of the App-package. With that, all code included in the App-package belongs to and gets provided by the App-Developer. Customization within Apps gets realized based on using prepared widgets / css scheming / etc, all in scope of the OS. With that oem-setting app belongs to the OS (essential software), and the App is only providing some data/model to it. But we do not have to adopt _all_ packages to replace the OEM specific settings implementation included in them. From my point of view it looks like your proposal fulfills that (since there is an application "oem-settings", created and distributed with the essential software), are we on the same page ?
Yes, precisely.
From "control" point of view, I would like to "enforce" the central solution, the using the exception only the complex parts. Launching the "oem-settings" application - instead of using some homegrown App internal solution w/o need - should _not_ be delegated to the App. It should be part of the system software (essential software) to launch it and to cover all common use-cases. Again, are we on the same page, its _not_ the App who decided/launches the oem-settings on the first hand (but the OEM settings App, who implements the umbrella) ?
Yes, we agree here too. In my suggestion, the settings UI for each application is launched by the system settings application, which is written by the OEM. The executable which provides the settings UI for an application is specified in the application’s manifest, which is also under the control of the OEM.
In regard to seamless integration, the "uncommon cases" should be go down to a granularity of a single entry within the settings. So some common, one 1 or more uncommon, again 1 or more common and so forth. I would not like to have a black or white decision, either all are common or the get replaced completely by a proprietary implementation. This is why I referred to Wizards. Its one entry in the settings app, but instead of modifying its value within the App based on an easy standard type, a dedicated executable is used for it. However, finally its seamless included into one view. Again, I have the feeling your proposal fits to that, but like to be on the same page.
I don’t think we are on the same page here. In my most recent proposal, an application’s settings UI is either entirely provided by oem- settings, or entirely provided by the application developer. If it’s implemented by the application developer, they can use ApertisSettingsList (for example) to ensure a look and feel which is consistent with oem-settings. However, they could choose to use something else. The problem with providing a ‘mixed’ solution – where oem-settings displays the simple settings for an application, and some code provided by the application developer displays the one or two more complex settings – is that of privilege separation. oem-settings necessarily has permissions to write to all GSettings keys for all applications — it is part of the trusted computing base (TCB) for settings management. If code provided by application developers is allowed to run within oem-settings, it also gains those privileges, which violates the security policy we want for settings. Therefore code from the application developer would have to run in a separate process and have its UI embedded into oem-settings. I provided a couple of options for how to implement this in the most recent version of the document (‘Alternative model 1’ in §5.1.5 of version 0.3.0 of the document). It’s possible, but is a very complex solution for a rare situation. Application developers would have to cooperate in implementing it, as the application-provided settings program would have to be a client in a client–server protocol for embedding the UI. This means that there would need to be app store validation of how they implemented the protocol, plus testing. What I suggest is to go with the black and white solution – not implement embedding – and instead make it easy for application developers to use ApertisSettingsList (and other widgets which replicate the look and feel of oem-settings) in their application settings UIs. Subject these applications to app store validation checks (which I suspect would end up being no more complex than the alternative of validating an application’s settings UI can be embedded).
If we are on the same page in regard to the 3 scopes mentioned above, I don't have any issue with the proposal. Hope you are also happy with the outcome.
I’ll start updating the design document once we’ve discussed the topic above.
And thanks for your clarification that GSettings will not allow a setting to be changed if it is not writable. That’s good to know. Also the recommendation to check is as part of app store validation. I fear we will forget all this valuable hints for store validation, because at least I do not collect this hints in a structured way. Hope you are doing that in some way.
The design documents which Simon and I have worked on recently all have any relevant app store validation checks listed in them. We have a task open for collating these and adding any additional checks we can think of (for older design documents). Philip
-----Ursprüngliche Nachricht----- Von: Philip Withnall [mailto:philip.withnall@collabora.co.uk] Gesendet: Montag, 11. Januar 2016 15:12 An: Barkowski Andre (CM-CI1/PRM1) <Andre.Barkowski@de.bosch.com>; dev el@lists.apertis.org Betreff: Re: AW: AW: [Devel] Preferences and Persistence design 0.3.0
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
participants (3)
-
Barkowski Andre (CM-CI1/PRM1) -
Philip Withnall -
Suma Shanbhog (RBEI/ECF4)