Last 5 Posts from 2007/April

I've been using GIT as version control system for my Python bindings for Enlightenment Foundation Libraries and I'm really enjoying.

As most FOSS developers, I've used CVS for some time, then when SVN appeared I've tried and liked it very much, lots of problems that I had with CVS were fixed, but one remaining problem stand still: offline commits. Nothing sucks more than working with huge changes offline and having to maintain the split patches yourself... or creating a local SVN to do it for me and then producing patches and applying to the other repository.

I've started my bindings and hope them to get hosted on E.org, so I wouldn't bother opening a SF project for it, however I don't like to work without version control system. I was about to issue "svnadmin create" when I was informed about ruby bindings and I saw they use GIT, so I opted to give it a try.

The first thing you will notice is that it's damn fast! I also like some utilities they provide, that makes day-to-day development cool. I still cannot say how much hurdle is to work collaboratively and neither if I like to pull, push, merge or what, since I'm working alone, but seems that the worst case will be just like CVS/SVN, but there is a comparison of Git and SVN.

If you have not tried GIT yet, checkout the introduction tutorial, "Git crash course for {CVS,SVN} users", "Everyday GIT with 20 commands or so" and "Introduction to git-svn".

I'm giving new life to Eagle. It was almost dead, I had no time to write code and even keep its web space.

But these last weeks I took some time and moved it to Google Code project hosting, created a Google Groups and fixed some bugs with its site. Basic information:

• SVN: svn co http://eagle-py.googlecode.com/svn/ eagle
• WWW: http://www.gustavobarbieri.com.br/eagle/
• DOCS: http://www.gustavobarbieri.com.br/eagle/docs/
• API: http://www.gustavobarbieri.com.br/eagle/docs/api
• MAIL: http://groups.google.com/group/eagle-py

Those new to Eagle: it's an abstraction layer atop existing Toolkits, currently GTK and GTK/Hildon/Maemo are supported. It has a simple, coherent and easy to use API. It does impose some limits in order to keep it simple, so it's not as flexible as GTK or QT, but it's much easier!

Maemo version still misses menu and toolbars, but I plan to add them this week, then I'll release packages and try to get them in repository.maemo.org/extras.

Some time ago, just after Morpheuz posted "Prison Break: Freedom for your videos", people were asking for UI being able to play it, so I joined the bandwagon and started to write a MPlayer frontend in Python, "Catota" was born. Catota, which means "snot" in Brazil (see README), is a quick hack and will not evolve as yet-another-player, however it's usable and extensible, so I can continue my experiments. As the screenshots show, it has a plugin system to enable various sources, featuring now "GMyth Streamer" (broken, see below), "Local Files" and "Pass Through" (to pass anything to MPlayer, like smb://a/b/c). These experiments were really useful for both Catota and GMyth Streamer. I've discovered that MPlayer for Maemo now uses dspmp3sink by default, and that sucks a lot! Hell, just being back to ffmpeg codecs and esd output solved a lot of problems, that's why Catota ships with this by default. Also, MPlayer crashes more than expected when using Xv output and toggle fullscreen. On GMyth Streamer front, what Artur (Morpheuz) did great was to discover MEncoder settings, but his server was a bit bad (we share the same house here in Recife, so I know he did the entire code on a Sunday night!), so I got some knowledge with Python and its libraries (SocketServer and friends) and give him a hand, providing a Catota-Server as example. This Catota-Server is now the base of GMyth Streamer! Great! (However now I need to update GMyth Streamer source to use the new schema). On the Catota features, I did a really nice thing that should be adopted by every Maemo application: auto-save every input field. Catota always remember last volume, mute, selected file, entered URL... It just sucks having to set those every time you start the application. Source is available at: http://barbieri-playground.googlecode.com/svn/maemo/catota/ (SVN)

Last week I was faced with a problem I had 2 years ago: generating Gantt graphs for our projects. While at IBM/LTC, I found TaskJuggler to be a nice tool, very developer oriented, but it lacked means to generate nice graphs... I've requested this feature in 2005, it got implemented by Chris, but one issue still remain: how to generate those automatically, without any UI, and in a scalable format to be used in our LaTeX reports and maybe some multi-page poster.

So this weekend I implemented this tool and it's quite usable already! It's a Python+ElementTree+PyX application that parsers TaskJuggler's XML (tjx) and output PDF, PS or EPS, with PDF and PS being able to output segmented, multi page, poster documents.

Chenca is developing a more report oriented graph, generating LaTeX tables instead of drawings, he promised to publish it as well ;-)

Source is available at: http://barbieri-playground.googlecode.com/svn/python/taskjuggler-utils/ (SVN)

These days Marcelo asked for a prototype in Python and SDL (PyGame) to work on Nokia/maemo devices.

After a preliminary attempt using pygame.sprite.OrderedUpdates I realized it was way too slow. Since heavy operations are handled in C by SDL itself, that shouldn't happen.

After some hunting and code review, it was the way PyGame's OrderedUpdates (and RenderUpdates) does clear() and mark regions to be updated after draw() that was the culprit. Both clear and updated rectangles may overlap, causing SDL to operate on the same area more than once, which is awful.

So Chenca and I started to work on a way to split rectangles that overlap into smaller pieces, avoiding more than one covering the same area, I've implemented this algorithm in Python and now the code runs about 2-3 times faster :-)

I've written 3 new classes to help development with PyGame, you can get them and the example at my SVN: http://barbieri-playground.googlecode.com/svn/pygame/smart_render/

Chenca and I will try to provide some other utilities to make pygame development for Maemo easier, like these rectangle split in C, functions to blit images with per-pixel alpha faster and also one to blit per-pixel images added to image alpha (enable fade in/out of elements with pixel transparency). Stay tuned.

UPDATE: SDL (and thus PyGame) already provide accelerated blit functions for 16bpp, just enable RLEACCEL flag of your Surface. I'm using the following code to load images (check SVN link above):

img = pygame.image.load(filename)
img.set_alpha(255, RLEACCEL)
img = img.convert()