Configuration profiles #667

Closed
nvaccessAuto opened this Issue May 22, 2010 · 60 comments

2 participants

@nvaccessAuto

Reported by simon818 on 2010-05-22 21:55
I'm sure someone has said this already, so I apologize if this is a duplicate. But is there a possibility of having application specific preferences and dictionary settings?

what I pictuer is something like this: Each settings dialog has two tabs, one is default settings, one is application specific settings. In the application specific settings tab we could have a list box with applications to modify, and possibly a way to make a new settings file for a given program (although it's probably better to put this somewhere else in the settings menu.) And also in the application settings tab there could be a "restore to default settings" button. It's just a thought, and I realize this is a lot of work, but it woudl be nice to have the ability to add definitions for certain programs, and set NVDA to function differently in certain other applications (for instance, changing the voice rate when going into wordpad to read a book.) This, I realize, is a minor thing, but I thought it was worth posting.
Blocked by #3524
Blocking #650, #1913, #3165

@nvaccessAuto

Comment 1 by jteh on 2010-05-23 00:54
I can't help feeling that having settings per application is a rather arbitrary boundary, especially as so many applications now are huge and perform many different tasks, some applications even having the same name as other applications in the same suite (e.g. OpenOffice.org). Also, most settings are rather dependent on the content you're working with and are easy to toggle with one keystroke. Using punctuation as an example, doesn't it depend on the particular document you're reading as to whether you want punctuation read? This is why it is possible to toggle punctuation with NVDA+p.

Anyway, leaving this open, as there are cleary other users who want this as well. However, I'd like to see some good use cases.
Changes:
Milestone changed from 2010.2 to None

@nvaccessAuto

Comment 2 by fatma.mehanna on 2011-06-15 18:03
hi,
there are some similar features between microsoft word and internet browsers, so if there is a way to make nvda customizable, it would be good.
i might want to let nvda report tables in word, but i don't want it to report them in internet browser for example.
the same may happen in punctuations. now it became very customizable, so i may want to use the all level in ms word and want to use another level when reading plain text using wordpad.
best regards

@nvaccessAuto

Comment 3 by briang1 on 2011-06-15 22:10
The point is though, that punctuation is in a ring and can be easily changed and changed back. I too find the tables and alignment thing needs to be seperate for web applications and editors though, so maybe there is a case for seperating these at some point in the future.

Unfortunately, to make every single thing have the ability to be changed per application would seem to mean that all app modules need flags for these items and .ini files to look up for each one. Surely this will slow things down a lot and also make it a bit of a nightmare to set things up.
I know that it gets very hard, for example in Hal, where we have settings files, scripts and maps all providing application and general settings in different ways.

Scripts are, I suppose a bit like I want this to do this here cos the app is broken, Maps are the nuts and bolts such as what way to read the access info low down etc, and where to send it, and settings are basic things like punctuation level etc.
I'm not sure we want to get too far down that road!

@nvaccessAuto

Comment 4 by briang1 on 2011-11-16 08:37
I suppose what may well be handy would be for app modules to be able to somehow tell the user if they have had to change the way a setting is implimented. In the recent case of the media player in win 7, it would need in that particular case to disable use of uia, and if it was available use msaa which may well impact on other parts of the nvda system of course as well.
However in this case its unlikely to be actually changing the settings which are global directly, only because of accidental interactions perhaps.

@nvaccessAuto

Comment 5 by kredh on 2011-11-16 09:25
Well I think that there are different way of seeing this enhancement.

First, the question "why should it be useful": as I said on the mailing list, there are some applications which would be easier and faster to use with specific configuration. For instance, a "Cursor follows review" or "system" per application. But if that was all, it'd be useless (I agree on that). Though, there are some different possibilities:

  • Have a different sybmoles dictionary for some applications (the ones used for coding, one more time as a developer this is the first idea that I get)
  • Automatically slow down the speech when reading a document
  • Change the character echo on a web browser
  • Automatically change the cursor preferences on certain applications
  • ...

All this examples doesn't make sense for everyone. But the possibility to configure a specific application with specific NVDA configuration seems interesting to me and would allow a gain of quickness.

Well now, the question "how to implement" is not really my cup of tea. I don't even speak of the NVDA code. The fact to have different tabs in settings sounds a bad idea to me: first, there would be too many applications to configure.

I think that the simplest thing would be to have a profile system: in the NVDA main menu, instead of a button "save configuration", we could have "save configuration as". Pressing DOWN arrow on this button, we could find the default profile (used for every applications) and a possibility to add a new one. That way, each profile will contain EVERY configuration proposed by NVDA (the syntthetizer settings, the vocal ones, the braille ones, the cursor ones, etc).

Now, to bind an application to a profile, a special NVDA key could be used. Something like, press NVDA + I-DON'T-KNO-WWHAT in your applicatio, choose the corresopnding profile ("default" by default), press enter and that's it: the choosen application will load the configuration contained in this specific profile and would use it when you switch on it (by ALT + TAB or anyhow).

That's an idea, even if the "how" is not the right one, the "why to implement" could be demonstrate. That's two different questions.

Once more, forgive my long comment.

@nvaccessAuto

Comment 6 by dwillemv on 2011-11-16 19:41
I would also like this feature, though it can be implemented as different profiles that you can switch to.

uses include turning off progress bar announcements in applications like eclipse where they become a problem.
turning off tooltips while reading in a text editor.
having different voice speeds for different tasks(e.g speech when I mud is very fast, I read mail at medium speed and study and read at a slower speed. doing these tasks together currently involves a lot of key hammering to get the right speech speed.

@nvaccessAuto

Attachment profile.py added by norrumar on 2011-11-20 03:50
Description:
Very simple plugin to create profiles.

@nvaccessAuto

Comment 7 by surveyor on 2012-05-26 10:15
Because I'm illiterate of programming and python I couldn't manage but, it would be so nice and useful to pop-up a dialog for the user to select a predefined profile. Anyway, I've added 3 more profile and packaged as a nvda-addon. Thanks alot for the initial profile.py file.

@nvaccessAuto

Comment 8 by surveyor on 2012-05-28 11:47
Provision of a utility such as Profile Manager can be also useful for many users I think. The utility may have these controls:
1. A list in which the user can choose among previously created profiles.
2. A read-only edit area describing selected profile.
3. a button to create a new profile based on current temporary settings.
4. OK Button
5. Cancel button.
Create new profile dialog may have these controls:
1. Edit box for the name.
2. edit area for description.
3. OK.
4. Cancel.
By the way, attached translatable version of the addon with an extra profile added, Text-only reading: disabling reporting almost all notifications in document formatting.

@nvaccessAuto

Attachment Profil.nvda-addon added by surveyor on 2012-05-28 11:48
Description:

@nvaccessAuto

Comment 9 by parham on 2012-06-12 06:24
A test case that programmers might be familiar with is line indentation.

For example, I'd like to be notified of indentation changes when in Notepad++, but not when in the command line or in my browser. So, whenever I want to test a web application, I constantly have to press four keys to switch (insert+ctrl+d, alt+i, space, enter). It's not as simple as switching between punctuation levels any more.

The easy solution that comes to mind here is to add a toggle (E.G. insert+i for the desktop layout) to enable the announcement of indentation changes. However, I have seen this in other screen readers, and what happens is that over time, you run out of hotkeys to use to toggle a specific setting.

@nvaccessAuto

Comment 10 by aleskis on 2012-09-08 15:13
A major functionnality of vTurbo it the capability to add a profile manager per application. In plus answering to numerous examples given above, resulting of a strong need, adding this functionnality will reduce his attractivity of vTurbo.

@nvaccessAuto

Comment 11 by jteh on 2012-09-09 05:37
While I have begun thinking about the design of a framework to facilitate configuration profiles (even before the release of vTurbo), the existence of vTurbo doesn't necessarily increase the priority of this for us relative to other work. In fact, this arguably shows that others are quite capable of contributing this kind of enhancement, which suggests our limited resources are better devoted to other tasks. Certainly, we're not going to give this top priority simply to decrease the attractiveness of another product, regardless of any philosophical concerns that we or others might have.

@nvaccessAuto

Comment 12 by aleskis on 2012-09-09 07:06
You true. You can ignore the crappy philosophy of vTurbo and the potential cannibalization of donations for NVAccess because of vTurbo price. Nevertheless, this is the reason why I've also talk of strong need, ask by users since longtime ago, responding to specifics cases. Il my opinion, if you can't ignore something, this is your community. But I largely can understand that you won't increase the priority of this task just because of vTurbo.

@nvaccessAuto

Comment 13 by jteh on 2012-09-09 07:13
To clarify, I'm not suggesting we're ignoring that users are requesting this. As always, it's a matter of priorities.

@nvaccessAuto

Comment 14 by norrumar (in reply to comment 7) on 2012-09-22 09:34
Replying to surveyor:

Because I'm illiterate of programming and python I couldn't manage but, it would be so nice and useful to pop-up a dialog for the user to select a predefined profile. Anyway, I've added 3 more profile and packaged as a nvda-addon. Thanks alot for the initial profile.py file.

Hello, I saw and tested your add-on few days ago. Thanks! I have another add-on in development: prof.nvda-addon. It contains your Wikipedia profile, or something like it, Development, that reports line numbers and indentation, default profile and NoDetectLanguage profile, that uses another variant of eSpeak.
This add-on is in development, so I think we can borrow code and add a menu, etc.
The commands are:

  • control+shift+f: opens the dialog New profile, where you can put its name and press OK to create the profile folder. Here we can include same error messages if this folder is not created.
  • control+shift+,: reports the current profile, only the name.
  • control+shift+m: prior profile in the profile list.
  • control+shift+.: next profile.
  • NVDA+d: save changes to current profile.
  • NVDA+a: load the current profile. This command is for debugging and perhaps should be removed, because profiles are loaded when you press control+shift+m and control+shift+.

In this add-on profiles only include configuration files (nvda.ini).
It's at:
http://bit.ly/SL4KTc
Thanks.

@nvaccessAuto

Comment 15 by norrumar on 2012-09-23 10:43
Prof add-on is updated at:
 http://bit.ly/SL4KTc

There was a bug in the previous version when selecting another synthesizer, so that you had to restart NVDA when trying to open voices dialog. Now if the choosen synth driver can not load settings, this error is saved to NVDA+s log, but you can use it without restarting.
This add-on is useful for me, because I like read documents in different languages, but markup language is often wrong. However, I think that a profile can be used in different applications, and sometimes we need various profiles in the same application.
Regards.

@nvaccessAuto

Comment 16 by elliott94 (in reply to comment 1) on 2012-10-21 07:48
Replying to jteh:

I'd like to see some good use cases.

With 2012.3, the total number of items in Explorer are now announced (e.g. 1 of 25). Personally, I liked the previous behaviour. However, I want to keep positional information announcements enabled for other applications, but not Explorer. This is where something like this would be useful, in my opinion.

@nvaccessAuto

Comment 17 by jteh on 2012-10-25 07:29
There are two parts to this: settings profiles and automatic profile switching based on context. The first needs to be addressed before we can consider the second and has broader use cases.

Requirements for settings profiles:

  • Any setting can be changed in a profile.
  • They should only contain the settings that have been changed for that profile, not all settings. Once a setting has changed, it becomes a part of that profile.
  • They should be stackable. Initially, we'll probably only have one level. That is, profiles will inherit settings from the default configuration. However, allowing for more levels of stacking later provides for some interesting possibilities.

High level design:

  • Currently, our global configuration (config.conf) uses configobj.
  • Instead, config.conf will become an object which maintains a !ConfigObj for the current profile, as well as being able to query the profile below.
    • When a setting is written, it checks the value of that setting in the profile below. If it is the same, nothing is done. If is different, it is written to the !ConfigObj for the current profile.
    • When a setting is retrieved, it first checks the !ConfigObj for the current profile. If not there, it checks the profile below.
    • There are two ways to do this:
    • config.conf is always one object which tracks !ConfigObjs for all active profiles. When profiles are switched, the list of !ConfigObjs just gets changed.
    • Each profile is an object which tracks one !ConfigObj and the profile object for the profile below. config.conf is then switched whenever profiles are switched. I haven't decided which yet. Option 2 is perhaps nicer in terms of design, but it might be unnecessarily complex.
    • The really tricky bit is applying settings that have changed when profiles are switched.
    • Obviously, we first have to determine which settings have changed. This is just a matter of coding an efficient algorithm.
    • Once we have this, we have to know what methods to call to update the setting. Most settings don't require any calls, but many speech and some braille settings do.
    • A nice way to implement this would be if each setting had information about what is required to update it. However, this means having some sort of object for each setting which has to be registered, which seems like serious overkill, especially given that the majority of settings don't need it.
    • An alternative is to have some kind of hook for setting changes. Modules could then register a handler which is then passed each setting as it changes.
@nvaccessAuto

Comment 18 by ragb (in reply to comment 17) on 2012-10-25 10:49
Replying to jteh:

There are two parts to this: settings profiles and automatic profile switching based on context. The first needs to be addressed before we can consider the second and has broader use cases.

Will this ticket cover just profile creation, or both?

Requirements for settings profiles:

  • Any setting can be changed in a profile.

  • They should only contain the settings that have been changed for that profile, not all settings. Once a setting has changed, it becomes a part of that profile.

I'd add something that may seem a bit strange at firt, but here it goes: There should be some way to delete settings from a profile. See the following example:

  • You change a setting on the profile, and it becomes different fro the global configuration.
  • You then change the same setting on the the global configuration and it becomes equal to the profile.
  • Now the configuration comes from where? I'd say from the profile, and if you change again the global configuration the profile should be untouched, but there must be a way to delete a setting from the profile.

Is this clear at all?

  • They should be stackable. Initially, we'll probably only have one level. That is, profiles will inherit settings from the default configuration. However, allowing for more levels of stacking later provides for some interesting possibilities.

Hmm, can you elaborate with examples?

High level design:

  • Currently, our global configuration (config.conf) uses configobj.

  • Instead, config.conf will become an object which maintains a !ConfigObj for the current profile, as well as being able to query the profile below.

    • When a setting is written, it checks the value of that setting in the profile below. If it is the same, nothing is done. If is different, it is written to the !ConfigObj for the current profile.

    • When a setting is retrieved, it first checks the !ConfigObj for the current profile. If not there, it checks the profile below.

    • There are two ways to do this:

    1. config.conf is always one object which tracks !ConfigObjs for all active profiles. When profiles are switched, the list of !ConfigObjs just gets changed.

    2. Each profile is an object which tracks one !ConfigObj and the profile object for the profile below. config.conf is then switched whenever profiles are switched.

    I haven't decided which yet. Option 2 is perhaps nicer in terms of design, but it might be unnecessarily complex.

I like option 2 better, but option 1 is not that bad at all.

  • The really tricky bit is applying settings that have changed when profiles are switched.

    • Obviously, we first have to determine which settings have changed. This is just a matter of coding an efficient algorithm.

    • Once we have this, we have to know what methods to call to update the setting. Most settings don't require any calls, but many speech and some braille settings do.

    • A nice way to implement this would be if each setting had information about what is required to update it. However, this means having some sort of object for each setting which has to be registered, which seems like serious overkill, especially given that the majority of settings don't need it.

    • An alternative is to have some kind of hook for setting changes. Modules could then register a handler which is then passed each setting as it changes.

I'd prefere the hooking option. It's less coupling, and seems well more extensible. However, depending on the number of modules the hook, things may imply some performance pnalty. There are some python libraries that already implement this signaling sort of thing which we can apply, I think. (I can elaborate more on that if needed).

@nvaccessAuto

Comment 19 by jteh (in reply to comment 18) on 2012-10-26 00:23
Replying to ragb:

Will this ticket cover just profile creation, or both?

This ticket will just cover profiles, not automatic switching.

Requirements for settings profiles:

There should be some way to delete settings from a profile. See the following example:

  • You change a setting on the profile, and it becomes different fro the global configuration.

  • You then change the same setting on the the global configuration and it becomes equal to the profile.

  • Now the configuration comes from where? I'd say from the profile, and if you change again the global configuration the profile should be untouched, but there must be a way to delete a setting from the profile.

I can't come up with a good UI for this, so unless someone else can, this feature isn't useful. I figured the user could just change the setting in the profile if it was incorrect. Perhaps I'm misunderstanding you, though.

allowing for more levels of stacking later provides for some interesting possibilities.

Hmm, can you elaborate with examples?

For me, application specific settings is just a minor part of this. It could also be used to have different settings for say all, for example. A user might have a profile which disables reporting of tables for a web browser, but they might also have a profile for say all which disables reporting of links and changes the synthesiser. When a user performs a say all in this web browser, the say all profile should apply on top of the web browser profile. Of course, this is very complex stuff and need not be handled in the initial auto switching implementation (if ever), but allowing for it in the core profile design will make it much easier to implement later. I don't think supporting this adds much complexity.

  • The really tricky bit is applying settings that have changed when profiles are switched.

...

  • Once we have this, we have to know what methods to call to update the setting.

I'd prefere the hooking option. It's less coupling, and seems well more extensible. However, depending on the number of modules the hook, things may imply some performance pnalty. There are some python libraries that already implement this signaling sort of thing which we can apply, I think. (I can elaborate more on that if needed).

Please do elaborate. However, any sort of signalling infers at least one function call per module. Even if you check some conditions before calling the hook, the check itself is probably going to require a function call, so I'm not sure we can get more efficient than just calling functions.

@nvaccessAuto

Comment 20 by jteh on 2012-10-26 00:25
Changes:
Changed title from "application specific settings" to "Configuration profiles"

@nvaccessAuto

Comment 21 by ragb (in reply to comment 19) on 2012-10-27 11:41
Replying to jteh:

Replying to ragb:

Requirements for settings profiles:

There should be some way to delete settings from a profile. See the following example:

  • You change a setting on the profile, and it becomes different fro the global configuration.

  • You then change the same setting on the the global configuration and it becomes equal to the profile.

  • Now the configuration comes from where? I'd say from the profile, and if you change again the global configuration the profile should be untouched, but there must be a way to delete a setting from the profile.

I can't come up with a good UI for this, so unless someone else can, this feature isn't useful. I figured the user could just change the setting in the profile if it was incorrect. Perhaps I'm misunderstanding you, though.

Probably I'm being too complex on this. I'll try another example to explain my idea:

  • I'm editing settings for some particular profile. I go to the voices settings and I'd like to change de rate for this particular profile.
  • However, While trying changing the rate, I acidentaly change the pitch setting and it becomes part of the profile. I'd like the pitch be globaly set, not on this profile.
  • I have two options:
  • delete the profile and create it again, avoiding making mistakes (If I had many profile customizations that would be boring);
  • Change the pitch within the profile everytime I change it globaly.

Here pitch and rate are hipotetic settings, of course.

Note that we can say that any of this options are right, due to UI complexity or any other reason. 'm just brain-storming use cases that may come up.

My suggestion for the UI (which might be questionable) is the following. Considering we edit settings for a profile with a similar UI we do now (settings dialogs for voice, braile, etc), you could have a revert to global configuration button on each dialog, that would be visible when we were editing settings for a profile (not globaly). That button, when pressed, would delete all references for the dialog settings from the profile, reverting of course the configuration to the global configuration object. This means that deletion is per set of related settings, no per individual setting.
This may be a possiblity.

allowing for more levels of stacking later provides for some interesting possibilities.

Hmm, can you elaborate with examples?

For me, application specific settings is just a minor part of this. It could also be used to have different settings for say all, for example. A user might have a profile which disables reporting of tables for a web browser, but they might also have a profile for say all which disables reporting of links and changes the synthesiser. When a user performs a say all in this web browser, the say all profile should apply on top of the web browser profile. Of course, this is very complex stuff and need not be handled in the initial auto switching implementation (if ever), but allowing for it in the core profile design will make it much easier to implement later. I don't think supporting this adds much complexity.

Sure, those are valid good points.

  • The really tricky bit is applying settings that have changed when profiles are switched.

...

  • Once we have this, we have to know what methods to call to update the setting.

I'd prefere the hooking option. It's less coupling, and seems well more extensible. However, depending on the number of modules the hook, things may imply some performance pnalty. There are some python libraries that already implement this signaling sort of thing which we can apply, I think. (I can elaborate more on that if needed).

Please do elaborate. However, any sort of signalling infers at least one function call per module. Even if you check some conditions before calling the hook, the check itself is probably going to require a function call, so I'm not sure we can get more efficient than just calling functions.

I think we can't really go better than function call. My idea was something like a publish/subscribe model. I believe that any NVDA module should be able to subscribe to any setting change, even for add-ons, so they can react if needed.(this might be extensible for other NVDA events or changes. Ok, you may be thinking... "this guy is crazy for hooks or publish and subscribe things alike"). We can implement these things ourselvs or can use something like the pidispatcher package:

http://pydispatcher.sourceforge.net/

Porobably wxPython also have some helpers to do it, mainly if we need things to happen on the GUI thread (probably that may be better handled by the hooking code, to send things for being executed assynchronusly, when needed).

@nvaccessAuto

Comment 22 by jteh (in reply to comment 21) on 2012-10-29 07:00
Replying to ragb:

Probably I'm being too complex on this. I'll try another example to explain my idea:

I understood your first example.

My suggestion for the UI (which might be questionable) is the following. Considering we edit settings for a profile with a similar UI we do now (settings dialogs for voice, braile, etc), you could have a revert to global configuration button on each dialog, that would be visible when we were editing settings for a profile (not globaly).

I guess that'd work, though I still find it a bit inelegant, which isn't to say I have any better ideas. Anyway, we can certainly include a function to remove a setting and perhaps one to check whether a setting is inherited.

My idea was something like a publish/subscribe model. I believe that any NVDA module should be able to subscribe to any setting change, even for add-ons, so they can react if needed.

The big question is how they specify which settings to subscribe to. Subscribing to individual settings is ugly and may not work for some things. Do we use some sort of pattern? That seems ugly, though.

@nvaccessAuto

Comment 23 by ragb (in reply to comment 22) on 2012-10-30 00:05
Replying to jteh:

Replying to ragb:

My suggestion for the UI (which might be questionable) is the following. Considering we edit settings for a profile with a similar UI we do now (settings dialogs for voice, braile, etc), you could have a revert to global configuration button on each dialog, that would be visible when we were editing settings for a profile (not globaly).

I guess that'd work, though I still find it a bit inelegant, which isn't to say I have any better ideas. Anyway, we can certainly include a function to remove a setting and perhaps one to check whether a setting is inherited.

Apple's VoiceOver on OSX, on the activities dialog (sort of profiles) has some check boxes to configure if subsets of settings are included on the activity (voice, forating, etc.). That might be an option, but IMO it might complex for users to remeber what settings they define for the profile or not.

My idea was something like a publish/subscribe model. I believe that any NVDA module should be able to subscribe to any setting change, even for add-ons, so they can react if needed.

The big question is how they specify which settings to subscribe to. Subscribing to individual settings is ugly and may not work for some things. Do we use some sort of pattern? That seems ugly, though.

I do not dislike the pattern way, something like speech.*, to subscribe to all speech settings changes. Probably, for this pattern idea, we might need to implement our own publish and subscribe solution (didn't thought about the need to subscribe for many settings at once, with the pydipatcher suggestion).

@nvaccessAuto

Comment 24 by camlorn on 2012-12-27 02:17
First, I just want to register my support for this.
Second, to share my thoughts.
I think this begins to show the shortcoming of the NVDA settings system--you can't do complex things. I like the NVDA setting system, it's easy and straight-forward, and makes this less needed than in anything else I've used.
Perhaps this should be a separate ticket, but it probably isn't a bad idea to consider moving settings to a "setting center", or something: a treeview of settings, from which you select the one to change, tabbing to a checkbox or combobox to do the actual changing, tabbing to a save button when done. Such a UI would in fact allow for extra buttons: the delete setting button, the delete selected category button, etc. It would allow for switching the profile being changed without having to make the other profile load (less important, we probably don't care about this ability right now).
Use cases: visual studio (indentation is the big one), firefox, mushclient, mirc, etc: see #698 for another one (application specific setting of whether or not typing interrupts speech comes to mind here).

@nvaccessAuto

Comment 25 by jteh (in reply to comment 24) on 2012-12-27 05:23
Replying to camlorn:

it probably isn't a bad idea to consider moving settings to a "setting center", or something: a treeview of settings, from which you select the one to change, tabbing to a checkbox or combobox to do the actual changing, tabbing to a save button when done.

We've discussed this idea a bit. However, it's worth noting that I can't think of a single application (other than some screen readers) that does this for its user (non-advanced) settings. It makes for a fairly tedious user interface, since you have to move to a setting, move to the adjustment control, change the value and then move back to the settings tree to access more of them. As a result of the fact that it's not done anywhere else, it's also harder for new users to follow. In any case, if this is going to get serious discussion, it definitely belongs in another ticket.

@nvaccessAuto

Comment 26 by camlorn on 2012-12-27 23:31
Imho, it does have some strengths, especially if implemented like the windows start menu--typing the name of a setting narrows the list--but it is probably also the best UI for the ability to delete a specific setting. I think that both have strengths and weaknesses. I don't think it is important at the moment, but it does help down the road if suddenly there needs to be 100 new settings for some reason. I haven't yet read the discussions on this--I haven't looked, as I hadn't gathered the information I wanted to before starting that ticket.

@nvaccessAuto

Comment 27 by camlorn on 2013-02-25 16:49
Now that we have typing interrupt, and now that I've switched fully to NVDA, I just want to say I was right about this being useful with those two settings.
To add another use case: programming. When programming, i want at a minimum a different level of punctuation, possibly a whole group of different voice settings. provided I always use the same IDE, I can just use this and get what I want.
I also second the bit about say all and tables and such, and making this system extensible enough to let me change those settings. I like the idea of having a different voice for say all, as well as other settings like that: reporting format changes, links, and all that. I could see uses for this, especially when reading novels.
I'd also add that being able to manually change between profiles would also be useful.
This is one of the few features I really miss from jaws.

@nvaccessAuto

Comment 30 by jteh on 2013-08-02 06:38
Try build: http://community.nvda-project.org/try/t667/nvda_snapshot_try-t667-9408,b6091b1.exe

Manual profile switching should be close to fully implemented. There's no documentation yet. Briefly:

  • Profiles contain only the settings you change. All other settings are taken from your base configuration.
  • To switch/manage profiles, press NVDA+control+p or select Configuration profiles from the NVDA menu.
  • Once a profile is activated, any settings you change will be saved to that profile.
  • If you select (none), all settings will be read from and written to your base configuration.

Please test and report any issues.

Automated switching is even more complex and will probably be implemented separately unless manual switching is truly useless to everyone except me.

@nvaccessAuto

Comment 31 by aleksey_s on 2013-08-02 06:54
Manual switching might be useful if we implement quick way of changing profile (by mean of 1-2 key presses). What about remembering which profile user selected last, and script to switch between current and the last profile? Or we can add a button in the profile dialog and make a mnemonics for it. then switching between two most used profiles would be only two keypresses.

Another useful feature for me is ability to switch NVDA language. Currently I use a small home-written plugin to switch NVDA configuration (language and current synth). Of course language change does not fully take effect, but its enough for my purposes (punctuation & some messages). So please keep ability to do that in profiles :-)

@nvaccessAuto

Comment 32 by jteh (in reply to comment 31) on 2013-08-02 07:00
Replying to aleksey_s:

Another useful feature for me is ability to switch NVDA language. Currently I use a small home-written plugin to switch NVDA configuration (language and current synth). Of course language change does not fully take effect

Speech language is included in profiles, which also includes punctuation/symbols. As you said, UI language can't fully take effect without a restart, so this isn't included in the profile. Including it would just confuse users; some of the messages would be in the right language but not others.

@nvaccessAuto

Comment 33 by aleksey_s on 2013-08-02 07:00
Seeing on how you're implemented handling changes of configs for different subsystems which require special treatment (speech & braille so far) I wonder whether we can implement a less coupled mechanism to allow subsystems to register for config changes. That way plugin writers might also have ability to act apropriately without resorting to monkey patching.

@nvaccessAuto

Comment 34 by jteh (in reply to comment 33) on 2013-08-02 07:04
Replying to aleksey_s:

Seeing on how you're implemented handling changes of configs for different subsystems which require special treatment (speech & braille so far) I wonder whether we can implement a less coupled mechanism to allow subsystems to register for config changes.

That'd be nice, though I don't think it blocks the initial merge. This requires some sort of unified hooking mechanism. I came up with a few ideas, but all of them suck, break in various situations and/or require you to explicitly register and unregister. In a dynamic language, we really shouldn't have to explicitly register/unregister stuff. :)

@nvaccessAuto

Comment 35 by aleksey_s (in reply to comment 32) on 2013-08-02 07:11
Replying to jteh:

Speech language is included in profiles, which also includes punctuation/symbols. As you said, UI language can't fully take effect without a restart, so this isn't included in the profile. Including it would just confuse users; some of the messages would be in the right language but not others.

Unfortunately not all synths support language switching and some will never support it. We might consider making _() function lazy, to get translation at the last stage when the text needs to be outputted - e.g. the way django handles that. Of course in scope of another ticket. But since we already have a dialog asking for NVDA restart after change of language, it should be not hard to modify it to include special warning if user are making change in scope of a profile.
That way we have a feature for advanced users and have warned users who do not care about it. Or am I asking for too much?

@nvaccessAuto

Comment 36 by aleksey_s (in reply to comment 34) on 2013-08-02 07:17
Replying to jteh:

That'd be nice, though I don't think it blocks the initial merge. This requires some sort of unified hooking mechanism. I came up with a few ideas, but all of them suck, break in various situations and/or require you to explicitly register and unregister. In a dynamic language, we really shouldn't have to explicitly register/unregister stuff. :)

OK, but I would say Keep it simple, stupid :) Do we really care is it just config.registerForConfigChange(handler) and config.unregisterForConfigChange(handler) or event_configurationChanged on the plugin or both?..

