litled

November 17, 2008 GNOME, General 6 Comments

Today is my first day at litl. I’m joining a team which should be familiar to GNOME:rs in general: Johan Bilien, Lucas Rocha, Havoc Pennington and Tommi Komulainen. Exciting times!

Introspection hackfest at the Boston Summit

August 21, 2008 Blogroll, GNOME, General, PyGTK, Python, olpc Comments Off

We’re arranging an introspection hackfest at the Boston Summit! Thanks to the nice lads at the foundation we can have most of the participants flown over. Colin Walters, Jürg Billeter, Philip Van Hoof, I and hopefully Havoc Pennington is going to be there.

If you’re interested in language bindings or other uses of the introspection data, come by and help us out.

Oh, I almost forgot to say hi to Planet Python. Andrew was kind enough to add me there. My name is Johan Dahlin and I’m mostly working on Python related to GNOME, especially, Python bindings for GObject and Gtk., and Kiwi + Stoq of course. The introspection project is intended to make it easier to write language bindings for the Gnome stack, not only Python ones.

Generic CClosure marshaller using libffi

July 31, 2008 GNOME, General, PyGTK, Python, olpc 1 Comment

Marco: You can also use the libffi CClosure marshaller I wrote for PyGObject. If you use you don’t need to generate the marshal.list at all, it’ll figure out the signature and call the callback just by looking at the signals GValues.

I originally wrote it so that Edward could prototype playbin2 in gst-python and still being able to connect to signals created in python from GstElements written in C. I know that a couple of other projects are using that file by copying and pasting it while waiting for bug 401080 to be solved.

PyGObject activities

July 28, 2008 Blogroll, GNOME, General, PyGTK, Python, olpc 1 Comment

I’ve been spending quite a bit of time lately on PyGObject, the python bindings for GObject. This blog post will summarize the recent activies.

Code Generator move

One of the most important parts of the gtk python bindings lies within the code generator. This piece of software which was mostly written by James Henstridge, Gustavo Carneiro and I takes an API definition file (in scheme s-expression style) and output C glue which tell Python how to call the API in a library. For various reasons the code generator is mostly intended to be used by a GObject based library. It was originally written for PyGTK but has since been used in a number of other placs, most noticable gst-python contains a fork which various modifications. It has recently moved from the PyGTK package to PyGObject and can now easily be used by GObject based library which wishes to use it without depending on GTK+.

GIO

The principal motivation for moving the code generator from PyGTK to PyGObject was to be able to create GIO bindings. An initial set of bindings has been created for GIO. They are not complete yet, quite a bit of the API which takes async result parameters has not yet been written, but it should be perfectly usable by applications already. Please use it and let me know if there is any methods missing and I will gladly wrap them for you

GLib

One of the complaints over there years has been that it’s kind of weird to type gobject.MainLoop(), gobject.io_add_watch() etc, since these functions are not really related to GObject. Complain no more, they have now moved to a new module called just glib. It’s been quite hard to come up with any reasonable use cases for third party packages using glib but not gobject. I guess one of them is python bindings for Qt wishing to integrate with the python bindings for Gtk+. Qt already provides (optional) glib/mainloop integration, so perhaps this would be useful to them.

Porting to Python 3

This weekend I ported the glib and gobject modules over to be compilable against Python 3.0b2. It has been done in such a way that the source code is compatible with both the 2.x and 3.0 APIs of Python. To be able to do that I was forced to add a number of quite intrusive macros which takes care of the hard work. I’ve only managed to reach the point where it is possible to import the gobject module. The code generator and the gio bindings has not yet been ported. Even less has the testsuite been run, so this is just moderatly useful at this point. As part of porting this I had to make the python support in automake be compatible with python 3. Patches against git head of automake can be found here.

GIO python bindings

July 15, 2008 Blogroll, GNOME, General, PyGTK, Python, olpc 7 Comments

Late yesterday evening I did a new release of pygobject. The first one in about 10 months, I should do this more often I know. The most important thing featured in this release is the addition of GIO bindings. I know lots of you out there have been asking for this.

There’s still no official documentation included, but there’ll be in the near future as we have a couple of people working on it. While you wait, enjoy this simple example:

import gio
fp = gio.File("http://planet.gnome.org")
data = fp.read()
print data

We have also moved the code generator from PyGTK into PyGObject, this means that GObject bases libraries can be wrapped in python without having to depend on GTK+, this should be quite useful, I think.

I’d especially thank Paul Pogonyshev (doublep on irc) for this work on this release, he’s getting more and more involved in both PyGTK and PyGObject, thanks Paul!

