So, the GSoC is over. During the summer the project changed form the initial vision quite a bit. Instead of being a simple standalone profile editor, the lockdown solution I’ve been working on requires some changes in:
- Accountsservice, where the changes are in gitorious for now.
Status — everything seems to be working, except role path validation.
- Gnome control center (code tarball), where I did the work on the older version that ships with Ubuntu 12.04.
Status — as of this moment unusable. Setting and getting lockdown profiles for existing users is there, but creating a new user with profile is not functional and some polish is needed for smooth UX.
- The lockdown editor itself (code tarball).
Status — Totally unusable. Very early prototype.
As a GSoC project it would be hard to call it a success. The main item — the lockdown editor itself — did not materialize.
Pitfalls during the project
- Knowing a programming language doesn’t help much if you don’t know the libraries. I thought I knew data structures in C, but glibc has its own ideas about everything and this was a new thing to learn.
Solution — get to know the environment before taking up the task.
- Moving targets. At the beginning of this project, there was just the lockdown editor, now it is a lockdown delivery system, where the editor itself is not really that important. It is hard to stick with a floating schedule.
Solution — before making a proposal, talk with interested parties and find out what they want.
- Exams and GSoC don’t blend well. One month of the GSoC period was wasted in exams.
Solution — start working on the project before the GSoC even starts to get some breathing space.
- Working with the cutting edge cuts badly. During the project several times I tried to get gnome-control-center to compile with jhbuild. Most of the time it failed to compile (to get to g-c-c, about 100 modules must be compiled beforehand). The only time it did compile, it crashed and burned.
Solution — if you are not an expert in the environment, don’t work with master.
In short — don’t just jump in with proposal in the last minute. It will hurt.
Interesting things I learned
- GOTO statements are OK in some situations.
- Code comments are not really necessary. Just read the code and an epiphany will hit you. </sarcasm>
- Sometimes pre-existing code is like math — you don’t understand it, you just get used to it.
For this all to have any meaning at all, these things have to happen:
- distributions must ship with the new accountsservice, which is not even merged upstream (quite likely to happen);
- changes made in g-c-c must be merged in master (should be possible with some pain);
- gdm should support all this lockdown sorcery (yes, I didn’t mention gdm before, but someone will have to code the support for all this);
- distributions should have the these packages included (like Ubuntu, which just loves to ship the latest gdm. Or was it lightdm? Oh my!</sarcasm>).
In short, these changes will most likely not see daylight in the next round of distribution releases.
By normal project criteria, my project has failed, but in its new form it seems more useful than at the beginning. It is behind schedule, but I expect this to be working as intended in the 3.8 GNOME release.
During the last GUADEC the vision on lockdown editor specifics got quite clear:
- The information about which user has which profile is stored in AccountsService. The newest changes are found in forked repository. It allows basic reading and writing of profile information.
- I previously hacked gnome-control-center to support different user roles. At the time the back-end wasn’t decided yet, so I now I will update it to get data from AccountsService. This time I hope to get g-c-c to compile with jhbuild.
- The profiles themselves will be in keyfile format, so they should be easily editable by hand. This should make the lockdown usable even before the lockdown editor itself is made.
Yesterday I spent the whole day with translators discussing how to make localization efforts easier for everyone. The work in progress is documented on GNOME wiki page.
A quick overview of things to be done:
- Make a release calendar, to keep translators in the flow of the software release cycle.
- Give priorities to modules to help new/small teams make the best use of their time and effort.
- Make a policy of deprecating modules and asking maintainers to make a new release when new translations are added to an otherwise inactive project.
- Statistics should be based on words, not strings (still being discussed).
- Increase required string percentage from 80% to 90% for supported languages, but limit the modules which have to be translated.
- Increase participation in outreach programs.
A lot of talks here at GUADEC are about communication between developers and newbies, technical writers, etc. As a translator I want to point out that it would be great if you remembered about us as well. And by “remember” I mean send a letter to gnome-i18n [at] gnome.org and inform, that the strings are frozen and the deadline, for example:
in two weeks the next version of next-best-thing will be released. This is a great time to update translations.
While most GNOME programs follow the 6 month cycle, the rest of them need to notify us. Many developers already do this (banshee, rhythmbox, gbrainy), but some don’t. The most noticeable example was the release of GIMP 2.8. I waited for years for it, and prepared for the string freeze, and then — out of the blue — it is released!
For those who think that translators should follow Damn Lies, this is not an answer, because:
- not all of the GNOME stuff is there (getting-things-gnome, inkscape);
- there is no point in translating active development branch where the strings come and go;
- it is far easier to translate 100 strings once than 10 strings 10 times.
Disclaimer — I write this as a software user, not a developer.
After the speech “Every detail matter”, I wanted to share some anecdotal experience on quality of software.
When I have to determine quality of software, I don’t have a lot of criteria on which to judge it. List of features and number of crashes plays part in decision, but if basics are covered and it is stable, then how do I choose? A quick list of things, that I believe matter:
- indicator of activities on longer operations;
- polished, consistent UI;
- proper spelling and grammar;
- if translated, translated fully.
Most of these things are covered in HIGs anyway, but my point essentially is — even if software is solid but looks flimsy, it will seem flimsy.
OK, so it is time to report on the progress with the lockdown editor.
During the previous week I did some gnome-control-center poking, and Ryan (desrt) is pushing to extend account services to support mandatory dconf profiles, group management and such things. The discussions of how [if] this should be implemented are still ongoing. I coded a prototype that gives some idea how it would look to an administrator:
In addition to the Standard and Administrator, there are custom account types in system, and choosing “Manage” opens a new application that can create/delete/modify types of accounts.
Meanwhile, I am working on the “Manage” part. After talking to my mentor about the most appropriate language for this, I figured I’d write it in Vala. So far all problems I’ve had with it were solved either by reading documentation, or just by assuming it is very closely modelled to C (well, at least when it comes to functions). Alas, right now I have no pretty screenshots to show — only ugly ones — since I am writing backend functions, but I should have something pretty to show this weekend.
Now that I am back form the final month of studies, which stalled my progress for good 4 weeks, some things in my initial plan has changed. After some consultation with my mentor on how to implement the creation and management of user profiles, it was decided, that I should integrate it into gnome-control-center user management (in account type, to be precise) and form here see, if it is working out. I couldn’t find any g-c-c documentation and comments in code are few and far between, so I have to rely on my investigation skills here, but I think I have figured the system out, so some hard results should be coming soon.
While this sounds rather easy, I found out, that jhbuild on Ubuntu system is an uphill battle, so after a some advice form fellow gnome developer, I installed Fedora 17 on my laptop and will see how it will turn out. Right now I am in step 18 of 94 and have no idea, why some sqlite patch is missing.
This is it for now.