J5’s Blog

Piling on to Colin’s post:

If you knew what I needed to do already why didn’t you just do it?  Just popping up the dialog that I now have to go searching for would have been somewhat passable.  Besides Jython is not even usable right now so just assume I want my system python.  That is just plain laziness and the reason why I keep trying eclipse and then thinking better of it a couple of minutes later.

To be fair I hear it is a great app but I can’t get past the UI.  It gets in my way.  The run dialog alone has forever traumatized me.  Let’s see if the bugzilla plugin will allow me to file this bug or I will be back with another ranty update. I’m going to try to give eclipse a longer benefit of the doubt but if I run into much more of this it’s going to take a lot of people telling me it has since gotten better, before I try again.

I just noticed PiTiVi was upgraded to 0.11.1 at some point in Fedora 8 so I gave it a run. While there are show stopper bugs (which I will file in due time) and it doesn’t do much yet, it is almost to the point of what I need in a video editor. The important part is the UI is intuitive and easy to use. Here are a list of features I would need for the bare minimum of using PiTiVi as an editor:

• Cross fades
  • Even if it is a simple, non-configurable cross fade, cross fades really add polish between harsh cuts.
  • Fading and unfading audio is also important
• Support for image files as frames
  • This is the quick a dirty way to do intros and credits (eventually I would want direct text overlays)
• decoupling the audio from the video
• quick timeline resize of audio and video in the advanced view
  • The clip editor in the simple view is fine for precise editting but having the ability to drag either end of a clip to resize it in the timeline makes it easy to sync up with other elements in the timeline

That’s it. While I would like more functionality such as voice overs, unlimited tracks, multiple effects and overlays, the above list is all I need to support the simple editing that I do.

Just thought I would take “release early, release often” to heart. Hot on the heels of 0.1.7 is a major feature release 0.1.8. As of this version all complex and simple D-Bus types are displayed properly in the UI even if they are nested.

Please let me know if you ever see an Error(<some char>) in the parameter lists.

As usual:

Homepage: http://d-feet.fedorahosted.org

Tarball: http://johnp.fedorapeople.org/d-feet-0.1.8.tar.gz

Rawhide and Fedora 8: yum install d-feet

I’ve been so busy lately I just noticed my Decorators on a Dime article was published by Python Magazine.  Pretty neat!

A new D-Feet D-Bus Debugger has been released. Some cool new features have been added and a lot of the code has been reorganized.

• no longer restricted to the System and Session busses
  • using the connection dialog you can attach to any bus address you need
  • 
• each bus tab is restored on startup if the address exists
  • 
• execute button makes executing methods more descoverable
  • button in toolbar become sensitive when you select a method from the introspect data
  • 
  • 
• icons show up if app associated with a name has a toplevel window
  • based on libwnck so the application needs to have mapped a toplevel window
  • 
• initial support for icons on introspect nodes
  • 
• syntax highlighting and nicer formatting for methods and signals
  • unicode arrow used for return values of methods (Ray Strode)
  • 
• support for property lists in the introspect data (Marcel Holtmann)
• move to gtk.Builder for UI
  • requires PyGtk >= 2.12.0 and Gtk+ >= 2.12.0

Get It

• tarball: http://johnp.fedorapeople.org/d-feet-0.1.6.tar.gz
• git: git clone git://git.fedoraproject.org/git/hosted/d-feet
  

I’ve been playing around with a little tool for debugging applications on the bus. It is far from done but I decided to release it now that it has become useful. Right now you can see all names on the Session and System buses and get information on the objects and interfaces they export.

Current Features

• View names on the session and system bus
• View exported objects, interfaces, methods and signals
• View the full command line of services on the bus
• Execute methods with parameters on the bus and see their return values

Planed Features

• Attach to any address
• Watch, edit and play back method calls
• Watch signals
• Attach scripted actions to triggers
• Profiler for D-Bus calls
• Assistant for creating async call chains

Info

Homepage: http://hosted.fedoraproject.org/projects/d-feet/
Tarball: http://johnp.fedorapeople.org/d-feet-0.1.4.tar.gz
Fedora: yum install d-feet
(Should be built for Rawhide, F-8 and F-7 though it may take a bit to be pushed as an update to F-8 and F-7)

Guido just released it today.

I was just reading Guido’s status update for Python 3000.  Though I have yet to go over the PEPs, his blog entry talks about some of the major changes, some of which effect the D-Bus python bindings and Sugar.  None of this is worrisome but are things we should keep an eye on while developing.

Unicode

I’m not sure if the unicode changes will help or hurt us in anyway though I will suspect they will help in that Python will be more unicode friendly.

The inclusion of mutable byte literals however will make it easier to support the array of byte type in D-Bus.  We’ve been flailing our arms on this issue and though Simon has come up with an elegant solution in recent releases, it is always nice to have support in the language itself.

Print and Formatting

Printing and formatting seems to be to be the most invasive change though I suspect the conversion tools will take care of this.

