Older blog entries for company (starting at number 28)

I need to follow up on David's Post about Foundation membership because it fits so well:

As much as it is a nice feeling to feel welcome when you've got your confirmation email, it's a weird feeling when you get the email that you will be no longer a member now, because you didn't do the work to renew it, even though you're still very involved with GNOME.
This is the only reason why I am no longer a foundation member.

Who let this crap into Gtk? I'm really annoyed that such code ended up there, because that code not only works bad, but also is conceptual crap. I'm talking about the dnd code. So what's wrong with it? I'll start with the worst things:

1. You have to provide a function that creates a new window if the tab is dragged off the notebook. So what's wrong with gtk_notebook_set_window_creation_hook? It's global. Every self-respecting programmer should know by now that globals are bad, mkay? Especially so in libraries. Anyone remember XSetErrorHandler? So just assume for a moment, that you were using a docking library (like the Gimp or Gdl) that wants to support floating docks and you want to make some of your own notebooks detachable. Who sets the hook?
2. To figure out if dragging from one notebook to another is allowed, one has to set a group id. And this is a (positive) integer. Hi namespace collision. By now I'd thought that it was common knowledge to use strings or pointers for such a thing. But apparently it's not. So what ID is the docking library using now? Just pick one and hope?
3. Detaching tabs only works if you drag them to the desktop. Don't ever try this with a fullscreen app.
4. Reordering is implemented without drag'n'drop to give nice visual feedback. Unfortunately detaching is implemented with drag'n'drop. So once you've gone over the threshold to start a drag, the UI looks completely different. Even if you later on move the mouse over the notebook again, it doesn't change back.
5. There is absolutely no visual feedback (aka highlighting) when doing a drag.
6. The code for reordering (or dragging) tabs in a small notebook (where the arrows are visible and preferrably only one notebook is visual at any time) does not work in any reliable way.
7. There are lots of different annoying drawing glitches from flickering to drawing tabs in weird places during reordering and dragging.

These are lots of reasons that would have gotten me patches rejected almost everywhere in the gnome stack. So why did the normally excellent Gtk quality control fail to work in the notebook case?

So there's lots of discussion about screencasting going on. And since I'm the Byzanz guy, I'll add my stuff to this discussion.

While thinking about how to extend Byzanz and what features to add to it, I came up with four requirements for a good screencasting application on Linux, which are, in descending importance:

1. Can be played back inside a browser with a default installation of current versions of Windows, RHEL and Ubuntu.

   This is important because most screencasts are made for the web and for a wide audience. And these audiences probably use an average distribution and are not into installing weird software. They probably just use the default. This is why I picked Windows (the biggest audience) and Linux (a big audience for recordings of Linux desktops).

2. Can be recorded on a recent Fedora or Ubuntu with a default install and an install of the recorder.

   It should not be hard to get going. If there's a custm compile needed or packages are required that for some reason cannot be included in the package tree (think multimedia and patents here), then it's not an easy tool.

3. Has a decent quality and file size.

   This is fairly obvious. You don't want to wait an aeon until the download is finished and you want to be able to see what the screencast is about. And this point requires special care because a lot of video formats are bad for screencasts since they fail to produce good enough recordings of text.

4. records audio

   While this sounds fairly easy ("just add the feature!"), it becomes a problem when choosing the right format. It's also currently a problem in the "just works" department because there's quite some setup required in all the apps I've used that support audio input. Even Ekiga, which is a simple to use multimedia application, still has a druid.

So with these 4 points I set out to find a format suitable for recording screencasts. And I haven't found one. There's a lot of formats that sort-of work, but none of them does all 4.

• GIF does (1) and (2) and is ok for (3). That is, until you start recording images or videos, because the format only supports 256 different colors and videos or images tend to use all the 16 million different ones. And the file size starts to suck, too. GIF totally fails at (4), because it has no sound.
• Flash is the probably the best choice for (3) and (4), might work for (1) - I have no clue about Flash playback in current Linux distros, but totally fails at (2). Flash audio is MP3 and currently no distro ships an MP3 encoder in their main repository. Add to that the missing availability of flash encoding libraries in Linux and especially Linux distros.
• All video formats (think MPEG, AVI formats or OGG THEORA here) do (4) and are ok at (3). But none of them does (1). Either they work in Windows or they work in Linux. Probably they work nowhere because browser plugins for video playback aren't installed by default. And the we haven't touched (2) which is hard becase multimedia production enters the patent minefield again which makes distros not ship encoding libraries.
• JAVA is an option. A custom Java applet for playing back screencasts could easily handle (3) and (4). And it would do (1) and (2) for every distro that has a JRE and Java browser plugin installed. Unfortunately this is the first problem. Most current Linux distributions don't have that installed. And the second problem is that a good Java applet is missing and noone has stepped up yet to code a screencast applet.

