GNOME Bugzilla – Bug 619398
Migrate to GSettings
Last modified: 2020-11-30 15:34:03 UTC
Orca rolls its own settings at the moment. That makes us a bad GNOME citizen. Plus our settings are rather messy at the moment. Migrating to GSettings is an official GNOME goal now [1], so we probably should get on this. :-) [1] http://live.gnome.org/GnomeGoals/GSettingsMigration
Alejandro, since you indicated an interest in this and the possible need for it to be done, would it be appropriate for you to take on this as part of your Andalucía work?
Ok, I did some research about this subject. Current state of python bindings of gsettings are very inmature. There's not support of GSettins via GObject Introspection because GVariant lack and there's no other bindings of GSettings into python. I'm thinking in another options like an abstract configuration system which knows how to represent itself in GConf settings or GSettings world. I would appreciate any help in this question.
Depends on bug #619501 Joanie, please assign me to this bug.
All yours. :-) Thanks!! As for this: > I'm thinking in another options like an abstract configuration system which > knows how to represent itself in GConf settings or GSettings world. This is my "just woke up, need coffee, haven't researched it" reaction: Something better-written and more robust that knows how to represent itself in a GSettings world sounds like a good idea to me. Off and on, on the desktop-devel-list [1] there has been discussion about GSettings migration. I don't know if there's anything in the threads there about the Python situation and how best to proceed. [1] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
FYI I'm following python-hackers-list [1] where people are working to bring GSettings to python via Python GObject Introspection [2] I feel like is the way to go. [1]: http://mail.gnome.org/mailman/listinfo/python-hackers-list [2]: http://live.gnome.org/PyGI
(In reply to comment #4) > All yours. :-) Thanks!! > [..] > Off and on, on the desktop-devel-list [1] there has been discussion about > GSettings migration. I don't know if there's anything in the threads there > about the Python situation and how best to proceed. > > [1] http://mail.gnome.org/mailman/listinfo/desktop-devel-list Actually I was following that thread and I think the migrtion discussed was more about apps that has already Gconf configuration and how to bring to those apps a "easy" way to work with the user's old gconf config and the new gsettings for awhile and how to migrate those configs. Anyway, I do believe the way for having GSettings in Python is to give to the library GObject instrospection support since is now the new way to create bindings in GNOME. I was looking the GSettings code and by now is quite far from having it (the GI support), but this is a must, so it will be sooner or later. Working with the Gsettings API in mind sounds good to me. If we are able to implement a configuracion system for Orca abstract enough to switch later to GSettings (or whatever...) will be great :-)
(In reply to comment #6) > Working with the Gsettings API in mind sounds good to me. If we are able to > implement a configuracion system for Orca abstract enough to switch later to > GSettings (or whatever...) will be great :-) Indeed it will. I say go for it. Thanks!
Hi all! I made a list with all orca settings that actually are stored in user-settings.py. I had defined many keys with its type and possible values. This list may be a first approach to new configuration model. Is there any interesting keys that will be added to that list? Regards!
Created attachment 162734 [details] Orca keys
Javier, thanks for doing this! At the moment I'm getting ready to head out for an appointment, so I've only barely glanced at your list. But based on your comment 8 I wanted to be sure you were aware of a couple of things: 1. Scripts can have (and write out) settings that only they need. If it's in a script_settings.py file, it will get written out to a file similar to user-settings.py in $HOME/.orca/app-settings. These items will also need to be handled (assuming you've not already dealt with them). 2. There have over the years been settings which we didn't include in the Preferences dialog (or explicitly write out for one reason or another) but make it possible for the user to override via user-settings.py. Therefore, a good check would be to go through settings.py looking for things which aren't on your list. Hope this makes sense. I'll be back in a while if you have questions.
(In reply to comment #10) Hi Joanmarie, > Javier, thanks for doing this! At the moment I'm getting ready to head out for > an appointment, so I've only barely glanced at your list. But based on your > comment 8 I wanted to be sure you were aware of a couple of things: > > 1. Scripts can have (and write out) settings that only they need. If it's in a > script_settings.py file, it will get written out to a file similar to > user-settings.py in $HOME/.orca/app-settings. These items will also need to be > handled (assuming you've not already dealt with them). We were looking the whole bunch of user settings and scripts and we think it better separate the actual settings from the scripting and customizations. GConf and GSettings can just store key-value settings, so we need to separate that kind of settings from others costumizations. But also we have to have in mind (I need to fill a bug... I forgot :-/) that Freedesktop already define a place for customizacions, user scripts and more stuff for the app but customized by the user. So we need to move those other things there. Probable on those places: ~/.config/orca/ ~/.local/share/orca Anyway, this is just the list Javi had been able to extract from user-settings.py os settings that can be stored as key-value. From this list we need to create a GConf Schema (later translated into GSettings Schema) and then Javi is going to be able to load and save all those keys and their values from GConf. Meanwhile, we'll move the user customizig/overwriting/scripting to better place (f.d.o rules) and we'll make sure they are loading successfully. > 2. There have over the years been settings which we didn't include in the > Preferences dialog (or explicitly write out for one reason or another) but make > it possible for the user to override via user-settings.py. Therefore, a good > check would be to go through settings.py looking for things which aren't on > your list. We are aware of that. We (actually Javi is doing it) are tracking down all the point were the configs (any kind) are loaded, used, called or stored, so we can figurate those other settings and what modules we have to touch. But the list is huge and we are not sure is there are settings deprecated, or missing, etc. That's why any help will be great. We'll see after the migration is there is something missing and it will be easy to get into the system, but it could be much better if we can reduce thode cases. About the settings.py, I think Javi was already checking there. But I guess is better to wait until he can connect (he hasn't have good intercnet connection at home so during the weekend he'll be a bit offline :-/ > Hope this makes sense. I'll be back in a while if you have questions. Thanks for the help and I'm sure Javi is going to thank any feedback and he will have more questions ;-) Cheers
Ok, I forgot, the bug for moving the ~/.orca was already filled: bug #596108 Some more info about: http://standards.freedesktop.org/basedir-spec/latest/index.html http://live.gnome.org/GnomeGoals/XDGConfigFolders Joanmarie, if you don't mind if I reassing that bug to Javi.
> We were looking the whole bunch of user settings and scripts and we think it > better separate the actual settings from the scripting and customizations. I totally trust you on this. (And am grateful you're doing it rather than me. ;-) ) But just to be sure we're on the same page.... There are settings (real, live settings) for Gecko stuff. They are used in Firefox and Thunderbird and Instantbird and Yelp 2.0. And they are set in the Orca App Preferences dialog. Some of them have associated keybindings. They are settings just like any other Orca setting. But since they are strictly settings for Gecko, they are not in settings.py; they are in Gecko/script_settings.py. I would think these would need to be included (right??). There is a similar situation for OOo.
(In reply to comment #13) > > We were looking the whole bunch of user settings and scripts and we think it > > better separate the actual settings from the scripting and customizations. > > I totally trust you on this. (And am grateful you're doing it rather than me. > ;-) ) Thanks :-) > But just to be sure we're on the same page.... There are settings (real, live > settings) for Gecko stuff. They are used in Firefox and Thunderbird and > Instantbird and Yelp 2.0. And they are set in the Orca App Preferences dialog. > Some of them have associated keybindings. They are settings just like any other > Orca setting. But since they are strictly settings for Gecko, they are not in > settings.py; they are in Gecko/script_settings.py. I would think these would > need to be included (right??). > > There is a similar situation for OOo. That's something we weren't sure about. We knew abour the user app-settings for overwriding the global app-settings, but we didn't check (yet) if there was any key we could take off and move into GConf. You've actually save us some work :-) Know we know more specifically what to look for. We've also to check then those places where the apps-settings are loaded to hook there as well the abstraction for the configuration. I think one of our problems here (apart form the big amount of keys whe have to manage...) is that there will be lots of places where we have to check for loading or saving settings. But hey, if this were easy or enjoyable, it'd have been done before, wouldn't it? :-P We'll check all those settings as well. Thanks for the tip :)
You bet. Here's another tip: You don't have to worry about pidgin/script_settings.py. We have generic chat support now -- something I need to migrate the pidgin script over to (bug 615489). I guess I should do that now since I keep threatening to do it. :-P Also, if you would find it a time saver to provide me with a list of "what the heck are these?" settings, I'd be happy to define them so that you don't have to deep-dive into the code to find out.
(In reply to comment #15) > You bet. Here's another tip: You don't have to worry about > pidgin/script_settings.py. We have generic chat support now -- something I need > to migrate the pidgin script over to (bug 615489). I guess I should do that now > since I keep threatening to do it. :-P It's good to know :-) > Also, if you would find it a time saver to provide me with a list of "what the > heck are these?" settings, I'd be happy to define them so that you don't have > to deep-dive into the code to find out. That'd be more than great :-) That also will be helpfully for the documention and the key descriptions (and translation comments) on the new schema files. I'm sure Javi will appreciate this and he will find out a specific list for you ;-)
Hi all! First of all, sorry for my absence but weekends I'm offline and yesterday I was busy working in other projects :( I suppose that Juanje and Alejandro were covering me answering all questions and design concepts during my absence. Thanks for keeping your attention answering this bug and related orca-list thread, resolving doubts and flaming a bit ... :P Well, this week I'm going to start with some proof of concepts, making an approximation of the gconf scheme and try to load some settings from it. I'll keep you informed and send all the advances in my personal orca's branch on gitorious (http://gitorious.org/~jhernandez/orca-mirror/jhernandez-orca-mirror). Joanie, about the 'what the heck are these?!' settings. At the moment, I get no doubts, but surely I will front this situation soon, and I will notify you :P When i started the thread i was looking for some punctual/special settings not in my first list (user-settings.py settings) and may be hardly considered. If the first scheme approximation is fine for all I'll keep working! Regards!
(In reply to comment #17) With respect to this: > Well, this week I'm going to start with some proof of concepts, making an > approximation of the gconf scheme and try to load some settings from it. > I'll keep you informed and send all the advances in my personal orca's branch > on gitorious > (http://gitorious.org/~jhernandez/orca-mirror/jhernandez-orca-mirror). Having your own mirror to make things easier for you is, of course, fine. However, as we get closer to the actual implementation.... We (Orca developers/contributors and Orca users) work upstream. Therefore, I'm wondering if perhaps the thing to do is create a branch in git.gnome.org in which to do this work. I'd think that would make getting and testing your work a lot easier. I don't know if you have git access for GNOME, but Juanje does, and so does Ale. Just a thought....
(In reply to comment #18) > (In reply to comment #17) > > With respect to this: > > > Well, this week I'm going to start with some proof of concepts, making an > > approximation of the gconf scheme and try to load some settings from it. > > I'll keep you informed and send all the advances in my personal orca's branch > > on gitorious > > (http://gitorious.org/~jhernandez/orca-mirror/jhernandez-orca-mirror). > > Having your own mirror to make things easier for you is, of course, fine. > However, as we get closer to the actual implementation.... We (Orca > developers/contributors and Orca users) work upstream. Therefore, I'm wondering > if perhaps the thing to do is create a branch in git.gnome.org in which to do > this work. I'd think that would make getting and testing your work a lot > easier. > > I don't know if you have git access for GNOME, but Juanje does, and so does > Ale. > > Just a thought.... It's a good idea, we'll create a new branch for this.
(In reply to comment #18) > (In reply to comment #17) > > With respect to this: > > > Well, this week I'm going to start with some proof of concepts, making an > > approximation of the gconf scheme and try to load some settings from it. > > I'll keep you informed and send all the advances in my personal orca's branch > > on gitorious > > (http://gitorious.org/~jhernandez/orca-mirror/jhernandez-orca-mirror). > > Having your own mirror to make things easier for you is, of course, fine. > However, as we get closer to the actual implementation.... We (Orca > developers/contributors and Orca users) work upstream. Therefore, I'm wondering > if perhaps the thing to do is create a branch in git.gnome.org in which to do > this work. I'd think that would make getting and testing your work a lot > easier. > > I don't know if you have git access for GNOME, but Juanje does, and so does > Ale. > > Just a thought.... We were thinking about to asking your permission after some proof of quality. I mean, I'd feel more confident about our pushes if the maintainers of the project we are working on bless some previous work so we know the code and commits are good enough. To be honest, Javi and David (who are coding on those a11y bugs) are good but quite newbies with Git and some GNOME standars. I've been so many branch meesed up because the use of git and I'd like they have some experience before to integrate their commits. I know that Ale would love to push the changes to a special branch at git.gnome.org for this (or another) bug, even myself, but I'd like first to be sure you think we are ready. Actually, I was to ask you to do it myself for the related bug about the config directories' location (bug #596108), but I didn't know if you will feel confortable with a lot of feature related branchs. Anyway, the decision is all yours and the person who should manage the Javi's works is Ale. I can offer may help but as a GNOME volunteer and I just wanted to show my vision about.
(In reply to comment #20) > > We were thinking about to asking your permission after some proof of quality. I > mean, I'd feel more confident about our pushes if the maintainers of the > project we are working on bless some previous work so we know the code and > commits are good enough. Hence my suggestion regarding "as we get closer to the actual implementation". Also, because this would *not* be master or the gnome-2-30 branch, but rather an entirely separate branch, if a change was in some way bogus you'd not be hurting anything other than your separate branch. I do not anticipate anything being committed to master until and unless it's been reviewed, properly tested, and suggested that you commit it to master. (I know that we all agree on this; I'm merely drawing the distinction between situations.) > To be honest, Javi and David (who are coding on those a11y bugs) are good but > quite newbies with Git and some GNOME standars. I've been so many branch meesed > up because the use of git and I'd like they have some experience before to > integrate their commits. To be honest back at ya, I was pretty sure that Javi didn't have commit access. So really what I was suggesting was that Ale (or you), having reviewed the work of your colleagues and tested it and pylinted it and concluded that what they had done was indeed of quality, commit it to a safe, separate, but upstream branch where it would not hurt anything in master, but would be more readily available for testing by us and by users. > I know that Ale would love to push the changes to a special branch at > git.gnome.org for this (or another) bug, even myself, but I'd like first to be > sure you think we are ready. And I appreciate that. Very much so. I trust that you and Ale will do the right thing and ask questions when they need to be asked and not proceed unless you are sure. I wouldn't have vouched for Ale's account if I didn't trust him to do that. :-) > Actually, I was to ask you to do it myself for the related bug about the config > directories' location (bug #596108), but I didn't know if you will feel > confortable with a lot of feature related branchs. I don't think bug 596108 requires a separate branch. That patch is not going to grow much larger, even with the changes we've discussed. And, as a general rule, no, I do not like a bunch of feature-related branches. But I suspect that the work on this bug is going to be much larger. And also suspect that there's a greater likelihood of unanticipated breakage. Therefore, I'd like to isolate the changes made to fix this bug from master but still make them readily available for testing. Sorry for any confusion as to what I was proposing!
(In reply to comment #21) > Hence my suggestion regarding "as we get closer to the actual implementation". Well, I guess I had missed that part :-P Sorry > Also, because this would *not* be master or the gnome-2-30 branch, but rather > an entirely separate branch, if a change was in some way bogus you'd not be > hurting anything other than your separate branch. > > I do not anticipate anything being committed to master until and unless it's > been reviewed, properly tested, and suggested that you commit it to master. (I > know that we all agree on this; I'm merely drawing the distinction between > situations.) Yes, I know and I agree. My concern was about to mess the separate branch. Sometimes with rebase+merge+push+whatever get messy and once the commits are pushed is more complicated to fix it properly. Then the merge is not so straight forward as it should/could be. Anyway, you're right what matters here is the commits merged into the master once everything is checked. > To be honest back at ya, I was pretty sure that Javi didn't have commit access. > So really what I was suggesting was that Ale (or you), having reviewed the work > of your colleagues and tested it and pylinted it and concluded that what they > had done was indeed of quality, commit it to a safe, separate, but upstream > branch where it would not hurt anything in master, but would be more readily > available for testing by us and by users. Again you are right. I also knew you knew that Javi didn't have commit access. I was thinking that if he makes the commits (after the reviews, checks, testing and pylinting)to his own branch (wherever it be) we can cherry-pick those commits or take from here the patchs so we integrate his patch as his, not as our commit. But well, it can be easily fixed by adding the '--author=' parameter to the commit... > > Actually, I was to ask you to do it myself for the related bug about the config > > directories' location (bug #596108), but I didn't know if you will feel > > confortable with a lot of feature related branchs. > > I don't think bug 596108 requires a separate branch. That patch is not going to > grow much larger, even with the changes we've discussed. And, as a general > rule, no, I do not like a bunch of feature-related branches. But I suspect that > the work on this bug is going to be much larger. And also suspect that there's > a greater likelihood of unanticipated breakage. Therefore, I'd like to isolate > the changes made to fix this bug from master but still make them readily > available for testing. It's going to have some more lines added and changed that I expected but yeah, no that much. I like to have (locally) a branch by bug or feature (at least) but no so much published. Too much branch at upstream is no very healty and it's very confusing. > Sorry for any confusion as to what I was proposing! Not at all. I understood and I was glad you proposing it. It's good idea and better for the integration. I've just to express some feelings about it to be sure you know all the team's knowledge and experience. I don't like to mess with other people's projects :-) Mostly because I care so much about GNOME and Orca and my goal with the team is that they learn well how to work properly with upstream. But I think I didn't explain myself very clearly again. I'm sorry.
Hi all! I finally started to code and I have to explain my first impressions and feedback will be gratefull. I'm codeing a new orca module, settings_manager.py (related to this bug), included in src/orca/ as others. My first need-to-change in orca's source code is to modify new orca_prefs.py, inserting some additional code for give to it load user-settings.py capabilities. This will be very helpfull for me cause my first intention is unify it for, later, load orca_prefs or rename it to classic_backend.py. I have created a new bug (bug 621518) to track this with a patch attachement. The patch contains the modifications that could be new orca_prefs.py or classic_backend.py, as you prefers. Review it and give me some feedback, please. Cheers!
Sorry just a quick note, bug 611576 introduced two more keys into settings.py, for you to take into consideration. "presentTimeFormat" and "presentDateFormat" Thanks
(In reply to comment #24) > Sorry just a quick note, bug 611576 introduced two more keys into settings.py, > for you to take into consideration. > "presentTimeFormat" and "presentDateFormat" > > Thanks These two keys are included Cheers!
(The whiteboard '3.0?' is just something I'm doing to mark items for some upcoming planning; in the case of this particular bug, it's not really a question.)
(In reply to comment #3) > Depends on bug #619501 > > Joanie, please assign me to this bug. Not sure you really need GVariant for this, other app authors have ported to GSettings without problems.
(In reply to comment #27) > (In reply to comment #3) > > Depends on bug #619501 > > > > Joanie, please assign me to this bug. > > Not sure you really need GVariant for this, other app authors have ported to > GSettings without problems. Can you point me some examples? Thanks Tomeu.
(In reply to comment #28) > Can you point me some examples? http://live.gnome.org/GnomeGoals/GSettingsMigration should link to quite some modules and examples.
(In reply to comment #28) > (In reply to comment #27) > > (In reply to comment #3) > > > Depends on bug #619501 > > > > > > Joanie, please assign me to this bug. > > > > Not sure you really need GVariant for this, other app authors have ported to > > GSettings without problems. > > Can you point me some examples? Sorry, I don't even remember who told me so, but the idea is that by using the g_settings_get_* functions you don't need GVariant support at all. But if someone could give a try to the patch at #619501 and report back, I may be able to find some time to submit a proper patch.
(In reply to comment #29) > (In reply to comment #28) > > Can you point me some examples? > > http://live.gnome.org/GnomeGoals/GSettingsMigration should link to quite some > modules and examples. Hi André, I check the list but any of them is pygtk code.
(In reply to comment #30) > (In reply to comment #28) > > (In reply to comment #27) > > > (In reply to comment #3) > > > > Depends on bug #619501 > > > > > > > > Joanie, please assign me to this bug. > > > > > > Not sure you really need GVariant for this, other app authors have ported to > > > GSettings without problems. > > > > Can you point me some examples? > > Sorry, I don't even remember who told me so, but the idea is that by using the > g_settings_get_* functions you don't need GVariant support at all. > > But if someone could give a try to the patch at #619501 and report back, I may > be able to find some time to submit a proper patch. I added to my todo list. I'll try it.
[Removing GNOME3.0 target as decided in release-team meeting on March 03, 2011. This report has an "important" categorisation for GNOME3.0 but is not considered a hard blocker. For querying use the corresponding whiteboard entry added.]
Hello!, What is the status of this? Do you plan to fix this for GNOME 3.2 ?
To be clear, I do not think this should be a blocker at all. * Orca's settings do not use gconf (i.e. it's not a deprecation thing) * Orca's settings use json (part of python and blessed external dependency I believe) * Nearly all Orca settings are NOT those which something like a universal access control panel (or similar tool) would wish to manipulate. (i.e. we're not really holding up progress) * There is already the screen-reader enabled/disabled gsetting which Orca does pay attention to appropriately. The magnifier setting is not part of Orca. Orca works with gnome-shell magnifier and pays attention to whether or not it is being used, but other than that magnification is not really "Orca's problem." Thus I think this is largely a "nice to have." Did you have some need for it to be implemented in time for GNOME 3.2 of which I am unaware? Having said that, it's bubbling to the top of our list now that we survived introspection. ;-)
Removing the blocks bug 622558 because it doesn't block it. :-)
From #a11y: < joanie> anyhoo, are you going to remove the gnome3-important whiteboard, or shall I? < joanie> as I really do think it's a nice to have which impacts no one outside of Orca < jjardon> yeah, feel free to remove it. It would be good to put a comment about that the bug is not to port from gconf, but for use Gsettings So to be abundantly clear: Not. For. GConf. :-) :-) Removing the gnome3-important. I'll aim for 3.2, but 3.4 is more likely. Marking as FUTURE until I set up new target milestones.
(In reply to comment #36) > Removing the blocks bug 622558 because it doesn't block it. :-) Yes, it does. This is how meta bugs work. :)
(In reply to comment #38) > (In reply to comment #36) > > Removing the blocks bug 622558 because it doesn't block it. :-) > > Yes, it does. This is how meta bugs work. :) Yeah, but I thought meta bugs worked by listing all the bugs which were relevant. ;-) Bug 622558 says "Gconf to GSettings migration" Orca does not use GConf. This bug is about migrating Orca's non-gconf settings to GSettings.
Ahem. Shame on me. Reverting.
There's a patch in bug 748248.
*** Bug 759006 has been marked as a duplicate of this bug. ***
Ok, I marked 759006 as a dup of this one, so consider the patch in that bug outdated. Attached is an updated patch, as in 759006, I noted one issue that remained, which I have addressed.
Created attachment 316987 [details] [review] Add GSettings support to Orca Patch to add gsettings support to Orca. Some notes: * The patch also enables the GSettings backend by default * No code has been written to migrate user settings from json to gsettings. * I have attempted to make the GSettings backend 100% compatible with how the JSON backend works, such that Orca should still function just as it does with the JSON backend.
Thanks for the patch and sorry for the delay (traveling, then holidays, now catch up). I noticed that you put nearly all of the settings in org.gnome.orca.general rather than breaking up things according to functionality (e.g. org.gnome.orca.speech, org.gnome.orca.braille, etc.). Did you find breaking things up into more modular schemas problematic? As a related aside, Orca's settings have some unfortunate names. This seems like a good time to make things consistent and sane. I wouldn't worry about writing code (to include in Orca itself, anyway) to migrate the settings. Maybe a stand-alone utility would be helpful for those who wish to use it. Should the schema files include localized summaries and descriptions?
On Sat, Jan 16, 2016 at 06:19:32AM AEDT, orca wrote: > I noticed that you put nearly all of the settings in org.gnome.orca.general > rather than breaking up things according to functionality (e.g. > org.gnome.orca.speech, org.gnome.orca.braille, etc.). Did you find breaking > things up into more modular schemas problematic? No, I must admit I didn't think about that much for the general settings. It could certainly be done. I'll work on a second iteration with settings broken up some more. > As a related aside, Orca's settings have some unfortunate names. This seems > like a good time to make things consistent and sane. Feel free to make the changes in master, and I'll adjust things appropriately. > I wouldn't worry about writing code (to include in Orca itself, anyway) to > migrate the settings. Maybe a stand-alone utility would be helpful for those > who wish to use it. Makes sense. The only thing I might add to this is if the user is starting with fresh config, then gsettings probably should be used, otherwise, use the already present json based config. > Should the schema files include localized summaries and descriptions? For completeness, they should, but I don't think its strictly necessary, and for most of the settings, a relocatable schema path is necessary, so it wouldn't be easy for users to know what schema path to use if they are reviewing things with dconf-editor for example. However, over time, its certainly something to work towards.
Created attachment 319535 [details] [review] New GSettings backend patch. Here is an updated patch, with settings split out some more, mostly into braille and speech subsections. I also took a stab at filling out summaries for as many settings as I could. Some probably need refinement, and others I didn't know what they were for, but its a start. They are also set up to be translatable.
Created attachment 321457 [details] [review] New patch to add GSettings support with support for latest sound settings additions. New patch. I've broken things up a little more, and added a sound schema.
Created attachment 321458 [details] [review] Patch to use GSettings when an existing JSON config file is not present. Here is a patch to also use GSettings by default if a json user-settings.conf file is not present.
Created attachment 321459 [details] [review] Revised patch to use gsettings by default if no json file present. This patch will now use the user-defined preferences location even if no file has been created there yet. Also cleaned up the class documentation since the backend argument was removed, since its not even used.
Review of attachment 321457 [details] [review]: This is obsolete. And the downstream version introduced various bugs, became unmaintained, and was ultimately removed from downstream.
Review of attachment 321459 [details] [review]: This is obsolete. And the downstream version introduced various bugs, became unmaintained, and was ultimately removed from downstream.
If anyone feels passionately about converting Orca's json based configuration and profiles to gsettings, please file an issue in gitlab.