I didn’t get around to blogging about gtkmm 3.8 when I released it last month, partly because we had to fix a crasher bug and do a gtkmm .1 release before people noticed.

Anyway, just a little while after GNOME 3.8 was released, we managed to release gtkmm 3.8 and glibmm 2.36. There is quite a bit of work in these, almost all by José Alburquerque and Kjell Ahlstedt, as well as the usual few days of last-minute work by me to wrap remaining new API.

I spend very little time on glibmm and gtkmm these days, and don’t have much motivation to change that.

There’s also a change that we expect in glib 2.38 that will break many installed applications that use gtkmm. We successfully begged the glib developers to add a special case for us in glib 2.36, but we have not found any way to avoid this for 2.38. So far our best option seems to be to do a new parallel-installed gtkmm (and glibmm) ABI, leaving the old (broken with glib 2.38) one behind, at least allowing applications to be changed slightly and then rebuilt.

Personally, I have no great incentive to go through that pain.

This brings the Maliit Keyboard into the QML/QtQuick2 world for Qt5, removing the use of QGraphicsView which is not really suitable for Qt5. This should also have some performance advantages and makes customization even easier.

Michael Hasselmann blogged a summary of the state of Maliit today. The recent work, along with the Wayland integration, has made Maliit more popular than ever.  But we still need to line up customers to fund the ongoing development, generally while creating custom features or solutions for them.

Our work on the underlying Maliit Framework for Canonical was published upstream as we did it. We believe we’ll be able to upstream more of our Maliit Plugins work in the future.

Versions of these Maliit Plugins commits were published a few days ago in the Ubuntu Phablet project’s maliit-plugins Launchpad/Bazaar repository. It also contains commits (not by us) on maliit-plugins’ Nemo Keyboard, mostly for integration with the Ubuntu Touch platform (and its use of Android’s Surface Flinger). The recent Ubuntu Touch preview is using a version of that Nemo Keyboard, though we believe that’s meant as a temporary solution. A properly integrated Maliit Keyboard should behave significantly better.

Anyway, these commits add these features to the Maliit Keyboard:

• Auto-capitalization.
• Styling, such as a black underline for the current word and a red underline for a word with an error, though its up to the toolkit exactly how it shows this.
• Word prediction, error correction, etc are now available when editing previously-entered words, instead of just the next word, taking into account the surrounding words.
• Users can add words to the dictionary with a long press on the space key.
• More settings to enable/disable auto-capitalization, auto-correction, word prediction, error correction, audio feedback and whether the word ribbon should be disabled in portrait mode.
• Applications can specify text and icons for actions keys, such as Done, Go, Login, etc.
• Keyboard themes can now specify fonts.

The maliit-plugins NEWS file gives more details.

Many of these features were already in the old MeeGo Keyboard (used by the Nokia N9) which had to be dropped last year because of its libmeegotouch dependency and its need for proprietary plugins to achieve these features.

We hope to have all this in an official Maliit release soon.

This is a huge part of American history that gets very little attention in popular culture, despite the wealth of supporting material due to it being such recent history. It’s full of incredible stories of personal courage and adventure. People escaped awful injustices that should not be forgotten. They were often prevented from leaving rural towns in the South, where they were given no choice but to work hard for little pay, at regular risk of violent assault and death. For many, escaping seems to have been almost as hard as for people escaping the Eastern block during the Soviet era. But, unlike defectors, their escapes were not celebrated in the US.

What’s really forgotten is how hard it was for people to settle once they escaped. They had more opportunities but these were still limited and blacks were initially prevented from living in some neighborhoods or taking many jobs. This is yet another dramatic chapter to peoples’ stories.

New distinctive communities were founded, and they should be celebrated by telling the stories of the people who built them. When I was in New York City over the summer, I found some time to visit Harlem at short notice with my young son. We walked around to get a feel for the place, and tried to join a Harlem Heritage Tour, but none were happening that day. It’s a small organization that I’d love to try again, but I cannot understand why no business has funded a massive tourist destination in Harlem that could be one of the big attractions on the New York CIty Pass along with the Empire State Building, Ellis Island, the Museum of Natural History, etc.

Now to try rolling a gtkmm tarball.

As with regular Glom, most of the work was getting the self-hosting tests to work with MySQL – to start the MySQL instances, create the databases, fill them with data, test them and shut them down. The rest of the support was mostly covered already by JOOQ but I had to make sure it always knew what SQL dialect to use.

We’ve massively improved Rygel’s (C) API documentation, which was rather bare after Rygel’s initial split into shared libraries. We had to investigate how the current plugins use the API, and sometimes improved the API in response. (The very latest API documentation improvements will be online soon, when we do a new Rygel release.)

We’ve added both simple and real-world examples, linking to them from sections in the API documentation and describing how those examples work. Those real-world examples are standalone GStreamer-0.10-based versions of the regular Rygel media engine and of its media-export server plugins, plus a GStreamer-0.10 version of the standalone renderer example.The original code for these (now using GStreamer-1.0) was in Vala, like the rest of Rygel, so we had to convert them to C. To maintain functionality, we chose to clean up the horribly-obfuscated C code generated by Vala. That took us a few frustrating weeks to finish but we got it done.

