Entries Tagged 'General' ↓

Some people have recently asked me for how to get started coding in Swfdec. As Swfdec doesn’t have any examples and I know we’re far too laz^Wbusy to keep it up to date, I’d just thought I might post somethig in my blog. Blog stuff is allowed to get outdated. So here goes my minimal example simple-swfdec.c to get a window up that plays a Flash file using Swfdec:

#include <libswfdec-gtk/swfdec-gtk.h>
int
main (int argc, char **argv)
{
  GtkWidget *window, *widget;
  SwfdecPlayer *player;

  gtk_init (&argc, &argv);
  swfdec_init ();

  if (argc < 2) {
    g_print ("usage: %s URL\n", argv[0]);
    return 1;
  }
  player = swfdec_gtk_player_new_from_uri (argv[1]);
  window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
  widget = swfdec_gtk_widget_new (player);
  gtk_container_add (GTK_CONTAINER (window), widget);
  gtk_widget_show_all (window);
  swfdec_gtk_player_set_playing (SWFDEC_GTK_PLAYER (player), TRUE);

  gtk_main ();

  return 0;
}

Compile with:

gcc -Wall `pkg-config --cflags --libs swfdec-gtk-0.5` simple-swfdec.c -o simple-swfdec

After that you can run Flash files by giving simple-swfdec the full URL like so:

./simple-swfdec http://www.onemorelevel.com/games2/tennis.swf

And now have fun integrating Flash into your apps.

Swfdec got a logo! I think it looks really great. It even fits perfectly with the Ubuntu Swfdec Page. Thanks so much Cris for the design. Now someone only needs to fight the MoinMoin installation on Freedesktop to give the webpage an update. And after that, we’ll have a nicely branded Swfdec.

In other news, I proposed our newest addition, swfdec-gnome, for the GNOME 22 desktop. Swfdec-gnome contains the stuff you need to integrate your downloaded Flash files better into the desktop: There’s a thumbnailer and a small player application. Note that I did not propose to include any browser integration, as I don’t think Swfdec is good enough for that. Yet. Maybe there’ll be swfdec-epiphany integration in GNOME 2.24. ;)

Bastien already had lots of feature requests which got me thinking: What integration features do people really want for local Flash files? After all, this is supposed to be a small application, not one with 25 different menus for what you can do with it. So question to anybody reading this: If you had such a player, what should it be able to do?

Dear artists of the internet, Swfdec is in desperate need of a logo and/or icon. We developers can all write cool code, but not design cool images. To get in touch, leave a comment, mail me or come to our IRC channel: #swfdec on Freenode

And a note: It should not be confused with Adobe’s Flash player logo. I don’t want to be sued.

I had a very relaxing holiday. 3 weeks in Italy. And since I’m a geek (or a nerd, up to you), I took all Flash games from OneMoreLevel.com with me. The result is a huge amount of bugfixes and speedups in Swfdec for supporting the best of those games. I was really happy to see how many of those games already work in Swfdec. So I guess Swfdec is no longer just a Youtube player, but can do all those time-wasting games, too.

And today I wrapped all of that into a Swfdec 0.5.3 release, so you can have fun playing games, too. I’ve updated the Screenshots page with screenshots of and links to those games, so you can play them yourself now.
And to save you one click, the most awesome game definitely is Tennis. I’ve spent days trying to make Anna Kournikova (the worst player) defeat Steffi Graf (the best one):

Thomas, I think this method might even be faster than using Python. And it’s even faster if you have a local checkout of the sources handy. And I think every developer should have checkouts of all the libraries he uses to look at for answering questions.

Let me introduce you to Jeff (photo kindly provided by Google Images). Jeff is an incredibly smart guy. He solves really all the really hard problems with very little code. These days he works for Microsoft as that’s where the hard problems are today. But back in the days he worked on Flash. And that was when Flash had the problem that startup was slow for large files. So Jeff came up with the smart solution to just limit the initial read to 64kB, or 65536 bytes. So files that are 64kB or smaller will be completely parsed when the first frame executes, larger files aren’t.

Does that matter? Yes, because there’s Flash files that assume that they’re not loaded completely in frame 1 and otherwise hang in an infinite loop (I’m debugging such a file right now). So it’s actually quite important to get right. But I don’t think any standard states this as required behavior. So much for usefulness of standards.

Alex has a post about laziness of developers. At least that’s the part I wanna focus on. He is wondering why people used to be ok with fixing the build but now they are “are unwilling to try out new things”.

I think it’s not the developer seniority he points out that’s the problem. At least it’s not the only problem. There is two more points. The first is the size of the project. People used to understand how all the software on their machine worked and what it did. I used to build an LFS and had looked at all the files in /etc. These days ai Can’t even get on the net anymore if NetworkManager doesn’t do it. And that’s not because I became stupid. It’s because I’d need to know the wireless extensions, wpa, hotplug and hal, and not just the right ifconfig line.
The second issue is the general quality of the software. People remembering the time of October Gnome know that problem: applications used to crash or not build. Fixing that was mostly easy. (This had the side effect of a low barrier of entry that helped attract lots of people, but that’s another story.) Today software is expected to be translated, crash-free and easy to build. Various distros are annoyed at libswfdec not having a stable API. 5 years ago people would have laughed at that requirement. So because all the other software today is better, people expect new software to be better, too. You can’t impress people with DOS games anymore.

