iDevice changes

If like me you jumped the queue of soccer moms, divorced middle-age business men and fanbois on Friday morning, you might have had a new toy to play with this week-end.

The good news

If you use Fedora 13, we fixed up some bugs and you can now mount your iPaid (private joke) on the desktop, and have it show up with a spiffy icon. All the updates are in updates-testing.

upower got the ability to tell you your battery status when plugging in an iDevice, though you'll need gnome-power-manager from master to see it, and even then, it won't show up on a desktop system without a UPS. Still some UI problems to iron out there.

gvfs will now warn you about the device being locked. Again, this change is only on master as it adds new strings.

nautilus-ideviceinfo is nearly ripe for consumption after my wad of bug fixes. I expect the code to move into the GNOME repos soon after the first release.

The bad news

Still no video, music or e-books syncing on the tablet iDevice.

No support yet for the per-app documents syncing. If you have a jailbroken device, you can use iFile to move your documents to the Documents sub-directory of /var/mobile/Applications/application-UUID (make sure to turn on "Application names" in the preferences).

Fedora 13 is out!

As the subject mentions, Fedora 13 is out!

Check out the announcement, and the fancy looking release notes.

Funny tidbit, The Register called it Linux for Applephobes, but failed to mention the enhanced iDevice support, and the features we added for Apple Macs as a Fedora machine.

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 :)

My new toys

Thanks to Openismus and Fluendo for sending me 7 new remotes. I guess it means I need to start helping Jarod make all those remotes work using the input layer now :)

And dark themes for apps are in GTK+

Another week, another GTK+ feature. This week's feature is probably easier to implement for applications that would require it, but the uses are also more far-reaching.

Before

After

What does it mean for me, application developer?

If your application matches the type of applications that would benefit from having a dark theme, please try it out. The 3 lines patch is easy to add to existing applications.

You'll most likely want to switch to using symbolic icons as well, for most of your UI, so that the icons show in the expected colour when a dark theme is not available.

What does it mean for me, GTK+ theme designer?

Either you keep your theme as-is. Then all applications will use that theme. This is most likely what should happen for Accessibility-related themes.

Or you create a "gtkrc-dark" file in your theme, at the same level as your gtkrc, and make it dark (not a bit darker like the bad example above, but real dark). Test it out with gtk-demo's “Application Window” demo.

By the way, you might want to update your theme for GTK+ 3.0 at the same time.

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.

Deinterlacing, now in Totem

Totem, in git master for GNOME 2.32, has support for deinterlacing video streams, thanks to the work by Sebastian Dröge. You'll need gst-plugins-base from git master to test it out for now.

Free of charge, you'll get Philip Withnall's work on not blocking the interface when parsing playlists. This should make Totem feel more responsive overall.