So currently, even though I have written an application that in my opinion almost perfectly manages the first 4 points of Quim's requiremens, I can't do anyting right now to solve the last ones because I'm lacking a format that would manage them. I'd love to, but I have no clue how. Suggestions welcome.

To go with the rest of the people: GUADEC is great. What is apparently great, too, is my English. Thanks to all the people who really thought I was a native Brit, you made my day. It'll probably make the day of my former English teacher, too, when I tell him this.

And I've met almost all the people I wanted to meet. Only iain, thos and vuntz are missing on my list. I probably forgot one though.

And, most important: sri is totally afraid of my verbal skills and keeps hiding from me!

Since I was nicely asked to do so, I'll write a blog entry about this stuff, that's been happening around me.

Workspace switcher

The workspace siwtcher got a facelift for the upcoming GNOME 2.16. Besides some visual improvements, you'll notice from the above animation that dragging items around is now real drag and drop with proper highlighting and prelighting. It's also now possible to drag windows from the tasklist to the pager. Says Vincent:

This is awesome. I don't understand how we could live without this!

Volume Applet

It seems to be a not so well known fact that using the Ctrl key, you can select multiple tracks to control. This is especially useful for people who have a different volume track for headphones and speakers on their Laptop.

Byzanz 0.1.1

Today I received a patch by Richard Ferguson, who made new icons for Byzanz. Wow. Together with the translations and various other people helping me fix stuff, that's a nice list of stuff other people did for Byzanz. Basically the first release where I didn't need to do anything for it. :)
Get it here.

There's one interesting patch that I didn't include, which tries to add "save to HTML". Problem with that patch is that it requires saving two files. This breaks a lot of assumptions of various parts of the code (example: overwrite confirmation in the file chooser) and it would probably break user expectations, too. ("I saved to HTML and then copied that to my webspace, but now the image doesn't show up.") So if there is a good solution to that problem that any app implements, please tell me.

Guadec Accomodation

Since many people have been wondering about this and I couldn't find it on the GUADEC page:
The accomodation is 8 nights, checking in on Friday 23rd and leaving on Saturday 1st.

Quick note

It's a good thing to see all these people in the open source scene promote Free formats.

Byzanz 0.1.0

I've now arrived at what I'd call feature complete. It even has an about box! So, go grab Byzanz 0.1.0 and play with it.

So what's new in this release? Three things: The applet got a complete overhaul, you can now record your mouse pointer and the code has been moved to Gnome CVS. What's also new is me wondering about where I want to go with this thing. Should it be included in the Gnome desktop? Should it be made to record to other formats? If so, which? Do people want to record audio with it? Do people want to add things to these recordings (like bubbles explaining things) and need an editor for this? Do people even care? I guess I'll need to wait for recordings popping up on the net to see what people use it for.

Another thing I've played around with a lot while writing this thing is GIF encoding and decoding. Encoding is interesting for two reasons. The first is performance. You want to ideally have your GIF completely encoded when you press the stop button and not have to wait until it's done encoding. While for an average desktop session, this is no problem even on my old iBook, recording playback of a full screen H264 movie (which itself can take more than half of the performance of a 3GHz CPU) will have you wait a while for the result. So what's so slow in the encoder?

• Color lookup is slow. Color lookup is the process of selecting that one of the 256 colors in a GIF that most closely matches the color we want to encode. I've yet to find an algorithm that implements that fast and efficient. The current tree-based algorithm and the "create a 64MB lookup table" approach seem both suboptimal to me - the first is slow, the second uses far too much memory.
• Dithering is slow. There's a lot of calculations required per pixel to keep track of all the different error values. This could possibly be sped up quite significiantly by using vectorizations (Altivec, MMX, SSE), but I'm not a specialist on those.

The second thing that is interesting about encoding is the size of the encoded image. The current code already optimizes quite a bit. It tries to find regions that haven't changed and omits them or if that's not possible it sets them as transparent. That way you get a lot of transparent pixels, which result in a pixel array that can be compressed a lot better. You can see this by opening one of your recorded GIFs in the GIMP (which is an excellent debugging tool for animated GIFs btw). But there are of course still optimizations that might be useful, like marking a pixel transparent even though it changed, when it didn't change a lot.

