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 🙂
I can see why you’re not able to use gsettings right now, but please for the love of good, don’t make something like the config system pluggable. This is adds no real advantage to end users, but multiplies the implementation work and testing matrix. Plus you can’t rely on any particular feature of any config system but must rely on the lowest common denominator.
Implement *one* config system and then spend your time working on the actual application instead. I know writing generic plumbing is fun, but its not really helping your users.
Trust me, it wasn’t our first option and it doesn’t seem fun for us, it’s just that they ask us to make things able to work with both (GConf and GSettigns) in the meantime.
The idea is to take off all the pluggable layer after the migration to GSettings is complete. At least, one of the ideas…
We algo need a solution for those distros based on already released versions of GNOME which doesn’t support GSettings and which won’t.
The idea is to make this “manager” as much simpler and light as we can so after we can remove it easily.
I share your concern but after some discussions at the bugs that was the better (temporary) solution we found. If someone come with a better solution for all the problems I said above, we’ll be really glad 🙂
Thanks for the comment 🙂
I cant’ decide what you want to work on of course, but generally “they ask us for XYZ” doesn’t automatically mean its a good idea, unless “they” are someone paying you money. Users have all sorts of requests, and its the role of the maintainer to collect all input, find out the best solution and then execute it. In many cases this results in telling users No to their requests.
In fact, saying no is generally what a maintainer do (as opposed to a normal developer).
But, its your code, do what you want.
The problem here is that we are not the maintainers and we are being paid for this job, so we need to do what the maintainers and the contractors believe that is better.
Ugh, the maintainer things this is a good idea? What, did we not learn anything in the last 10 years developing gnome. Do we have to make all mistakes over and over again…
*sad trombone*
Well….
My recollection is that saying that we need to migrate to gsettings from the crazy, roll-your-own situation we have now. I don’t recall proposing gconf. [1]
Regardless… With the deprecation of bonobo, we’re moving closer and closer to (hopefully) being able to not just be the GNOME screen reader, but perhaps also be a screen reader for KDE. So I am indeed very much in favor of a solution which does not limit us to just GNOME. And it is my understanding that, this solution will give us that. So in that sense, yes, I do think this is a good idea.
As for the sad trombone a couple of comments later…. There are lots of reasons to play it, including (but not limited to):
1. Many of the bugs preventing Orca from providing access to the GNOME desktop and its apps are not Orca bugs but bugs in the apps we’re trying to provide access to. And we can’t get the maintainers to fix those bugs. In some cases, bugs in other GNOME apps haven’t even been triaged, and four years have passed.
2. Companies shipping the GNOME desktop don’t see fit to invest sufficient funds to ensure that it’s accessible.
3. Oracle laid off the last remaining paid Orca developers. With no one else stepping up to the plate, a significant piece of GNOME accessibility support is now the (full-time volunteer) job of a teacher (aka me) who already has a full-time job.
I’m doing the best I know how to do to ensure that users who are blind will continue to have access to GNOME and (hopefully) one day have access to KDE. I would not object to people who know better (and who also have an understanding of accessibility for users who are blind) joining the effort.
Of all the things a ‘sad trombone’ should rightly be played for, I don’t think settings is one of them.
[1] https://bugzilla.gnome.org/show_bug.cgi?id=619398#c0
As I said on the PyGI bug report, I think GSettings is already usable in introspection-based bindings. You can only handle base types and string lists, but that’s what GConf handles. GNOME Shell has a patch to use GSettings through GJS, and nothing is missing. So please really consider GSettings.
Of course we’ll implement a backend for GSettings. We take care of that.
Yes, as you should notice I add the GVariant bug of pygi dependent of our GSettings bug in Orca.
I check pygi status when start to think about settings supports at Orca. What we want is a flexible system to maintain GConf (for GNOME = 3)
Pygi and glib teams are working hard. Thanks!
I think there are some (all valid) point of view and why the solution (still in progress) we take is the one I explain above:
* From my GNOMEr’s point of view was always abvious that migrate to GSettings was the right thing to do.
* From my Emergyan’s (the company I work for and the one is paid for the job) point of view I need a solution that we can finish before the our client’s deadline and something that should be working on GNOME 2.30.
* From the maintainers point of view they need to migrate to something because there are some bloked bugs because of the current setting system and because they want to be better GNOME citizents.
* Also from the maintainers point of view they see as people from others desktop doesn’t have screen reader and soonish they will have a a11y support so they’ll be ready to use a screen reader. Orca could integrate them if is open enough let them use it.
I believe the solution is just a compromise solution between all those point of views. Maybe is not the best sotulion but sure this will unblock some bugs and make the maintainers their life easier. And Orca has much more important issues to take care about I’m afraid :-/
From my point of view a little abstraction in this system don’t hurt. 🙂
Orca can move easily to any other context with this solution.