I’ve tried Cinnamon

Another intermission while I’m still not having anything new to say about my current line of work. Since the new GNOME 3 was released today, I was discussing it with Luca, and he suggested me to try Cinnamon which is Linux Mint’s user interface, based upon GNOME 3’s technologies and libraries, but providing an experience much more in line with GNOME 2. Exactly what I wanted.

Indeed, after trying it out a moment, it seems to me like it’s exactly what I want: it propones again some of the features that I used from Compiz (including the Expo support for workgroups, even if they are still in-line rather than squared around), and it provides an experience in line with the one I get from Xfce4 right now…

So why did I go back to Xfce, if all seems to be what I want? Well, beside the fact that Cinnamon shows to still be in its infancy, I’m having some serious doubts about Gtk3’s viability, but I’ll wait for the new release before judging I guess. What’s going on here is simple to put in works, but probably not simple to explain: part of the behaviour of Super and Alt_L keys is switched.

What I mean is that if, with the default configuration, I hit the Super key (i.e., the one with the Windows logo on it on this keyboard), then I get Cinnamon’s Menu, exactly what I want. On the other hand, if I press Alt-Tab to get the application switcher, I get nothing: the switcher comes up with Super-Tab. The same applies to other parts of the bindings: Alt-F2 brings me to the second workspace, rather than to the “execute command” dialog, which appears if I press Super-F2.

I would have said the problem lied in Cinnamon, if the documentation didn’t report everything to be correct as I expect it to be, and having had some serious issues with Super not working correctly on my home desktop where I tried GNOME 3 before (It wouldn’t let me use Super-C/Super-V to copy and paste from GNOME Terminal).

There actually is an option in the xkb configuration that allows you to switch the two keys, making it possible to have a quite reasonable experience — if it wasn’t that then you would have Super and Meta switched within Emacs, which otherwise respect the same correct configuration as I’m expecting out of the box, d’oh.

Add to this that Clutter’s cogl library seems to be unstable on nvidia-based hardware, and you can probably see why I’m still not convinced to move to that desktop environment, which is a shame, since I actually think it has a much better experience right now than Xfce4. If it worked correctly, sigh!

I’ll wait on it.. and if somebody has a clue about the issue I’m describing with the keys (I don’t want to debug it further myself for now, that’s why I haven’t reported it upstream yet), please let me know!

Xfce4, ssh-agent, and smartcards

This is more of a note for myself to not forget this again.

As I said the other day I’m not liking Gnome 3 so much; while the “fallback mode” looks more usable than the shell itself, the fact that to get to the tweaker tool I have to install shell anyway is a bit bothersome. I set up the desktop already, as I said, to use part of Gnome3 stuff, mostly because of a bug in Evolution 2, but now it’s the turn of the laptop, as Gnome 3 has been unmasked

Incidentally, my desktop, and thus my main work environment, is currently unavailable; after the outages of the other day I found out that one of my two UPSes had a fried board, and it couldn’t work without mains running.. given they are doing heavy work on the power line, and the fact that I had to clean up my home office already as new furniture is scheduled to arrive next week, I decided to simply put it away until the new desks are in. Why do the job twice?

At any rate, I decided to go with Xfce4 on the laptop as well, even though this seems to have a slightly different configuration and that spells trouble with Gtk3 for now – in particular fonts are huge, and I don’t know yet why; xdpyinfo reports the correct DPI value for the monitor, and the correct size in millimetres – it still is better than Gnome3. Interestingly enough, the way Xfce4 handles ssh-agent and gpg-agent is quite nice: indeed it actually relies on using gpg-agent with ssh support instead of both of them separately, which is generally compatible with using OpenPGP cards for SSH authentication, but it is a bit incompatible with my suggested script (which I should actually update, at another time, since I modified it a bit since last time).

It is true that I could probably just suggest a few changes to Xfce’s handling code and get it to behave exactly like mine, or at least in a compatible way (the startxfce4 code is very neat, and very hackable!), but for now I wanted to sidestep the issue altogether. I just need for the session script not to override what I set myself. So how do you do that? Simple enough it seems:

% xfconf-query -c xfce4-session -p /startup/ssh-agent/enabled -t bool -s false -n
% xfconf-query -c xfce4-session -p /startup/gpg-agent/enabled -t bool -s false -n

By the way, the reason why I’m not going to spend time trying to fix the compatibility issue between my script and the original code is actually quite simple: the only difference I see is the placement of the agent sockets: my current script uses the standard socket locations (~/.gnupg/S.gpg-agent and ~/.gnupg/S.gpg-agent.ssh), while Xfce4 says nothing and gets the random, temporary locations instead. In the next GnuPG minor version, the default will be changed to use the standard location, so Xfce4 session will be automagically fixed.. that’s about the only reason why I don’t want to spend time on it now.

At least by blogging this I’ll remember how to get back to Xfce4-handled agents, and adapt my script to integrate with that.

Single point of mime detection

(The title refers to Single point of failure, which vaguely relates to the issue at hand.)

I was talking with Ian (Amarok) and Pino (Okular) tonight, as I fixed a few more mimetypes in xine-lib, about shared-mime-info.

The SMI package, originally written for GNOME, but nowadays also used by XFCE and KDE4, contains an XML file which contain the list of mime types, the extensions they can take and a few magic numbers to identify the mimetype of a given file.

Having a shared package is quite a good idea actually, and as shared-mime-info is extensible by adding an extra xml file (like OpenOffice does), it adds flexibility to be able to change the data in one place to fetch it from everywhere.

But, one tool that is not using this data is the main consumer of similar data: file(1). The file implementation we use at the moment has its own data files to discover the type of files, it does not use shared-mime-info.

So if anybody would like to cut his teeth with a new application, I suppose it would be at least a nice proof of concept to have a 100% compatible file(1) implementation – libmagic included – which uses shared-mime-info database for gathering the data.

I’m just not sure if shared-mime-info contains enough data to implement that, as file(1) reports a few extra information about the files, like the version they implement (for audio files for instance). It would be nice, though, if we could do that, as that would mean that we’d have a viable single source for such data, which is a good thing as you can share it between even widely different software.