Another interesting thing are GIF decoders. Since your average GIF image is small (you know those little animations on the web - the biggest ones are probably banner ads), but Byzanz easily records full screen animations that last multiple minutes and easily exceed 50MB in size, you find the limitations of the current GIF decoding libraries easily. And you find out that every project has its own GIF decoder. And you find out when you record a 17MB animation of a short movie with around 1500 frames (the movie itself is 9MB in size, so don't use GIFs to record movies ;)), that

• the GIMP decodes the whole image into layers and then gets performance issues when rendering the resulting file, since it has to compose 1500 layers. Changing the visibility of one layer result in a huge lag. It's ok in memory usage though (around 300MB, probably only keeping the change regions).
• Mozilla also decodes the whole image at once resulting in rendering hickups during playback of the loading animation. When it plays back the looping animation a second time, everything works fine though. It uses as much memory as the GIMP for this (300MB).
• Internet Explorer 4 (the only one I have) opens the image fine and displays it without problems. No clue about memory usage though.
• Gtk consumes all available memory and my machine hangs. (Crappy OOM handling therefor a desktop, Linux.) This is because it tries to keep the completely rendered frames in memory. That easily exceeds multiple Gigabytes.
• note to self: test Konqueror

None of those applications handle GIF the way it was envisioned in the GIF spec: As a data stream. They all implement it like it's used most of the time: As ad banners. I wonder if Gtk and Mozilla devs would like to get their gif image handling code improved, even if that'd require writing a new library. I'd bet on "don't care really, the current code is good enough".

Oh and one thing: I need icons for Byzanz that don't suck. Feel free to create some and send them my way - or just check them in if you have a Gnome CVS account.

Byzanz 0.0.3

Byzanz 0.0.3 is out. This time it's supposed to work on a lot more computers than jus my laptops. The last release had the (expected) first release illnesses and for most machines didn't work at all. Particularly the "everything is red" and "Byzanz needs XComposite enabled" bugs are gone. A new demo of Gedit's new features is available straight from Paolo's blog

I was really overwhelmed by the feedback I got and how many people expressed interest. Such things really motivate. Thanks to everyone who emailed me with bug reports, tips or a translation. It's greatly appreciated. If this release actually works for normal people, I'm particularly interested in if it works on 64bit systems.

I should probably mention one thing: The whole code does not do error checking. So if something fails, it fails and it won't tell you or do something against it. Error reporting has to wait for one of the next releases I'm afraid. But then again, this is 0.0.2. ;)

Writing panel applets

Writing good panel applets is hard. And since pictures say more than a thousand words, look at this:

This is two very standard widgets given less size than requested. And I'll explain my big hurdles to writing good panel applets anyway:

• Gtk widgets are really bad at handling the case of getting allocated less space than they requested (see the screenshots above). This is because the Gtk usecase is a window which sets its minimum size to the requested size of its contents, so it basically never happens. But for a panel this is a frequent happening, because the user sets the maximum size of the panel and not Gtk.
• There are no containers that handle the different panels in a satisfying way. Since it is possible to have panels on all 4 sides on the screen (vertical and horizontal orientation) and with sizes from 23 to 120 pixels, there is a lot that can be and is done wrong with widget layout. The simplest example is that a container that behaves like a Vbox on a vertical panel should behave like a HBox on a horizontal panel.
• Panel applets must be optimized for size. Since they occupy parts of your screen all the time, the space occupied should be as small as possible. A lot of widgets are written for nice display in big windows (as in 500x300 pixels or more) and don't care about using 2 or 3 pixels more. A GtkButton in the most-used themes uses on average 5 pixels on both sides for displaying the box around it. If you now remember that a normal panel is 30 pixels high, you can imagine that losing a third of your available space just for a nice border is not what you want.
• Since the presentation space of applets is not very big, the information must be presented in a very compact form. For example text is not an option most of the time, since text is just too big. ("Hello World" requires 76x16 pixels in my configuration, that's almost enough to display 3 24x24 images.) Unfortunately there seem to not many widgets around that try to achieve the same goal. An exception might be the GtkToolbar widgets, but then again the toolbar uses a visually very different approach from panel applets, so just using toolbar items would look kinda stupid in a panel.
• Applets normally don't react to right clicks but bring up the default menu instead. But lots of Gtk widgets intercept right clicks. This makes applets with those widgets feel wrong. (The window list does this for example)

So what I'd like to have is a collection of widgets that make it easy to create good applet UIs. And I'd like
And I'd like these widgets applied to the current applets. Current applets suffer heavily from this not being available. Just try using a 60px vertical panel as your only panel for a while to figure this out ;)
Unfortunately there seems to not be a lot of interest in getting applets working nicely the maintainers of that code tell me. I wonder why that is. Probably just a case of missing good libraries to use, as always...

Edit: Yes, that read 0.0.2 before, but people seem to have their own partition for $HOME which tends to cause issues. So I did a quick-fix to 0.0.3 for them.