@nvaccessAuto

Comment 37 by jteh (in reply to comment 36) on 2013-08-02 07:29
Replying to aleksey_s:

Unfortunately not all synths support language switching and some will never support it.

They don't have to support automatic switching to benefit from this. If they don't support language switching at all, including it in the profile wouldn't help you anyway.

We might consider making _() function lazy, to get translation at the last stage when the text needs to be outputted

That'd require a massive amount of code change, since a lot of the places where we use _() expect a string, not some object they have to call str() on. Still, if you feel strongly about it, please do file a ticket.

But since we already have a dialog asking for NVDA restart after change of language, it should be not hard to modify it to include special warning if user are making change in scope of a profile.

Maybe, but it looks pretty unpolished and nasty, even if it is a nice advanced hack. I tend to prefer not to implement something than to implement something half-baked and broken.

Or am I asking for too much?

Perhaps for an initial implementation :), but you're welcome to file an enhancement for this.

Replying to aleksey_s:

Do we really care is it just config.registerForConfigChange(handler) and config.unregisterForConfigChange(handler)

Ug. So many plugin authors are going to forget to unregister. Also, we're going to need a hooking mechanism in other places too, so we may as well unify it.

or event_configurationChanged on the plugin

Doesn't work for speech, braille, etc.

or both?..