Simplified tabbing support in Gtk+

July 12, 2008 GNOME, General 15 Comments

There has been a couple of posts recently on Planet GNOME mention the increase usage of tabs in applications. I decided to write up a quick patch for GTK+ which makes it even easier to add tab support. With the patch I applied you can just call a single method:

gtk_widget_set_use_tabs (widget, TRUE);

To get complete tab support in your application.

Emmanuele just reviewed it and it will soon be committed to SVN trunk of GTK+. I’m looking forward to applications migrating to this new simplified API!

Monday Quiz

July 7, 2008 General 10 Comments

In this quiz I am looking for 3 persons who are or have been syndicated by Planet GNOME.

Question 1: What are their relationship with the below mentioned projects/technologies?

Question 2: Who are they?

Person A

  • Norton Commander
  • Microsoft COM
  • Microsoft .NET Framework
  • Microsoft Excel
  • Microsoft Outlook
  • Microsoft Silverlight

Person B

  • Regedit
  • DCOP
  • KHTML

Person C

  • Apple iTunes
  • Spice3
  • Microsoft Project

Introduction to GObject Introspection

June 1, 2008 Blogroll, GNOME, General, PyGTK, Python, olpc 7 Comments 
This was also sent to gtk-devel today:
== Introduction ==

GObject-introspection is a package which will collect and extend the API
metadata for GObject based libraries. The main motivation of this work is to
centralize all introspection information required to write a language binding.

There are many other use cases as well, some of them are described at:

   http://live.gnome.org/GObjectIntrospection/

== Current status ==

The GObject-Introspection module/tarball contains the following:

     * An XML format called GIR containing introspection information
     * python package to create and parse the GIR format
     * scanner to generate GIR format from C source and headers

These components are also included, but needs to be ported to the GIR format:

     * a typelib similar to xpcom/msole which stores the information
       on disk in a binary format
     * a compiler to compile the typelib from a xml format (and vice versa)
     * C library to read the typelib

A separate SVN module called gir-repository has been created.
The idea is to create .gir files of all libraries available in the
the whole stack which language bindings can depend on.
Eventually the plan is to move the .gir files into the upstream projects
themselves, but that's likely to be a long process.

== GIR XML Format ==

The core of the GObject-introspection is an XML format which is called GIR (
GObject Introspection Repository) which contains the API introspection
metadata for a library or interface entity.

GIR currently contains three different XML namespaces:
  • core: contains features available in popular programming languages: classes, methods, functions, interfaces, properties, strings, enums etc.
  • c: contains features specific to the C language: identifiers, symbol names, C types
  • glib: contains features specific to GLib/GObject: signal, GType, flags, paramspec
The separation of different data in different namespaces allow you
to reuse it allows you to arbitrarily extend the metadata available
in different languages.

== Scanner ==

To be able to bootstrap the effort and make something which will be
available in a reasonable timeframe we've been working on a scanner
which parsers C sources and headers and extracts the metadata and
generates a GIR file.

This is likely to be used by most of the Gtk/GNOME stack, as it would
require the least amount of work, however it's not the only way to
use the GIR format nor GObject-Introspection.
In the future we might use something similar to CORBA IDL to define
the interface, as GIR is not meant to human editable.

In addition to the parsing the C headers, additional metadata will
be provided, likely by using source annotations in gtk-doc comments.

== Typelib ==

To be able to create efficient read introspection data we need a typelib, eg
an efficent disk format with a C API to access the internal data.
Matthias wrote one based on the XPCOM typelib which has not yet been
updated to the GIR format, it's instead the tools to compile it are still
using an older XML format.

The work on finishing the typelib is depending on having the GIR format
somewhat stable and at that point updating the existing tools to understand it.

== How can I help? ==

At this point I'd like to get more eyes at the current GIR format to make
sure that it contains the necessary information and in a way which will
be easy to parse/access.
I am currently working mainly on the scanner to be able to quickly get
a large amount API expressed in GIR files.

For more information, check out the wiki page:

   http://live.gnome.org/GObjectIntrospection/

And the gobject-introspection and gir-repository modules in GNOME SVN.

ASCII art User Interface mockups

May 6, 2008 GNOME, General, PyGTK, Python, olpc 19 Comments

I have the pleasure of knowing the great mpt. He actually spent a couple of months in Brazil back in 2006 and we ended up sharing the same apartment during this period. One of the great things he masters is the art of writing ascii art mockups of user interfaces As I am a mere beginner might not be the best person to explain this. However I will make an attempt to explain the basic principles, in the effort of having this written down somewhere.

