[Architecture] [Ux] How should PCP handle adjusters which need a restart to be applied?

Alexander Milchev amilchev at asteasolutions.com
Tue Jun 24 10:07:11 EDT 2014

Hi everyone!

I'm asking this as an open question so that more people can share their
thoughts on this and we eventually reach to an appropriate solution.

Should PCP show adjusters that cannot be applied *live* to the system? *If
so, how should we handle them?*

Currently, as decided on a previous discussion on the same topic before the
pilots, PCP is only showing adjusters that *can* be applied live, e.g. you
turn the high contrast On and it you can see that being reflected on the
machine within seconds.

However, the adjusters PCP is showing should become (and have become up to
90% in this branch
<https://github.com/radmanovi4/prefsEditors/tree/gpii-543>) dynamic - PCP's
be created only after PCP has received which adjusters exactly to show (as
a parameter) from another component. In other words - GPII-543

Naturally, this makes it possible (and quite probable actually) that PCP is
urged to show adjusters that *cannot be applied live and need a restart*.
On Windows, these are all the solutions except for high contrast on/off
(notice, on/off, not contrast theme). On Fedora the live applicable
adjusters are quite more, but still not completely all of them.

I've created a JIRA for the issue - http://issues.gpii.net/browse/GPII-855,
we can write down any decisions made on this subject there.

By the way, has there been any improvement on the number of live applicable
adjusters (on either OS) since the pilots decision?

Waiting for your thoughts on this...


*Alexander Milchev*
*First Level Software Engineer*
*Astea Solutions AD*

*The information in this e-mail and any accompanying files is intended only 
for the recipients named above. This message may contain CONFIDENTIAL 
recipient, you may not download, copy, disseminate, distribute or use in 
any way the information in this e-mail. Any of these actions can be a 
criminal offense. If you have received this e-mail in error, please notify 
Astea Solutions AD immediately by reply e-mail, and delete this e-mail and 
any copies of it.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gpii.net/pipermail/architecture/attachments/20140624/8ab3e0f0/attachment.html>

More information about the Architecture mailing list