Inconsistency is evil. :)

I filed #3393 to try to find a unified solution.

@nvaccessAuto

Comment 38 by fatma.mehanna on 2013-08-10 09:07
hi,
can you add a feature for importing and exporting these profiles to be easier for restoring them again?
thanks.

@nvaccessAuto

Comment 39 by jteh on 2013-08-10 09:19
Changes:
Milestone changed from None to next

@nvaccessAuto

Comment 40 by James Teh <jamie@... on 2013-08-10 09:20
In [0e97469]:
```CommitTicketReference repository="" revision="0e97469fc5b5e6e4dd416e76248346decde00569"
Merge branch 't667' into next

Incubates #667.

Changes:
Added labels: incubating
@nvaccessAuto

Comment 41 by jteh (in reply to comment 38) on 2013-08-10 09:21
Replying to fatma.mehanna:

can you add a feature for importing and exporting these profiles to be easier for restoring them again?

We don't currently have a way to export/import configuration in general, so this is a more general feature request. Fwiw, profiles are just ini files like the NVDA configuration file.

@nvaccessAuto

Comment 42 by PZajda (in reply to comment 40) on 2013-08-10 10:41
Replying to James Teh :

In [0e97469]:

#!CommitTicketReference repository="" revision="0e97469fc5b5e6e4dd416e76248346decde00569"
Merge branch 't667' into next

Incubates #667.

Great!
Could you make it available as the current "next" branch snapshot please?

@nvaccessAuto

Comment 44 by James Teh <jamie@... on 2013-08-20 10:27
In [0b5118e]:
```CommitTicketReference repository="" revision="0b5118e5b44180c7330ba17f5d891f846b9499f3"
Merge branch 't1913' into next