The new Rygel Integration page provides an overview of the APIs that platforms should find interesting, linking to the various documents that we’ve created during this effort. That Integration page is part of a complete overhaul of Rygel’s wiki project pages to make them more attractive and useful.

To help with maintenance of Rygel itself, we now have a Rygel Architecture page with descriptions of Rygel’s program flow in various situations, and a Rygel architecture diagram showing how the various parts of Rygel work together.

My aims were to have:

• Official email accounts, without the bother of managing our own email server. (Google Mail)
• Mailing lists (or groups) so we can send mail to one parents@ email address instead of copy/pasting long CC lists.
• An online calendar that we could use to show official events, which could show up on peoples’ iPhones and Android phones. (Google Calendar)
• A shared space for official documents. (Google Drive)
• Private photo galleries. They can’t be public because people don’t like pictures of their children being online. (Google’s PicasaWeb, I hoped)

I was really looking forward to playing with this stuff, hoping that it would quickly do useful things, and hoping that it would be easier for non-technical people to administer when I’m not around. But I’ve been rather disappointed.

The various problems lead to me having to choose between two options, both of them inadequate:

Option 1: Domain users

In this scenario, I would add someone@ourdomain.com accounts for all of the parents.

Pros:

1. We would be able to see all contact details for parents and teachers in the “Directory”. That would be available on peoples’ Android phones, too, and maybe on iPhones.
2. We could use PicasaWeb to share photos and view them as galleries.
3. System administration would generally be easier. The simplicity makes
   it easier to avoid sharing something publicly by accident.

Cons:

1. We would give everyone an @ourdomain.com Google account. That would give them a @ourdomain.com email address, using GMail, which would be useless to them. Parents would each have to manually set up GMail to forward to their personal email address, though I could tell them how to do that.
   (You could send email to some.parent@ourdomain.com, but when they replied, you would see them replying from their some.parent@hotmailorsomething.com email address.)
2. If parents already have a Google account, they would need to switch between them in the web browser. That’s fairly easy using Google’s multiple sign-in, but that does not work well right now. Sometimes you’ll find yourself using the other account suddenly.
   It’s a particular problem for Google Apps that don’t support multiple-sign in, but real people do use those apps. For instance:
   • If you click on a link to a PicasaWeb album, you’ll just be told that the album doesn’t exist, until you log out, log in as the other user, and try again. That is beyond the abilities of the typical user.
   • Google Checkout, used when buying from Google Play, will offer a choice of users to log in as, but I’ve regularly seen it ignore your choice and continue as the wrong user.
   • When going to the GMail site, if you are logged in as a user with no gmail email address, it will offer to create one for you with a “Add Gmail to your Google Account” page. If you try to switch users to the user with a GMail account, it will just take you back to the same page for the previous user.

Option 2: Non-domain group members

In this scenario, I would not add someone@ourdomain.com accounts for all of the parents.

Instead I would add their regular email addresses as members of groups such as parents@ourdomain.com. The various Google Apps seem to allow sharing to group email addresses, understanding that that means sharing to the group’s members, though that’s not documented or hinted at.

The parents would have to create Google accounts for these non-Google email addresses, which is still possible via this link to create a Google account without being forced to have a Google email account, though that link might not work in future. (Update from 2013/04: Indeed, it doesn’t work now, so you have to disable the gmail email address after creating the Google account.)

Pros:

• People could use their existing Google accounts and existing email addresses.

Cons:

• We could not use Google’s contacts system to share a list of contacts. We’d have to maintain a separate list on a web page. It wouldn’t be available in the normal way on an Android or iPhone phone.
  This just isn’t possible with Google Apps unless all the people have domain accounts, with domain email addresses. Google recommend the use of 3rd-party web applications that let you manually sync address books every now and then, but that’s not good enough.
• We could not use PicasaWeb to share photos. We could use Google Drive
  instead, but this doesn’t offer a gallery view showing sets of photos
  with back/forward, etc.
  This is because PicasaWeb does not support sharing to a Google Apps group. You can only share to users in your domain, or you can share via an obfuscated, but public, URL.

Summary

For now, I find that Google’s multiple sign in is so awful that I cannot risk asking people to deal with it and cannot risk having to support them with it. Therefore, I have to live with sharing photos via Google Drive instead of PicasaWeb, and having no shared contacts list.

I feel that we wouldn’t have this problem if Google Apps really supported domains rather than just using redirects. For instance, I’d like to use email at mail.ourdomain.com, instead of typing that into my browser’s address bar only to be taken to mail.google.com/mail/u/0/?shva=1#inbox . A real domain would have its own users and there would be no conflict with regular Google users. Obviously that would be harder for Google to do.

Things would also be simpler if PicasaWeb supported multiple-sign in, and if it supported sharing to groups. Or if Google Drive allowed image files to be viewed via PicasaWeb. It’s to be expected that educational institutions will want to share photos privately. I wanted to use that as an attractive way to get people into the system.

