Glom 1.6 bug fixes

We didn’t do a new major version of Glom recently, though we usually follow the GNOME schedule, because some of the new features are not quite ready, such as the drag-and-drop layout, and the new printout designer.

But this does mean that we have a chance to get a bug-fixed version of Glom’s stable version into Ubuntu’s stable version, for the first time. I’ve had some success with that, thanks to Chris Brotherton. It can still take a long time (10 days last time, though it felt like longer), and the longer it takes the more chance there is that a change in some other package can be a reason to wait. But I have a feeling that things are getting easier.

Of course, the more usable Glom is in Ubuntu, the more bug reports we can get. Many thanks to Jani Monoses and Pavel Mlčoch for keeping me busy, particularly for discovering the problems with changed behaviour in PostgreSQL 8.3, which we discovered late because PostgreSQL 8.3 only just started working for some people recently. These bugfixes mean yet more tarball releases for Ubuntu to package, and there’s always the risk that they will stop taking new versions as they really hit their freeze. Hopefully, they’ll manage to do just one more update because Jani found some more critical bugs.

After Ubuntu Hardy is released then our upstream bug fixes will probably never get into Ubuntu Hardy unless we can claim that they are security problems, as is still the problem with Glom in Ubuntu Gutsy. At FOSSCamp in Prague in May I’m apparently meant to be leading some discussion about how to get stable updates into stable distros. I have some ideas about who a distro (and its users) should trust, and about what is currently just providing a false sense of security at the cost of user experience. I don’t know what to expect from FOSSCamp so it might not have any effect. I didn’t see the point in flying to the last FOSSCamp in Boston for one day just for some seemingly aimless meeting and talking, but Prague is not far away by train, so it’s worth a look.

Just-Works IR Remote Controls on Ubuntu

gnome-lirc-properties GUI is now in Ubuntu Hardy, after much effort.

We had a variety of remote controls for testing, so we could at least guarantee that it worked for a certain list. Here are our results. The ones that worked perfectly were recognized by gnome-lirc-properties’ auto-detection button and their keys were immediately recognized in the preview area.

  • Streamzap PC Remote Control (IR receiver and remote control): Worked perfectly.
  • SnapStream Firefly PC Remote (IR receiver and remote control): Worked perfectly.
  • Sound Blaster Remote Control Upgrade – White Box (Has its own IR receiver): Worked perfectly.
  • Pinnacle Remote Kit (IR receiver and control): lirc has no driver for this, and no patch has been submitted to lirc by anyone that can confirm that it works.
  • Xbox 360 Universal Media Remote. (Just a remote, though the XBox has a built-in IR receiver): This didn’t work with any of the other IR receivers, but it presumably works with an actual XBox running Ubuntu. We’d love to hear from people running Ubuntu Hardy on an XBox. Does the auto-detection in our GUI work?

We also tried two other replacement remote controls that have no IR receiver of their own. They work with the other IR receivers – you can use the key learning feature in our GUI to configure them.:

  • Sony RM-V202 4-Device Universal Remote Commander.
  • One For All “Universal Replacement Remote” URC4110.

IMG_3153

So I’m adding one of these to my Ubuntu Hardware page, because it just works.

Webcams that just work with Ubuntu Linux

The GNOME Foundation Board asked me to buy a webcam for the GNOME Events Box, so we could show Cheese on our stands. This could be cool together with the box’s new projector. I also wanted a webcam for my own use so Liam’s grandparents can see him in motion more often. So this was an opportunity to discover if any two available webcams really “just work” with Ubuntu, after doing some research and guessing. The results were great.

I bought a Logitech QuickCam Pro 9000 and a Creative Live! Cam Optia AF, both 2 Megapixel webcams. The video for both “just work”ed perfectly in Ekiga, Cheese, and Skype, on Ubuntu Linux Gutsy (7.10) and Hardy (8.04, currently in beta), though all these programs require you to choose the video input from a list, regardless of how well the webcam works. The Logitech one has a built-in microphone without an extra cable. The Creative one has a separate cheapish in-ear headphone+microphone headset for the regular 3.5mm “minijack” socket.

IMG_3337