Incubates #1913, #667.

@nvaccessAuto

Comment 45 by James Teh <jamie@... on 2013-08-23 13:49
In [bfea638]:
```CommitTicketReference repository="" revision="bfea63892d6a9e63e86db4d26ec13bb15fb44c69"
Merge branch 't667' into next

Incubates #667. Re #1913.

@nvaccessAuto

Comment 46 by James Teh <jamie@... on 2013-09-12 01:49
In [b120c93]:
```CommitTicketReference repository="" revision="b120c93442d5f1367e3b7af3fd4cbe398c9a675e"
Merge branch 't667' into next

Incubates #667.

@nvaccessAuto

Comment 48 by James Teh <jamie@... on 2013-09-13 08:21
In [64c1988]:
```CommitTicketReference repository="" revision="64c198882fd30be0eaab86abfe0d8ea6502065fc"
Merge branch 't667' into next

Incubates #667. Fixes #3524.

@nvaccessAuto

Comment 49 by beqa on 2013-09-13 10:51
hi.

one more error.

when adding trigger and say all is unchecked nvda displays error.

ERROR - unhandled exception (14:50:51):
Traceback (most recent call last):
File "gui\configProfiles.pyc", line 264, in onClose
File "configobj.pyc", line 643, in delitem
KeyError: 'sayAll'

@nvaccessAuto

Comment 51 by James Teh <jamie@... on 2013-09-13 22:43
In [23b20c2]:
```CommitTicketReference repository="" revision="23b20c22fbcf9ea13d95b79f41ee382ed08129cb"
TriggersDialog: Don't barf when say all is unchecked and the say all trigger isn't associated with any other profile.

