We keep working on a11y improvements for the GNOME desktop. We’re focused on some Orca and OCRFeeder bugs the Consorcio Fernando de los Ríos has ask us to fix.
But when we started with the Orca’s ones we realized that Orca needed a better configuration system and Joanmarie (Orca’s maintainer) invited us to solve this before going on fixing the other bugs.
At this point we had to decide what configuration system we should migrate Orca to. At the first shot, GSettings seemed to be the better choice, but after a second thought it didn’t seem so obvious.
Let’s see some issues we found about it:
- GSettings is not fully implemented right now
- Orca is written in Python and the GSettings support for GSettings (via PyGI) is not ready
- We need those changes available for Guadalinex v7 and Guadalinfo v6 distributions which ship a GNOME version with no GSettings support at all. Backporting Glib for getting that support doesn’t seem to be a good and healthy choice…
- Some people like to have plain text based files for the settings
That’s why, after some discussions we all agreed to create a settings manager that could be plugged by different config backends (plain texts, old Python based config, GConf, GSettings, KDE settings?, etc). It is not much more work and it would make happier everyone 🙂
The settings manager itself is almost ready and now it is working properly with the old Python based config files. The next step is to get the GConf backend ready to go. Later, when the GSettings support in Python is ready, we’ll create that backend based on the GConf one (it should be easy).
For the GConf backend we are focusing first on defining the schema, because there are a lot of different keys and values to care about and they need to be checked and confirmed. My friend Javi is working on that and he has asked for help to check for missing keys, values or deprecated ones. Any help here will be very useful.
Once he has the GConf schema, he’ll be able to create the backend which will get and set the different keys and values into GConf system.
I know that all this settings manager sounds a bit overcomplicated but the implementation won’t be and we need it, at least for the transition. Hopefully we’ll skip this manager and we’ll let just the GSettings connection at the next cycle.
The discussions were very interesting and explained better than me the needs that made us to take this approach so, I recommend reading them if you’re interesting on this topic.
And, of course, any ideas are welcome 🙂