In this blog post I will focus on commonly used interactive widgets available in Gtk+, since these are the ones I tend to care the most about.

GtkEntry

An entry is straight forward, you use brackets in the beginning and the end and underscores to fill up the allocated width of the widget:

[____________]

If you want a text, just replace the underscores with letters

[Hello World____]

GtkButton

Buttons are similar to entries, the main difference is the lack of underscores and the use of capital letters. Icons are usually ignored as they often are rather tricky to represent using the ASCII alphabet. A cancel button looks like this:

[ CANCEL ]

GtkToggleButton and GtkRadioButton

Toggle buttons uses brackets around the toggle part and no brackets around the rest. If the value of the radio should be active, use a lowercase x to say so:

[ ] Buy milk and cheese for breakfast

[x] Eat strawberries after lunch

Radio buttons are similar but uses parenthesis and o, eg:

(o) Fresh fish

( ) Rotten eggs

GtkSpinButton

Spin buttons are similar to entries, but they have two small arrows on the right hand side. To represent the arrows, use H:

[1234 H]

This might not look good in all fonts, but it’s the best that can be done, at least as far as I know.

GtkComboBox

A combobox tend to be represented again by using brackes in the beginning and the end. To represent the arrow, use a lower case v and separate it from the text by using a | (pipe) sign.

[ Stockholm | v]

GtkDialog

Prett simple, use _ (underscore) and | (pipe) for the borders, titles and window manager buttons can usually be skipped since they are mostly noise to us in this context:

 ________________________________
|                                |
| Do you want to close the open  |
| document and lose the changes  |
| made to it?                    |
|         [ CONTINUE ] [ QUIT ]  |
|________________________________|




These  are the widgets I usually end up using in my mockups. Have any missed any important onces? Or I have I done any serious mistakes? Comments appreciated!






 Read the rest…

	


		

		
Using GtkListStore in Python

		May 6, 2008
		GNOME,  General,  PyGTK,  Python
		4 Comments
		
		
I often end up reading code using GtkListStore in Python, either in existing projects or on irc when someone asks me to fix their program. It’s pretty straight-forward to using the GtkTreeModel interface and it’s various implementations such as GtkListStore and GtkTreeStore. However, due to lack of proper documentation, the small pieces of Python sugar on top of the raw C wrappers is seldomly used. In this blog post I will attempt to document the most useful one in hope that some popular search engines will pick this up and help someone in the future.


Construction 


For starters, let’s look into construction of GtkListStores:


model = gtk.ListStore(gobject.TYPE_STRING, gobject.TYPE_INT, gobject.TYPE_FLOAT)


This creates a liststore with three columns, a string, an integer and a float. The column types are specified using the constants available in the gobject python module. Since I’m hardly a normal person, I’ll immediatelly get frustrated when I see that kind of code. Instead, I wish people could write the following code instead, which is shorter and thus easier to parse:


model = gtk.ListStore(str, int, float)


It does exactly the same things, interally str is mapped to the gobject.TYPE_STRING constant and so on.


Appending data


At some point during the life time of a program you want to insert data into a model. A common way of doing is that is


the following:


iter = model.append()


model.set(iter, 0, “foobar”)


model.set(iter, 1, 1138)


model.set(iter, 2, 3.14)


This appends a new row and sets the values”foobar”,1138 and 3.14 to the three columns. You can avoid the three different calls by sending in a list to append as the first argument, eg:


model.append(["foobar", 1138, 3.14])


Which again, is the exact same thing. (Modula saving a reference to the inserted tree iter of course)


Fetching values 


To fetch a value from the a model you usually get an iter, for example from a selection:


model, path = selection.get_selected()


value = model.get_value(model.get_iter(path) , 0)


Two things can be simplified here: First of all we take advantage that model implementes a list like api, you can just access the model list a list, eg: model[n]. Secondly you can send in either an index, path or iter as n, so the example above is simplified to:


model, path = selection.get_selected()


value = model[path][0]


Iteration 


Iteration over all the values in the model is usually done something like this:


iter = model.get_iter_first()


while True:


value = model.get_value(iter, 0)


iter = model.iter_next(iter)


if iter is None:


break






Which can also be considerably simplified:


for row in model:


value = row[0]




Also note that using the variable name iter in a python program is always wrong, since there is a builtin variable with the same name. Avoid the name iter, and use for instance titer instead, which is almost as short and a bit clearer.

	



« Previous Entries