Re #667.

@nvaccessAuto

Comment 52 by James Teh <jamie@... on 2013-09-13 22:43
In [9f66029]:
```CommitTicketReference repository="" revision="9f660291af006a6d8f46c5130a5d849bc6e07abd"
Merge branch 't667' into next

Incubates #667.

@nvaccessAuto

Comment 54 by James Teh <jamie@... on 2013-09-24 03:21
In [c74811f]:
```CommitTicketReference repository="" revision="c74811ff0002aba0ff8c56dd731e5a49f76fe3a8"
Merge branch 't667' into next

Incubates #667.

@nvaccessAuto

Comment 55 by James Teh <jamie@... on 2013-10-01 02:09
In [b758136]:
```CommitTicketReference repository="" revision="b7581366c34a85cfa6d0c54f1f5ce6b074103cb2"
Merge branch 't667' into next

Incubates #667.

@nvaccessAuto

Comment 56 by jteh on 2013-10-01 02:10
Please note that existing profile triggers will need to be set again, as I had to change where they are stored. Sorry for the inconvenience.

@nvaccessAuto

Comment 57 by jteh on 2013-10-13 23:16
For those that do want to clear the useless trigger data out of the old location, do the following:
1. Press NVDA+control+z to open the Python console.
2. Copy and paste this line:

 import config; config.conf.profiles[0]["profileTriggers"].clear()
  1. Save your configuration. You don't need to do this, but I'm providing the info for those that care.
@nvaccessAuto

Comment 58 by James Teh <jamie@... on 2013-10-13 23:18
In [838882a]:
```CommitTicketReference repository="" revision="838882ad3b47703e3f898f811d32572760dbe8fa"
Merge branch 't667' into next