I recommend the Logitech because it has a convenient built-in USB microphone that avoids non-USB microphone hell, though you’ll obviously then need speakers for the output. I added it to my Ubuntu Hardware. That page has almost paid for the costs of the USB Wi-Fi sticks that I bought to discover one that worked. Maybe it will pay for my webcam too. What other hardware should I use that page for, to discover just one model that really “just works”? As I’ve said before, I think the hardware lists on the Ubuntu wiki are mostly useless for real users because nobody is insisting that “just works” really means “just works”, and nobody is flagging the ones that really do just work.

It was nice to see that these products have dire warnings about not attaching them to your Windows PC before installing the special software, and to see that Amazon has lots of comments about how people couldn’t get them working with Windows.

Getting my microphone to work

A couple of years ago the microphone on my headset (regular, not USB) stopped working. I had used it with Skype briefly. I guessed it was a problem with the headset. A while ago I bought a new headset, and that microphone didn’t work either. Then I knew that it was a software problem with Ubuntu/Linux. I have two new headsets now so I am really really sure.

Today, I was trying to get either Skype or Ekiga working between two computers on my local network, and I still can’t fix it. The laptop is using a USB microphone built in to a webcam, and that works fine. But I can’t get the headset to work with my desktop PC. Here are some screenshot to express my frustration.

System-wide Sound Preferences

The Sound Preferences control panel forces me to choose from a huge list of meaningless device names, none of which work. Here are the basic settings (in Ubuntu Hardy, but this hasn’t worked in Gutsy or Feisty, at least). The test button doesn’t echo any sound to me with any of the choices. Some of the choices show a dialog with a gstreamer pipeline error, which then hangs the control panel.

Sound Preferences

And here are the volume preferences (strangely only available from the panel applet), to show that the microphone is not muted:

Volume Preferences

Also, the Sound Recorder application refuses to start, saying “Your audio capture settings are invalid. Please correct them in the Multimedia settings.”, whatever device I choose in the Sound Preferences. Strangely, Jokosher’s wave graph shows that some input is being received when I speak, but I don’t hear anything when I play it back. It’s nice that Jokosher has no microphone preferences of its own, by the way.

Update: Juerg Billeter pointed out that there’s also a preferences window in the Volume Control, via the Edit menu. It has some obscure check boxes that I can select. None of them seem to help. So now there are yet more things that I can break while looking for the one thing that I need to change to fix the problem, so that one thing probably won’t fix the problem anymore when I find it.

Volume Control Preferences

Application-Specific Sound Preferences

Ekiga asks me to choose one of these devices:

Ekiga Sound Preferences

Skype asks me to choose from this huge list:

Skype Sound Preferences

And what’s with those “default” device choices in both the sound input and output? Neither actually work, though both are offered (and sometimes, but not always, chosen by default) by applications such as Ekiga.

glibmm 2.16.0

With the release of GNOME 2.22 we finally made an API/ABI stable release of glibmm with the new giomm API. We went way past the GNOME API freeze date, which was scary and unwise, so there are sure to be some undiscovered problems. But we are quite sure that any remaining problems would be things that we could fix by deprecation+addition.

There are some giomm examples in the gtkmm-documentation module and the giomm API reference is not too bad. For instance, see Gio::File. Hopefully I will find the time to write a chapter on giomm for the gtkmm book.

Thanks again to Marko Anastasov who did all the initial wrapping work and to Jonathan Jongsma and José Alburquerque. Jonathan Jongsma is now officially a co-maintainer of glibmm. I’ve pesuaded him to do tarball releases after glibmm 2.16.0. Now I must persuade Marko to become a co-maintainer of something.

To the GTK+ HackFest in Berlin

Early tomorrow I’ll take a train to Berlin for the GTK+ HackFest. I’ll arrive at 14:07 at the Hauptbahnhof [1] and wait for Behdad to arrive a few minutes later, if the trains are on time. Unfortunately, I’ll miss most people because I’m leaving the next evening. But I can only be away for one day and it seems I can be most useful as a German speaker helping to get things set up.

I wouldn’t be that useful later anyway. I don’t really do communal coding. For one thing, it doesn’t work when other people try to show me something quickly and see that I don’t use either emacs or vi on my laptop. I can’t imagine using them and I believe this may be due to some fundamentally different structure in my brain.

I am quite looking forward to the six hour train ride to Berlin. When I regularly did the Munich-Berlin commute it was great for solving bugs that had stacked up and needed some dedicated concentration.

Someone asked me today if I’m a native English speaker. Yes, I am. Ask a German.