It should also be expected that educational institutions, like many organizations, want to deal with people who will never have an official email address for that organization.

It took several tries to finish The Quantum Universe, partly because I had to go back over several of the earlier explanations before moving forward. I’m a big fan of Brian Cox’s TV shows, but not so much a fan of the co-author’s Jeff Forshaw’s articles in the Guardian, though I find most popular science journalism rather insubstantial.

In the end, I had to accept that several explanations in the book just weren’t good enough. It seems to have been rushed, probably to capitalize on Brian Cox’s current fame, without anybody taking the time to check that all the text actually makes sense. It must be hard to find editors who are brave enough to say when they don’t understand.

It also got unnecessarily hand-wavy at times. And I didn’t like how on the one hand it rightly discussed observed experimental behavior of the quantum world as being predictable via the maths, but then went on to describe that maths as being a mechanism that causes other effects rather than just being consistent with the observed effects. That feels like anthropomorphizing the maths, before we’ve really figured out if we have the most general model to think about things. I’m thinking particularly of the epilogue about how Pauli’s Exclusion Principle explains how electrons limit the mass of white dwarf starts. Maybe I’d find it more justified if there was some proper explanation of the exclusion principle, assuming there is one, but the book skips over that.

Like many people, I found the clocks analogy to be a distraction. I’d rather just see the maths used to explain probability waves and their wave interference. Plenty of people are afraid of maths, but the clocks explanation mostly just gives the false impression of understanding, while annoying people who are comfortable with a little calculus. Without the equations, I don’t feel like I’m on solid ground.

Reading it on the Kindle wasn’t particularly pleasant, because I had to flick backwards and forwards between the text and the diagrams. But as far as I can tell, the real book is not laid out much better. Again, I guess the book would have a more approachable layout if it wasn’t rushed.

As you can tell, I’m not qualified to judge this book properly. That’s because I am the target audience. I still feel a lack of understanding of quantum and particle physics that bothers me deep down. I hope to find the time to read Ramamurti Shankar’s Principles of Quantum Mechanics instead, to solve the problem properly. I’ve already enjoyed some of his Fundamentals of Physics lecture videos that Yale have made available online.

So I fixed that, I think, learning some things about Java Servlet sessions along the way. This text is mostly for my own reference, and so that people can tell me how wrong I am, because I’d like to know about that.

In the server-side code

Java servlets already set a JSESSIONID cookie in the browser, but you shouldn’t try to use that cookie to maintain a login across browser sessions. Instead, I now set and get a custom Cookie, in the server code, using javax.servlet.http.Cookie. HttpSession.getId() conveniently provides a unique-enough session ID for me to use in the Cookie. This page about Cookies with GWT seems to suggest setting the cookie in the client-side JavaScript code, using com.google.gwt.user.client.Cookies, but that sounds rather wrong.

I now store the username and password (Yes, that’s not good, so keep reading), associated with the session ID, in a structure that’s associated with the ServletContext, via the javax.servlet.ServletContext.setAttribute() method. I get the ServletContext via the ServletConfig.getServletContext() method. I believe that this single instance is available to the entire web “app”, and it seems to work across my various servlets. For instance, if I login to view a regular page, the images servlet can also then provide images to show in the page. I’d really like to know if this is not the right thing to do.

However, it still stores your PostgreSQL username and password in memory, so it can use it again if you have the cookie from your last successful login. It does not store the password on disk, but that is still not good, because it could presumably still allow someone to steal all the passwords after a breakin, which would then endanger users who use the same password on other website. I cannot easily avoid this because it’s the PostgreSQL username and password that I’m using for login. PostgreSQL does store a hash rather than the plaintext password, but still requires the plaintext password to be supplied to it. I think I’ll have to generate PostgreSQL passwords and hide them behind a separate login username/password. Those passwords will still be stored in plaintext, but we won’t be storing the password entered by the user. I’d like to make this generic enough that I can use other authentication systems, such as Google’s for App Engine.

To avoid session hijacking, I made the cookie “secure”, meaning that it may only be provided via a secure protocol, such as HTTP. I believe this also means that client (javascript) code is not allowed to read it, so it can only be read by the server via HTTP(S). I did that with the javax.servlet.http.Cookie.setSecure() method, though I had to make a build change to make that available.

The login servlet now checks that it has been called via HTTPS, by using the ServletRequest.isSecure() method, and uses HTTPS when testing via mvn gwt:run. It refuses to do any authentication if HTTPS was not used, logging an error on the server.

In the client side code

I added a check for what protocol is used. If it’s not https then I warn that login cannot work. This does not add any security, but it’s a helpful hint.

Actually, the entire site must therefore be served via HTTPS, not just the login page, or we would violate the Same Origin Policy by mixing protocols, which the browser would rightfully complain about. At this point I noticed that most serious sites with logins now use HTTPS for their entire site. For instance, Google, Amazon, Facebook. This seems like a good simple rule, though I wonder if many projects don’t enforce it just to make debugging easier.

I also converted the popup login dialog into a proper login page, making sure that it takes the user to the desired page afterwards.