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

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

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!

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.

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.

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.

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

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.

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:
6. Edit box for the name.
7. edit area for description.
8. OK.
9. 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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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).

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.

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

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).

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.

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).

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).

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.

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.

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.

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.

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.

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.

Comment 64 by James Teh <jamie@... on 2013-10-22 04:37
In [048f502]:

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.