[1] I can’t get used to calling it the Haupbahnhof. It’s the Lehrter Bahnhof even if it now looks like a giant ant farm.

Two Months and Smiling

Liam is just over two months old now. He’s a little more aware of the world, though not really interacting with it much yet. He started to smile properly a week ago, and every day he makes slightly different vowel sounds. After two months of sleeping, eating and crying, the first wide smile makes a big emotional impact.

He’s now nearly 5 Kg, almost double his birth weight, and my back knows it.

liam_weighing_cropped_small.jpg

Sigi and I take turns so we can get other things done. I have the midnight to 4am shift, when I give him the bottle, and 10am to 12pm. I generally get work done between 12:00 noon and 18:00, and sometimes in that midnight to 4am shift. He’s quite an easy baby, I think, but we are very lucky that there are two of us who can give him lots of time. It would be nice if he didn’t need to sleep in my arms quite so much.

I have decided to avoid taking on much new work before June, so we can keep this daily routine for a while more. I’ll also look for a small office in the neighbourhood – The Glockenbachviertel in Munich, in case anyone has a suggestion. But there is work to do so I’m still trying to hire new people.

Clutter Tutorial done for now

Now that Clutter 0.6 is out, I found the time to finish the planned sections for the Clutter tutorial that I mentioned in December, for Openismus. Here is the html version and a PDF, though of course the PDF doesn’t have the nice links into the API reference documentation and the links to the actual files of the examples.

The guys at OpenedHand haven’t had time to review this yet, so be aware that there could be significant errors. But I think it’s mostly accurate, useful, and unique, though the appendices and full example are obviously lacking. I’ll try to keep it up to date and correct as I get feedback.

Having done all this investigation into Clutter, I have formed some opinions:

  • Clutter is a nice way to move semi-3D things around on the screen to create “innovative” user interfaces. Its abstractions for actors and behaviours really give you something to work with compared to using OpenGL directly. But it’s still hard to create natural-feeling responsive applications and I don’t know exactly what’s lacking. It feels like there is a disconnect between the act of coding and the very dynamic UIs that the code creates. I sometimes feel I’d like to just put actors on a rail, twist that rail about, connect some actors together with struts or springs, start them moving, let the user push and pull them around within constraints, and trigger extra behaviour when they reach certain positions, or reach each other.
  • Clutter is now a very basic API. You will need to implement a lot of simple functionality to create applications that act as today’s users expect. The Tidy “reference-implementation” example toolkit thing is not a shared library – it’s meant as an inspiration for you to do all this yourself, and it is itself not very complete. I don’t think that is a wise strategy, though rampant bad reimplementation is the standard in today’s mobile/embedded development projects.
  • Neither you or Clutter should want to reimplement the huge amount of UI logic that is, for instance, in GTK+. Without reusing all that work, Clutter applications will generally have inconsistent or inadequate text editing, scrolling, focus, keyboard accessibility, right-to-left language support, etc. Applications will share little common API so it won’t be easy to throw new developers at your project. Somehow we need a way to use some GTK+ widgets in Clutter without them looking and feeling like they are visitors from an extra dimension.

These problems could probably be solved by lots of hard work by smart people. I don’t know what the near-future strategy for Clutter is, so I don’t know if the current state is intentional or if anything particular is planned. It’s certainly getting better all the time.

gnome-lirc-properties: Using PolicyKit to get sudo access

Can’t get PolicyKit’s ObtainAuthorization() to work.

gnome-lirc-properties, which I just mentioned needs to edit /etc/lirc/lircd.conf, which requires sudo/root access. Various APIs exist to get temporary sudo/root access but everyone now seems to agree that the new PolicyKit system is the way to go. I’d like to link to a website for it. All the system administration control panels in Ubuntu Hardy Heron seem to use PolicyKit already.

But I can’t get the thing to work, maybe because I’m using Python, and I haven’t found any help so far. I have defined the PolicyKit mechanism, but I can’t get even a simple test of the ObtainAuthorization() method to do anything interesting. This python code does not return anything other than None from ObtainAuthorization() and none of the callbacks are called:

#!/usr/bin/python

import pygtk
pygtk.require('2.0')
import gtk

import dbus
import os