The print command now becomes an actual function so we should most likely replace all occurrences of print ‘foo’ to read print(’foo’) which will work in current python and python 3000.

Formatting will be completely different, changing from the ugly % operator to a format method on string classes.  While I do agree with the need for this change, we do use this everywhere and there will be no good way to be backwards compatible here.  This makes it a bit of a bite the bullet when we move to Python 2.6 sort of thing as Python 2.6 will support the older and newer APIs with the older ones spewing warnings.  We may just want to write a utility function for activity authors to use which will shield them from this change.

Class Decorators

I kind of wanted to have these when designing the decorator syntax for exported classes.  Instead I used metaclasses which means you have to inherit from dbus.service.Object in order to export your object over the bus.  This leads us to having to do hacks in order to support multiple inheritance such as the newly added metaclasses for exporting classes which need to inherit from GObjects.

We may wish to explore using class decorators as a more flexible way for exporting objects in the future though there are behavioral questions to work out.  For instance what do you do when an internal method such as Introspect is also implemented in the class.

Metaclasses

In the future metaclasses will be specified via a class keyword (i.e. metaclass=MyMeta) instead of setting the magic __metaclass__ variable.  D-Bus simply will have to switch over and most likely support two releases for a short while.

Method Signatures

Python is getting typed…sort of.  Methods and functions will be able to specify a type for its parameters and return value.  These are only annotations and do not have any meaning to python.  For instance:

def foobar(a: Integer, b: Sequence) -> String:
…

We can however deprecate the in and out signature keywords in D-Bus’ method and signal decorators and use this instead.

Sugar should also use this when we decide to move, to make the code clearer and allow debugging tools to have more context.

Conclusion

I’m sure there are other things that will bite us.  I’m going to keep an eye on things and as soon as the alpha comes out start running some test.  This is a long way off and with Python 2.6 giving us time to move with a migration path it is even a longer way off though at some point it will cause us pain and should be tracked to minimize the impact.

As it currently stands the Python team expects the alpha to come out some time in August with a goal of releasing Python 3.0 (which is the stable release of Python 3000) about a year later.  Some months before Python 3.0 is released, Python 2.6 will be released and will roughly be the same as Python 2.5 plus all of the new bits that will be in Python 3.0, or at least the bits that we need for a orderly migration.

It is my hope that Python 3.0 will make python much cleaner and easy to support in the long run.  If it achieves those goals then it is worth a little bit of pain in the short term.

I am in the middle of re-factoring the Block Party codebase to be more object oriented so I can easily scale the graphics and add multiplayer support. In the process I changed some algorithms around to make them clearer and more streamlined. I got the code to working fairly well but there was one weird bug that was stumping me. When the blocks got stacked to a certain height they started drawing trails from the top of the screen to where they ended up resting. I couldn’t figure out what was going on because all of my printouts showed that I was only writing into the game grid at the proper x, y coordinates. . I then decided to print out the whole game grid every time I placed a block. Here is what I came up with:

As it turns out my optimizations of the line dropping code was the culprit. I was doing pretty much the same thing as the old code except the old code worked by deep copying the game grid every time it did a change. My problem came down to one simple line in the algorithms:

for ii in range(clearlines[i] - 1, nextclearline, -1):
    self.grid[ii + i + 1] = self.grid[ii]

Changing it to this fixed the issue

for ii in range(clearlines[i] - 1, nextclearline, -1):
    self.grid[ii + i + 1] = list(self.grid[ii])

Notice before I was copying the address of the row into its dropped position. In the old code we were copying between two different grids so this didn’t matter. I’ve changed it to use the same grid when dropping lines. What would happen is every time a line was dropped the top row’s address would be copied to the next row but the top row would not get a list. In essence the top two rows would be the same list. Every time after that a line was dropped the next row would get the same list until your blocks stacked high enough and wrote into one of those rows. After that it is sort of like crossing the streams in Ghost Busters, bad mojo would happen, except this time I don’t think you would save the world from Zuul.

The solution, and I should have known better, was to make sure the row is copied instead of assigned. A further optimized solution would have been to special case the top row and just create a new list for that and do the assignments for the rest of the rows. Something like this should do just fine:

for ii in range(clearlines[i] - 1, nextclearline, -1):
    self.grid[ii + i + 1] = self.grid[ii]

#row 0 is just there for padding so we can copy ourself
self.grid[0] = list(self.grid[0])

My article is up on Red Hat Magazine. It is the first part in a series on porting a PyGTK application, in this case a game, to the OLPC Sugar environment. This article goes into how the game actually works. The next release in the series, which is being scoured by the editors now, will detail how to quickly make Block Party play nice in Sugar. Future articles will expand on this by cleaning up the source code into classes, porting the gdk drawing layer to cairo, adding multiplayer functionality and hooking up to Tubes and the XO’s presence service to do networking.

This will also be the basis for my talk/tutorial at GUADEC as there is something to learn for Sugar, GTK+ and Python hackers.