[Architecture] NVDA on master
steve at opendirective.com
Wed Jan 14 14:47:08 EST 2015
OK. My concerns is we do not too tightly couple to the solutions. For
example, when a solution is updated to have new settings all should
continue to work before the GPII has chance to catch up (assuming all
known settings are unchanged of course). Of course this is quite a
problem in itself, especially if the GPII specifies the version of
solution it expects.
On 13 January 2015 at 19:35, Antranig Basman
<antranig.basman at colorado.edu> wrote:
> It doesn't necessarily have to "know" them, but it certainly has to "know
> how to ignore" them if they are not of interest to personalization, or if
> there is some reason that they may change spontaneously for reasons outside
> the control of (and not of interest to) the architecture. If there are
> settings of these kinds, we will need to put in filters in the "get" part of
> our settings handlers for the different solutions to discard them.
> On 13/01/2015 19:32, Steve Lee wrote:
>> Maavis also adds settings in some circumstances.
>> Are you saying in the new architecture that the GPII has to know all
>> settings? Not just those that may be of
>> interest for personalisation?
>> Steve Lee
>> Sent from my mobile device Please excuse typing errors
>> On 13 Jan 2015 19:24, "Antranig Basman" <antranig.basman at colorado.edu
>> <mailto:antranig.basman at colorado.edu>>
>> On 13/01/2015 02:43, Steven Githens wrote:
>> Hi all,
>> I’m trying to get NVDA to launch on github master (on Windows8),
>> and am getting this error about
>> not settling':
>> Any ideas what the issue might be?
>> Also, in the preferences, I had to rename it from
>> nvda.screenReader to org.nvda-project.
>> The architecture was improved last month to verify that the settings
>> that we write are the ones that the
>> application ends up storing. It appears that somehow an extra element
>> named "update" is introduced into
>> the INI file, presumably by the application itself. You might try to
>> study the INI file to see if you
>> can discover when/how this element gets into it - I can only imagine
>> that on discovering that the
>> contents have changed, that the application rewrites it by itself.
>> If/once we understand the issue, we should fix our settings handler so
>> that it filters out this value
>> when reporting back the payload, to avoid confusing the lifecycle
>> manager. The new behaviour is, on
>> discovering a mismatch between the written settings and the read
>> settings, to i) continue trying to
>> reread the settings to see if they will eventually agree, and ii) to
>> periodically reissue the rewrite to
>> see if that will also cause them to agree.
>> This issue also highlights the vital importance to the GPII of having
>> a standard set of acceptance
>> testing virtual machines, configured with each of the different
>> applications that we support, so that we
>> can detect these kinds of issues on a nightly build basis rather than
>> running into them weeks or months
>> Architecture mailing list
>> Architecture at lists.gpii.net <mailto:Architecture at lists.gpii.net>
> Architecture mailing list
> Architecture at lists.gpii.net
More information about the Architecture