Incubates #667.

@nvaccessAuto

Comment 59 by James Teh <jamie@... on 2013-10-16 06:29
In [d92358e]:
```CommitTicketReference repository="" revision="d92358efa813ea5da5e947c7084cf544d7c9a48c"
You can now have different settings for different situations using configuration profiles. Profiles can be activated manually or automatically (e.g. for a particular application).

Fixes #87, #667, #1913.

Changes:
Removed labels: incubating
State: closed
@nvaccessAuto

Comment 60 by jteh on 2013-10-16 06:31
Changes:
Milestone changed from next to 2013.3

@nvaccessAuto

Comment 61 by nvdakor on 2013-10-16 10:04
Hi,
If a user updates to the latest next snapshot (9855), one would see duplicate entries for this ticket in what's new. This does not appear for master branch. Thanks.

@nvaccessAuto

Comment 62 by jteh (in reply to comment 61) on 2013-10-16 22:23
Replying to nvdakor:

If a user updates to the latest next snapshot (9855), one would see duplicate entries for this ticket in what's new. This does not appear for master branch.

Fixed in 4e28b25. Thanks.

@nvaccessAuto

Comment 63 by leonarddr on 2013-10-19 11:09
There's currently a major issue. When you create a profile which is triggered by an application and the profile is both triggered and manually activated, whenever you delete the profile there's nothing active anymore. Behavior should be that the normal configuration is active again.

@nvaccessAuto

Comment 64 by James Teh <jamie@... on 2013-10-22 04:37
In [048f502]:
```CommitTicketReference repository="" revision="048f502e7f41430c5b83d45dc9b280fd87c692ff"
Correctly handle deletion of a configuration profile when it is both manually activated and triggered.

Previously, the profile remained active even though it had been deleted. In the profile list, it appeared as if nothing was active.
Re #667.

@jcsteh jcsteh was assigned by nvaccessAuto Nov 10, 2015
@nvaccessAuto nvaccessAuto added this to the 2013.3 milestone Nov 10, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment