IM, Contacts and Social Hackfest, the sponsors

Many thanks to Intel, Red Hat, and the GNOME Foundation for sponsoring participants at the hackfest, and heaps of thanks to Collabora who are contributing a lot of participants to this hackfest, their offices, their coffee machine, and getting us pizza and Nutella dough balls yesterday. Num Num!

IM, Contacts and Social Hackfest, day one

In Cambridge (the proper one, in Cambridgeshire), at the Collabora offices, for the first day of our IM, Contacts and Social Hackfest.

Today, we:

• discussed end-user problems with Telepathy and Empathy's gnome-shell integration (and started the specifications necessary to fixing some of those bugs) (everyone for the problems listing, Danni and Guillaume for the start of bug fixing)
• started working on integrating gnome-keyring dialogues into the Shell (Stef Walter)
• fixed libfolks bugs (Philip), and discussed a potential problem API problem in the folks to evolution-data-server synchronisation code (which will be used in the Contacts API) (Travis, Raul, Bastien)
• packaged up gnome-online-accounts for Fedora (Bastien)
• worked on better high-level tp-glib support for file transfers (Morten)
• HMAC support in glib (Stef Walter)

Tomorrow we'll have Rob Bradford joining us, and probably start talking about GNOME Online Accounts integration with libsocialweb, as a way to kickstart its use all across the desktop.

Small tablet improvements

I recently added two new plugins to gnome-settings-daemon, which should make life a little bit better on tablet computers, such as the WeTab/ExoPC that most MeeGo developers seem to have lying around.

The first plugin is the orientation plugin, which will read the orientation from udev (which itself reads it from the accelerometer), and rotate the display and the input touchscreen as appropriate.

The second plugin is the cursor plugin, which will simply hide the mouse cursor when you don't have a mouse attached to a computer with a touchscreen.

Related to those are two gnome-shell bugs. Related to orientation is this bug about providing smoother XRandR transitions in gnome-shell, and related to cursor is a way to show activity in the shell panel when a busy cursor would be shown.

No screenshots, because a vertical desktop with no cursor isn't that interesting.