The approach I’m trying to take in this laziness problem with Swfdec is pretty easy, and is probably the same as for all software in development, but it should be spelled out. I think some people might not have realized this, both people interested in helping or just random people commenting on your software. Here it goes: The most important people are the people working on the project. If the developers have to jump over too many hurdles, they’ll not get stuff done and that is most important at this stage of the project. So if the developers want to use git, the software will be hosted in git. The second most important people are testers and packagers, i.e. all the people that directly work with the source code. The normal user running the application comes last. This is for quite simple reasons: There’s more testers than users – or at least almost as many – and they are a lot more important for the project. They find loads of bugs, report them and help in fixing them. This order of priorities can be seen in the current features of Swfdec: There is an internal debugger, but no stand-alone player. There is the possibility to download movies in the plugin (You need the files to debug them), but it doesn’t do any sort of preferences.

When the project grows up and the number of users increases, this will gradually shift. You can see this with mature software such as Gnome: Not surprising the user is a way more important thing for new releases than adding cool new features. You can of course also notice that such user-friendly software advances way slower than unstable software where developers can change everything to their heart’s content. Both kinds of developments have their place. And the cool thing about it from the users’ point of view is that they can influence the state of a project: The more people use it, the more user-oriented it will become.

I released Swfdec 0.5.2 today. This was an answer to the Ubuntu team that asked to have a new release to go with the Gutsy freeze. Diffstats showed 3k adds in libswfdec/ and 12k adds in total – for 3 weeks, that is pretty awesome. It even makes me the 6th most active C Free software coder!

This release also marks an important point, because it makes the Flash file work that David always wanted to have working. So we fullfilled the goal that made the project founder give up. ;) And while doing all this and walking down history lane, I realized I never thanked the people that make Swfdec go at the pace it currently does. So here is a (most likely incomplete) list of Thank you’s:

• David for starting Swfdec and writing such a sane file parser and jpeg library. I love not having sigsetjmp() in my code.
• Eric for being a great reference on all things X and BSD and doing the admin tasks on Freedesktop.
• Pekka, who suddenly showed up and started testing and fixing all this stuff I’ve always been too lazy to do. Sorry Warsow guys. :p
• Klaus and Sandro for hacking on Ming, that makes writing tests bearable and easy.
• Carl for enduring my questions and helping me slowly get rid of my ignorance of all things graphics. Oh, and he also manages Cairo.
• Andreas, PClouds (his actual name is Nguyễn Thái Ngọc Duy, but I can’t pronounce it, so I always think of him as PClouds) and all the other people that submitted patches.
• Michael, Mario, Alexander and all the other packagers that ensure the code I write works and works well.
• Johan and the rest of the Gtk team for Gtk, and in particular GtkBuilder. Building GUIs made easy again.
• Ryan for dvalue. And for knowing all this stuff about C.
• Richard for that one email back in the days. I wonder if he even remembers it.
• And last but not least Ulrike and the rest of my family, who live with me ignoring them for hours or (probably worse) showing them stupid Flash files that work.

So, how many people work on Swfdec?

And Swfdec’s day, too. First I merged the new debugger into master without any issues. So now everyone hacking on Swfdec can profit from Vivified greatness.

After doing so, I used it. And made bloxorz.swf go from this:
to this:

And if that wasn’t enough, I made Kittencannon work. Here’s the 23MB proof in slow motion. And to top it all off, Pekka has finished making variable flags work. 4 awesome things in one day.

Both of those bugs were longstanding bugs where I had no idea what was causing them. It’s one of the things I have been thinking about a lot. Swfdec is a virtual machine that runs for a long time and at some point you notice something is wrong. But how do you figure out which of the thousands or millions of executed statements caused it? So far the only solution I had was using my knowledge of the codebase and printf debugging, which is not really that great. gdb is not really helpful for stuff that runs for long times, as it always interrupts and it’s hard to inspect the running program.
Vivified so far is only two things: 1) an improved way to insert printfs – by inserting prints in the debugger’s hooks and 2) a UI for common things to look at, so printf isn’t needed. Vivified keeps a tree of the currently running movieclip instances, so it’s easy to see when one goes away when it shouldn’t, even an invisible one. It helps tremendously (see above), but I have the feeling it can be done way better.

When looking at other software with the same problems in Gnome land, there isn’t really a lot. Most Gtk applications aren’t long-running, they’re mostly short snippets of code after a user action. The parts that are (session startup) pretty much use the same approach that GStreamer uses, and that approach is the old one: printf. GStreamer just has this glorified printf framework where one has to look through 3GB of output to find a bug, which is neither easy nor intuitive. So I guess I should end this rambling with a “dear interweb”: Dear Interweb, do you know of ways to debug long running applications and find bugs that happened 20 minutes ago but only caused a problem now?

Watch this!

Your only excuse of not watching it is if you already use git. It’s a one-hour Google tech talk from Linus about Git. You not only learn why Git is the only sane RCS to use, but also that Subversion designers are stupid and that Linus doesn’t trust Google. He claims to not even trust Andrew Morton to take his medicine every day.