class TestWindow:
    def on_button_clicked(self, widget, data=None):

	#Call the D-Bus method to request PolicyKit authorization:

        session_bus = dbus.SessionBus()
        policykit = session_bus.get_object('org.freedesktop.PolicyKit.AuthenticationAgent', '/', "org.gnome.PolicyKit.AuthorizationManager.SingleInstance")
        if(policykit == None):
           print("Error: Could not get PolicyKit D-Bus Interface\n")

        gdkwindow = self.window.window
        xid = gdkwindow.xid

        print "Calling ObtainAuthorization..."

        #This complains that no ObtainAuthorization(ssi) exists:
        #granted = policykit.ObtainAuthorization("test_action_id", xid, os.getpid())

        #TODO: Neither of the async callbacks are called, and how could the return value be useful if it is async?
        # Note: Other code (such as gnome-panel) seems to use ShowDialog instead of ObtainAuthorization, though
        # ShowDialog is apparently deprecated (I don't know when), but that also has no effect.
        granted = policykit.ObtainAuthorization("test_action_id", xid, os.getpid(), reply_handler=self.__handleAuthReply, error_handler=self.__handleAuthError)

        print "...Finished."

        print "granted=", granted

    def __handleAuthReply(self, granted):
        print "handleAuthReply: granted\n"

    def __handleAuthError(self, exception):
        print "handleAuthError: not granted: %s\n" % exception

    def on_delete_event(self, widget, event, data=None):
        # Close the window:
        return False

    def on_destroy(self, widget, data=None):
        gtk.main_quit()

    def show(self):
       self.window.show()

    def __init__(self):

        self.window = gtk.Window(gtk.WINDOW_TOPLEVEL)
        self.window.connect("delete_event", self.on_delete_event)
        self.window.connect("destroy", self.on_destroy)

        self.button = gtk.Button("Obtain Authorization")
        self.button.connect("clicked", self.on_button_clicked, None)
        self.window.add(self.button)
        self.button.show()

window = TestWindow()
window.show()
gtk.main()

gnome-lirc-properties has a real mechanism and tries to use ObtainAuthorization() for real, if someone wants to look at it properly. Here is the gnome-lirc-properties svn, and a tarball (it doesn’t do much yet).

How to use PolicyKit from an application

In return for asking the lazy web, I’ll try to describe how I think it should work, based mostly on David Zeuthen’s description. There are many opportunities to get something wrong:

  • You install a D-Bus service (a PolicyKit “mechanism”) that does the thing that needs sudo access. PolicyKit will control access to this mechanism. For instance, the Clock applet’s mechanism has a SetTimeZone method. gnome-lirc-properties uses the Python D-Bus bindings to implement its mechanism. I know that our WriteConfigFile() method is far too generic, but we will improve it when we get this working.
  • Update:: And this mechanism’s implementation should ask PolicyKit if it has authorization, and return an error if it doesn’t. Thanks mclasen. I’ll try to find out how to do this. Update: You can do this via the PolicyKit (on the session bus) object’s IsProcessAuthorized() method, now used in the gnome-lirc-properties PolicyKit mechanism.
  • As with other D-Bus services, you install a .service file, so that D-Bus activation can start it on demand. PolicyKit mechanisms use the System bus rather than the Session bus, so you install it in $(datadir)/dbus-1/system-services (/usr/share/dbus-1/system-services on Ubuntu). Here is the .service file for gnome-lirc-properties.
  • As with other D-Bus services, you install a .conf file, saying who can use the service. This is installed in $(sysconfdir)/dbus-1/system.d (/etc/dbus-1/system.d/ on Ubuntu). This is the .conf file for gnome-lirc-properties
  • A .policy file tells PolicyKit who should be allowed to use the mechanism. You install this in $(datadir)/PolicyKit/policy (/usr/share/PolicyKit on Ubuntu). Here is the .policy file for gnome-lirc-properties. I believe this allows system administrators to configure access to these features via these .policy files, and I believe that is the whole point of this D-Bus “mechanism” abstraction.
  • Applications that want to use this mechanism call the ObtainAuthorization() method on the “org.freedesktop.PolicyKit.AuthenticationAgent” D-Bus service, passing the action ID that is mentioned in the .policy file. If necessary, PolicyKit asks for a password (or whatever) for authentication, and presumably then gives the application the appropriate rights. The dialog uses (translatable) text from the .policy file, so it’s very specific to your application. Many applications still seem to be using the ShowDialog() method instead, but that has been deprecated.