Games on Linux Blog

I'm not a game player, but my minor attempts at using the Wine AppDB have been fruitless and frustrating. I wanted a list of easily-installable games that just work, either natively or with Wine. Since my gal spends an hour a day with little, fun games, mostly using Wine, I decided to recruit her as a tester and put up a blog about the games that work OOTB.
The format of each entry is the same:

1. The title of the game with a link to the download page
2. A screenshot
3. The publisher's description of the game
4. The system requirements from the publisher
5. A gameplay video
6. Installation instructions

Click on the title, above to see the thirty games I've got so far. Contact me if you want to help with the project.

The New Ribbon in F-Spot

F-Spot has a new ribbon. Here's a short video of it in action.

Ubuntu devs are considering using empathy as default for Intrepid

As a follow-up to my recent post about Empathy being accepted into Gnome, it appears that the Ubuntu devs are looking for testing in anticipation of replacing Pidgin as the default IM client.

There is certainly no consensus on the matter right now, but the feeling is that

1. Intrepid is the proper place to make such a replacement since the LTS was just released and there is enough time to work any kinks out.
2. Empathy will probably be integrated at some point and Ubuntu should be on the leading edge of this (A.K.A. "It's a selling point).
3. Empathy offers a much better path forward than Pidgin.
4. Empathy offers voice/video right now, while Pidgin's has been promised for some time and is on an uncertain timeline.

See the original e-mail announcement for more (much more!) information.

Why GnomeBaker and Brasero Aren't Standard on Gnome

When the Ubuntu devs decided to ship Brasero with 8.04LTS, the users thundered with applause. Everyone, it seems, wants a Nero-style application for the desktop. Why is that? More pointedly, why does Gnome choose not to ship a CD-burning application as part of the desktop? The answer to that question says a lot about how Gnome is designed to be used.

Let's look at some of the standard uses of Brasero and see how we accomplish the sale task without it in Gnome.

Easy Task: Write a prepared .iso file to a CD or DVD.

In Brasero

1. Open Brasero
2. Choose "Burn Image"
3. Click on "Path"
4. Navigate to and choose .iso file
5. Click "Burn"

In Gnome

1. Open a file browser window
2. Navigate to file
3. Right-click the file and choose "Write to Disk"
4. Click "Write"

While these two procedures don't seem very different from each other, you often start at step three of the Gnome way because you are already looking at the file you want to burn. You'll look at the file and say to yourself "I want to make a copy of this." If you know that double-click means "open" in Gnome and right-click means "do something else to a file," this method is the intuitive one.

Medium Task: Create a data CD

In Brasero

1. Open Brasero
2. Click "Data Project"
3. Drag and drop files or use the chooser.
4. Click Project > Burn
5. Click "Burn"

In Gnome

1. Insert a blank disk or choose Places > CD/DVD creator
2. Drag and drop files
3. Click "Write to disk"
4. Click "Write"

Again, these don't look very different on the surface until you realize that you get #1 for free by inserting the CD (which you need to do in any case). The work flow is intuitive: Insert a blank CD and choose what to put on it.

Difficult Task: Create an audio CD from OGG or MP3 files.

In Brasero

1. Open Brasero
2. Choose "Audio project"
3. Navigate to the audio files
4. Drag and drop the files
5. Click "Burn"
6. Click "Burn" again

In Gnome

1. Open Rhythmbox
2. Create a new playlist
3. Filter the files you want
4. Drag and drop the files
   
5. Right click the playlist and choose "Create audio CD"
6. Click "Create"

This is arguably a draw, but I'm going to argue that RB, being a jukebox application, is probably more efficient at finding your music than a multi-pane browser is. It's probably up to taste.

Bonus Task #1: Copy a disk

In Brasero

1. Open Brasero
2. Choose "Disk copy"
3. Choose "Copy"

In Gnome

1. Go to Places > Computer
2. Right-click on the CD and choose "Copy disk"
3. Click "Write"

This is probably the least intuitive Gnome method so far, but it was still exactly where I expected it to be (note: I've never attempted this task before and I doubt many average users would ever do it). I do wish that there were a menu option under "File" when the CD directory opens (automatically in Gnome) to copy the disk. Given the lack of a drive-centric view in *nix, though, I think that the method used is the most consistent ideologically.

Bonus Task #2: Create a new .iso image

The steps for both methods are exactly the same as creating a data CD (above), except that the user needs to choose "File image" instead of the drive in the "Write disk to" field.

Conclusion

Brasero has four options for creating CD/DVD projects. It contains nothing that standard Gnome can't do in the same number or fewer steps or much more easily.

Why do so many users want Brasero, then? Nero-itis. That's the rational answer. Tell me if you have another reason or if there's something that Brasero (or even the vaunted K3B) does better than Gnome apps do.

Gnome has Empathy for You

Well, the Gnome 2.24 freeze is on, and something happened that I never imagined.

Just after 2.22 was released, I took a look at the upcoming Gnome release, and I said, for probably the fifth time, that I wish Empathy and Telepathy would make it into Gnome, but that it wasn't going to happen because

1. The licensing was wrong (libempathy is GPLed because it is forked from Gossip), and
2. The was no API documentation

The Gnome developers have apparently gotten tired of waiting for these problems to be fixed and just went ahead and made Empathy and the associated libs part of Gnome (edit: only as external dependencies). I'm assuming that this move will put more pressure on the main developer to come into line and will make the project higher profile, giving him more manpower to work with.

Although I've said it before, this next part bears repeating. The inclusion of Empathy (and Telepathy) into Gnome is huge. Why? Well, just look at the history of GStreamer.

GStreamer came into Gnome as an immature and underpowered framework for audio and video. It took a few releases to mature, but it does pretty well these days (We all know it can be improved) and the next release will see more advanced features like DVD menus. Totem uses GStreamer. Rhythmbox uses it. Banshee uses it. Elisa uses it. Pretty much every application that wants to add audio or video is now using GStreamer ... even some KDE apps.

Telepathy is likely to work the same way for messaging. Right now, telepathy has real backends for text, voice, and video. It handles quite a few protocols through its own plugins and virtually everything else though libpurple (from Pidgin). In a couple of Gnome releases, we should be seeing Evolution, Ekiga, and Empathy in a giant symbiotic relationship. Suddenly, you will see that the person you're emailing is online and accepting IM/voice (but no video), and you will be able to click to start the conversation. This isn't too much different than the way GMail works now (and is a killer feature), but the desktop integration will be complete, meaning an easier time communicating for the Gnome user. I'm really looking forward to this eventuality. Oh, and can we get Soylent while we're at it? ;)

If you use Ubuntu, consider voting for Empathy.

ALERT: Ubuntu is considering replacing Pidgin with Empathy for Intrepid.

Also included in the final cut was another next-to-impossible-to-approve application called Conduit, which I use daily and which I'll be writing about soon. What was keeping Conduit from being considered was

1. The total lack of keyboard utility, and
2. An impossible accessibility situation

The solution to problem #2 is being worked on, but I don't think the Gnome devs are that interested because they are focused on making Conduit a back-end instead of a main application. Eventually the individual applications will call Conduit to do backups and syncs for them. Sadly, Conduit the application has been called a case study in why you shouldn't use custom widgets, and it will probably never be 100% accessible.


While I'm talking about new applications in Gnome, I should mention Hamster, a time-tracking applet which has some interesting features. We should be seeing good keyboard shortcuts and maybe even a connection to virtual desktops in order to track time.

Don't Like Mono? Try Vala.

My recent post about Mono was sincere, and Boycott Novell has the story about Debian wrong, but Gnome actually is pushing an alternative. Before I introduce you to the programming language Vala, let me give you some background on programming for Gnome as I understand it (note that I am not a programmer and haven't done anything real since the mid-80s).

Gnome is based on C, which makes it much more difficult to write for than, say, KDE, which is an object-oriented, C++ language. Gnome tries to put some OO structures on top of C, but developers often claim that they don't help a lot. As a result, Gnome developers (especially new ones) like to use bindings for other languages like Python, Ruby, or C#. These have drawbacks that the languages and bindings have to be installed, raising the install size (see Debian's complaint about Mono bringing in 50MB just for Tomboy). Mono's JIT executables are almost as fast as binary executables, but not quite. Scripting languages, though, are notoriously slow. None of the languages are a perfect fit for the GObject system, either.

Enter Vala, which is a new language developed by Gnome specifically for developing Gnome apps. It has a syntax very similar to Java or C# (closer to C# from what I've read) and a precompiler which maps the Vala to C source and header files, which can be compiled into an executable. The code is probably not as efficient as that written by hand, but Gnome claims very similar performance. Of course the use of a high-level language means that programmers shooting themselves in the foot with C is more difficult. The downside is that Vala programs aren't cross-platform like the other high-level options, but cross-compiling for three or four platforms shouldn't be too difficult.

Vala should reach 1.0 at the end of September, but only supports GLib and GTK+ right now. The entire Gnome platform is expected to be supported Real Soon Now (TM). There's already language support for it in GEdit and bindings for Monodevelop.

I've been playing with the example code, and it seems straightforward and simple to make GUI apps (eggclock is to the left). The language is really new, so there aren't a lot of applications writeen using it, but a fork of Cheese is trying to rewrite the application using Vala. There are also various multimedia, benchmarking, and text editing apps.

Mono and C# have a lot of really cool applications right now: Tomboy, F-Spot, and Banshee. If these were forked and rewritten in the C#-like Vala, we could see greater performance and silence the anti-Mono crowd. Sounds like heaven, eh? OK, I can dream, can't I?

Oddly, I don't really get an NIH feeling about Vala at all. I wonder why that is.

Solognu has translated this post into Spanish. ¿No te gusta Mono? Prueba Vala

Is Debian Really Afraid of Mono? No!

Not only is Roy Schestowitz a little on the paranoid side,he apparently likes to troll, as well. In a recent article he claims that

The necessary harmonisation between GNOME metapackages and tasksel turned out to be in favour of removing tomboy from metapackages instead of adding it to tasksel, because Mono is widely seen as “controversial” (see above).

and quotes the developers:

 * tomboy: very nice app, but controversial since it brings the
full Mono stack, so we don’t make it part of
gnome-desktop-environment.

The only problem is that, if you actually read the link, you find that he's taken everything out of context. I couldn't let that go, so I posted the following response

I know you like to live in your own reality, but the thread explains itself nicely if you read it.

Josselin Mouette is the package maintainer for gnome-desktop-environment, which he/she describes in the message as ‘Currently, the “gnome-desktop” task consists of the “gnome-desktop-environment” metapackage (official GNOME release) plus a number of extras. However we already provide the “gnome” metapackage which consists of g-d-e plus a number of extras to make a full-fledged desktop. ‘ He/she suggests INCLUDING Tomboy, but says the quote you use in your summary to show a possible downside.

Joey Hess (who apparently has privilege to immediately edit the gnome-desktop task) gives the REAL reason for not including Tomboy when he responds “There’s a fundamental difference between the gnome package and the gnome-desktop task. The former is the complere (sic) gnome desktop environment with all extras, as shipped by gnome, while the latter attempts to be the best gnome-based desktop that Debian can put together and ship on a CD/DVD.” Later, “I doubt that the size of [Tomboy’s] dep chain (~50 mb) makes it worthwhile to add it to our task.”
Josselin answers “Yeah, that’s what I feared. I hope someone rewrites it in Vala some day…” He/she understands that there’s not enough space.

Tomboy (and by proxy, Mono) were reduced to “a recommends,” meaning that tasksel won’t install Tomboy, but aptitude (the recommended method to add software) WILL.

Mono is just too big a dependency to put on CD1 for one application.

If you install a Debian standard system, then “aptitude install gnome,” you’ll STILL get Tomboy.

There is no controversy. Quit stirring up stuff that’s not there.

Considering the quality of the hysteria on that site, I doubt he'll listen.