If you're interested in testing out this on a WeTab, you'll need the accelerometer driver in the kernel, udev git (or udev 172 when it's released) and gnome-settings-daemon master.

And if you want support for another tablet device, check out this discussion on the linux-input list, and drop me a mail if you need more guidance.

Get your hot (beta) GNOME 3 distro!

Want a distro with all the best gizmos? systemd, with learning read-ahead for faster boot? GNOME 3 getting out of your way so you can do work? And much more.

Get Fedora 15 Beta now!

Want to debug an old status icon applet?

If you want to debug an "old" status icon when running the GNOME Shell, and it duplicates functionality from a icon in the shell itself (say Bluetooth or Sound volume, in my cases), there's two tricks available.

The shell looks at the WMNAME for the applet when choosing to hide it, or show it.

• For most applets, gtk_status_icon_set_name() isn't called, we just need to change the binary name. Create a symbolic link to your binary with a different name (say, "test-applet"), and launch your application from that.
• If the applet calls gtk_status_icon_set_name(), just name it differently. Unfortunately, that will require recompilation.

With those tricks, I fixed the volume status icon for the fallback mode, and helped Frédéric Crozat pin-point a (likely) bug in the Bluetooth menu in the shell, as we could not reproduce the bug with the fallback status icon.

Totem in GNOME 3.0, plans for 3.2

Totem for GNOME 3 is available in the GNOME FTP servers. And now onto GNOME 3.2.

There's a couple of major UI changes planned for Totem 3.2, with designs from the GNOME Design team (and Hylke in particular). These include the removal of the status bar, better fullscreen controls, more contrast when playing movies, etc.

New colours

The changes for contrast are already in Totem itself, and you can grab a 3.2 version of gnome-themes-standard to see the "dark" variant of Totem (or enjoy the screenshot below).

Black Swan, go see it.

New video widget

For the rest of the changes, we needed a video widget that was more flexible than the X-based one we were using. So from Totem 3.2, we'll start using clutter, and clutter-gst.

This means that we'll be able to implement things like OSDs for more than just the fullscreen version, use an indicator in the video directly when buffering for live streams instead of the status bar. It would also allow other useful features, like rotating videos with animations, to preview movies from your phone or camera in landscape mode.

Performance-wise, if you were already using an OpenGL-accelerated desktop, the difference should be minimal, comparing clutter-gst's video sink to an Xv overlay using OpenGL, the major difference being the addition of the videobalance element to the pipeline.

If you don't have OpenGL drivers for your machine, Totem 3.0 will still be maintained, with important bug fixes being backported.

Misc changes

We expect a Grilo plugin making its appearance, which will allow us to focus our bug fixing on the interface parts, rather than having to maintain the code to access various video resources.

We also made changes to the nautilus properties tab, which should make it faster, using Edward's GstDiscoverer.

Colophon

You can start testing the clutter-based Totem, the dark variant, and the faster nautilus properties right now, in the master branch of Totem in GNOME git.

GNOME 3 Test Day

On Wednesday evening, Fedora Desktop hackers were frantically building GNOME 2.91.6 into rawhide, including a number of rebuilds against newer versions of GTK+, and beta testing Live CD images to make sure they were usable.

On Thursday morning (European time), ISO images were being uploaded by the our favourite QA insomniac. Quite a few people came to test the Live CD, and many bugs were filed.

There were plenty of questions about GNOME Shell itself, and some about the design decisions. So if you did try out one of the many GNOME 3 live CDs, and asked yourself the following questions, we'll try and provide some answers.

Q: The dash is broken, I can't add more than 13 favourites to it!?

A: It's known problem, which also fits into the dash resizing when you drag'n'drop new items to it.

Q: I can't read the full name of certain applications when searching for them in overview mode. Can I haz tooltips?

A: Tooltips, maybe not, but a solution is being worked on. Follow the discussion in this bug.

Q: I can't change my font size, really?

A: You can change it for the applications, in the Universal Access settings. For the shell, it's currently not possible, but it will get fixed.

Q: I don't like how hard it is to create workspaces. Is this the final design?

A: It's not. Owen has been working on implementing Jakub's video mockups. See this bug for all the links.

Q: I use 2 monitors, and GNOME Shell is very difficult to use. Is it going to get fixed in time?

A: Hopefully yes. There are two bugs you can monitor. One is about a bug when using two monitors (or at least, more prominent when using two monitors), the other about the plans for even better multi-screen support.

Q: How do I restart my computer?

A: Type "reboot" in a terminal? Unfortunate, but how to present it needs a bit of design work. Just adding another menu item in the system menu just muddles it.

Q: This is way slick. But the NetworkManager applet looks really out-of-place. Can you make it look cool?

A: Yes! System status legend Giovanni is on the case.

Q: My machine can't run GNOME Shell. What about the fallback mode?

A: It looks pretty sad at the moment. There's plenty of room for improvements here. Feel free to jump in if you want to help those not fortunate enough to be able to run GNOME Shell.

Also notable is the fact that plenty of bugs were filed, and quite a few fixed, that we are exercising the graphics drivers and finding bugs, and that despite some complaints (some of them constructive, but not always), GNOME 3 is looking better and even more usable than GNOME 2 by the day.

PS: We even had KDE make GNOME crash. Or close enough.

infra-red remotes in GNOME 3

gnome-lirc-properties has served its purpose. It will probably carry on working on GNOME 3 desktops, but you won't be happy when it drags in GTK+ 2.x Python bindings, HAL or doesn't integrate into the new control-center.

But things have changed since gnome-lirc-properties was first written, and the way to handle IR remotes has changed as well:

• A large majority of receivers are now supported in the kernel using rc-core (né ir-core).
• Some receivers aren't supported (iguanaIR amongst others), and some need porting from pure input drivers to rc-core. Some functionality for the ATI Remote Wonder remotes is also not supported by the new drivers. If you're interested in working on this, drop a mail to the LIRC list.
• Mauro Chehab is making progress at propagating the key events from the kernel up to the stack to X11 applications. There's some patches in that direction on the Red Hat Bugzilla.

This means that:

• Event delivery would still need a broker in the session, to get to unfocused applications. gnome-settings-daemon can step in that role (and step out of the way when the application is focused, so the app can bring context dependent behaviour). gnome-settings-daemon already handle some of the more common multimedia keys in its media-keys plugin.
• The only configuration one would need to do is selecting the type of remote for the receiver, eventually tweaking the keymap for that remote.

So to write a replacement for gnome-lirc-properties that would fit into GNOME 3, one would need:

• A way to enumerate receivers on the machine
• A way to change the remote configuration (changing the keymap) for that receiver
• Eventually a way to tweak the keymap

This could all be handled through a D-Bus version of ir-keytable. If Mauro's patches reach X.org mainstream, then a kernel/GNOME summer of code project could be had for this work. Best to start writing some kernel patches, or laying some code if you want to get a headstart.

PS: For completeness' sake, there are also "pure" input devices that are remotes that wouldn't be handled through this. Those would need to be blacklisted in the input layer, and handled through rc-core instead.

And for something different now

Because it looks better in fullscreen, with acceleration, and you can save it if you want to keep it. Totem now with a "Save Copy..." menu item, and a playlist parser that knows about video websites.

The ever present Xan is demo man.

You'll need quvi (for its library) and the master of totem-pl-parser (that should even work with older versions of Totem) for the video website support. The "Save" menu item lives in Totem master, scheduled for GNOME 3.

New gnome-phone-manager maintainer

Seeing as I haven't given gnome-phone-manager enough love lately, Daniele Forsi, of gnokii fame, is stepping up as the new maintainer for it. Bug fixes coming your way very soon!

I'll still be handling the packaging of gnome-phone-manager in Fedora.

House arrest, or just document sharing

Yesterday and today, I wrote a chunky patch for gvfs to allow it to use the "house arrest" protocol for iOS devices. This is the protocol is rather more well-known as "iTunes documents sharing".

You can see a tedious example of how you can use it in this Apple KB.

For GNOME, we did it slightly differently, and you don't need to use your music manager as a file manager for your non-music device. Plug the device in, and all the apps that support file sharing will be showing up in a "Applications on Foo" device, on your desktop.

Managing files with a file manager, what a brilliant idea.

Fedora 14 is out!

With the latest GNOME 2.32, go get it!

The new control-center and you

URI scheme handlers

In the past, handlers for specific URI schemes lived in GConf. This caused multiple problems:

• it would cause problems when 2 applications tried to lay claim to the same URI schemes (say both Banshee and Rhythmbox wanted to handle the "itpc" scheme), because GConf would expect only one schema (thus one application) to handle a particular key.
• when the key was set, by the preferred applications for example, the key would lack important information to make things like startup notification work (or even whether it works), the application name, icon, etc.
• and for schemes where a desktop-wide modules (such as gnome-vfs, as listed above) would own the key, you'd still need to add a separate file to have the application added to the Preferred Applications control-center applet.

We now use mime-types for all this. If you wanted to handle the aforementioned "itpc" URI scheme, you'd just need to say you handle the "x-scheme-handler/itpc" mime-type. This also means you could easily switch between applications handling a URI scheme, as you would a filetype.

You can track the feature, and its usage in bug 631433.

Non-panels in the dog house

For GNOME 3.0, the control-center "capplets" got turned into panels in a new shell. In addition to porting your old preferences application to being a control-center panel (see gnome-bluetooth, gnome-media, gnome-power-manager and others for a show-and-tell), you'll need to make a few changes to your .desktop file.

You'll need to add the "X-GNOME-Settings-Panel" category. If your dialogue is a panel, but lacks this category, it will show up under "Other" in the shell. If your preferences are not a panel but you try to cheat, you'll get a warning, and be removed from the shell altogether.

Bad Bastien

I forgot to mention in all my previous blog entries that my accommodation at GUADEC was sponsored by the GNOME Foundation. Thanks guys!

GUADEC slides

Got back from GUADEC on Saturday, and spent most of the week-end recovering. Probably a good thing, as I have loads of things on my TODO list, for either the Board, GNOME or Fedora.

Geoclue talk

As per usual when I make slides, I end up going through them quickly, but the Q&A session was long enough for me to go into more details.

Bluetooth talk

No slides, for a change. I hope the videos will be available online soon.

10th GUADEC

Made it to the venue today, and am currently enjoying my 10th GUADEC. I'm still behind jrb :)

My first GNOME Foundation board meeting

A couple of weeks ago, I took part in my first GNOME Foundation Board meeting. As you'll soon see (when the meeting minutes are published), I might have opened my mouth a bit too often as I ended up with 5 separate action items :)

With my holidays behind me, I've been able to knock a couple of those items from my list, and I'll try and use this last day to catch up on the rest of them.

I'll be flying in to GUADEC tomorrow morning, probably spending the day doing some tourism, as Sunday is our first face-to-face Board meeting of the new crew.

iDevice tablet hints

As some of you know, I purchased an iPad some time ago, and I've been using it to read articles and papers away from the computer (which definitely makes for a nice change on week-ends).

It's also started to find its place as an online encyclopedia (thanks Wikipanion) next to the sofa, and a YouTube client when friends are around (along with jeers from my N900 wielding housemate).

Getting Books

Plenty of locations to get those. I've been using Project Gutenberg, because it allowed me to get some classics in French. EPubBooks.com has a similar collection, but better formatted, if you only want the English versions.

For comics, I recommend Tintin Revolution (in English and French), with a definitely left-leaning Tintin, out of a job and on the dole. You'll also find some very old school comics on Golden Age Comics.

Reading books

I use Stanza for PDFs and ePubs and ARCReader for comics. Note that ARCReader is supposed to handle PDFs, but it failed to import any of the files I put on there.

Getting the books on the iPad

The version of the iPhone OS on the iPad is different from the one on the other devices (for now), and doesn't allow easy access to the application documents. All the documents live in the application's directory, and a new protocol is used to get and put documents within each app. This isn't working just yet within Linux, so if you don't want to use iTunes, here are a couple of work-arounds.

One way is using ideviceinstaller. It's painful, especially for large files, but it would at least allow you to get your documents back, or on the iPad, even on a non-jailbroken device.

You would need to list the apps:

$ ideviceinstaller -l | grep -i arcreader

org.fieldman.arcreader - ARCreader 1.1

Get an archive of the application onto your computer:

$ ideviceinstaller -a org.fieldman.arcreader -o copy=./

Unpack the IPA file (it's a zip file), add your documents to the Documents subdirectory, repack as a zip file, and push the IPA file back onto the device.

YMMV, I was having some problems with archiving myself.

The second option is using the afc2 jailbroken filesystem. Once jailbroken, and with the afc2add package installed, you can mount the complete filesystem using nautilus-ideviceinfo (right-click on the device, select Properties, then Details, and select "Browse jailbroken filesystem"). The URI is afc://UUID:2/ if you want to mount it by hand using gvfs-mount or nautilus.

Then you can browse to /var/mobile/Applications/Application UUID/Documents add add documents there. Note that free space stat()'ing is broken (I saw 300 megs free when I have nearly 30GB of free space), and you might break your device using the jailbroken filesystem.

The final option would only work with Stanza, we'll come back to this in a second.

Offline reading

I wanted a way to mark articles as "to read later" in my desktop web browser, and be able to read them when more at ease later on. The bare minimum, which I was using until a couple of days ago is the Offline Pages application, a web browser that'll allow you to download full pages for later reading.

Much better for my usage was the Readitlater application, along with its high-quality javascript bookmarklets. The service has nice APIs, so it would be nice to see more integration in feed readers and web browsers (brownie points for the person who makes an Epiphany extension for it).

Getting the books on the iPad, part #2, Stanza

When launching Stanza, you might see a "Computers sharing books" section in the Get Books/Shared section. This will look for computers on the local network exporting a Stanza service via Zeroconf.

Calibre has an implementation, but it's a bit too heavy duty for me. I tried implementing a proof-of-concept version, and it turns out it's not too complicated, though would need more integration into the desktop.

The protocol used is HTTP, with ODPS data. Implementing things like search and categories was not my prime concern either.

First, I launched a web browser, using the little script I use in Totem for my web-based streams tests:

./launch-web-server.sh --remote start

Then publish it via Avahi:

avahi-publish-service "Stanza export" _stanza._tcp 12345

Right, it shows up in Stanza, and the access_log shows me it's trying to get '/'.

It copied a PDF inside the root directory of my web server, and created cover and thumbnail images for it:

evince-thumbnailer -s 512 'foo.pdf' cover.png

evince-thumbnailer -s 512 'foo.pdf' thumb.png

Finally, I create the smallest possible Atom/ODPS file to advertise my PDF file (saved as index.atom):

<?xml version="1.0" encoding="UTF-8"?>
<feed xmlns="http://www.w3.org/2005/Atom"
xmlns:dc="http://purl.org/dc/terms/"
xmlns:opds="http://opds-spec.org/2010/catalog">
<entry>
<title>My PDF</title>
<link type="image/png" rel="http://opds-spec.org/cover" href="cover.png"/>
<link type="image/png" rel="http://opds-spec.org/thumbnail" href="thumb.png"/>

<link type="application/pdf"
rel="http://opds-spec.org/acquisition"
href="foo.pdf"/>
</entry>
</feed>

And redirected the index file to index.atom:

$ cat .htaccess

DirectoryIndex index.atom

Retry access from Stanza, and voila.

This should be fairly straight forward to implement in gnome-user-share, the only hard part being the metadata extraction for the PDFs, and other file types. If somebody fancies taking this on, drop me a mail, and I'll point you in the right direction.

PS: Found out about vim's TOhtml function. Neat.

More on remotes and receivers

After receiving a load of new remotes last week, it was only fair I hacked on gnome-lirc-properties and fixed a number of the long-standing bugs, and release gnome-lirc-properties 0.5.0.

So, what happened

Before the 0.5.0 release, we had a very small number of remotes and receivers combination declared, and unless you owned a receiver and remote that the developers did, you had to select your receiver/remote combination by hand.

Johannes Schmid fixed half of that problem by creating a script that'll go through the lirc sources to add all those remotes to our remotes list. I fixed up a number of bugs, added quirks, and support for parsing user-space drivers.

With that, we went from around 10 remotes/receivers combinations to just short of a hundred.

What's next

ir-core work is ongoing in the kernel, and will provide drivers for a number of receivers with a default keymap. That means that things will work as soon as you plug them in.

A number of receivers also already have input drivers, one level down from ir-core, and work out of the box, such as the ati_remote and appleir drivers.

As we can receive events from the remotes, we just need to funnel them to the desktop. That'll be the work of lircd in the short-term, until XKB2 shows up.

Can I help?

Sure you can. Plug in your receiver, launch gnome-lirc-properties and report whether the receiver is not auto-detected, or whether no remote is selected by default. You can also get me one of the listed remotes on this Amazon wishlist :)

Client-Side Window Decorations and misconceptions

This morning, my RSS reader was full of news with links to Mark Shuttleworth's blog about Canonical's idea for windicators.

The problem now is people conflating Canonical's own design decisions (most of which I don't agree with, except for the case of netbook UIs, but that's not the point here) and Client-Side Window Decorations support.

Martin Gräßlin's blog lists a few things that you would lose if we were to use client-side window decorations. Most of them are just wrong:

• Consistent behavior between all applications no matter if it is a Qt or a GTK or $Toolkit application: How can you say that when there's no agreements on the implementation yet? Of course Athena widget apps will look different, they already do. As long as the theming and behaviour is known and agreed upon, there's no reasons why it should happen. It's just a bit more complicated because you would have cases where the Window Manager would behave differently from the toolkit. All those are solvable, and old, unmaintained toolkits will not integrate.
• Window Tabbing (KWin specific): Why would that be impossible to implement? You'd just need help from the toolkit to do that.
• Window rules like always show a close button even if the window is not closeable: Working around broken apps? Fix your apps...
• Accessibility features like big border and button sizes for all windows: Certainly not. It would even mean that you wouldn't get a disconnect between application and window manager implementing accessibility features.
• Easily changeable window themes: Why wouldn't they be easily changeable? That's highly dependent on how the theming is implemented in toolkits. I guess it would be the case if you had a half-hearted implementation.
• Shadows which are part of the theme (KWin would not paint shadows for a client-side window-decorated window): Why not? If KWin knows that the application is drawing its own decorations, it could draw the shadows, or you could make the application's toolkit be aware that it needs to draw the shadows. Either way, it's not impossible to implement.

There also doesn't seem to be a list of thing you'd end up winning:

• Tear-free window resizing (when the client is doing the resizing, with a proper resize grip for example)
• Better integration of resizing within applications (say "zooming" when going to fullscreen
• Proper way to do tabs in titlebar, a-la Google Chrome
• Window-as-a-document/object (see the tab interaction part of this Empathy UI review, which would enhance the integration between applications and file managers)

And that's just the things I see myself as winning. There's more technical details on the GNOME Wiki.

Update: Got my knickers in a twist over Client-Side Windows vs. Client-Side Window Decorations, fixed up links and text.