The second package for today is yet another initial release: termconnect is a Python module for accessing terminal based protocols such as Telnet and SSH.
Because the telnet module that is shipped with Python is incomplete, poorly implemented, and does not have a generic API, termconnect was written to provide a clean and simple replacement.

The example code is here:

from termconnect.Telnet import Transport
#from termconnect.SSH import Transport

conn = Transport()
conn.connect("127.0.0.1") # The default port is 21
conn.authenticate("myuser", "mypassword")
conn.execute("ls -l")
conn.send("exit\r")
conn.close()

The API for SSH is absolutely identical, so changing the protocol in your code is a matter of changing the import statement - that is the way it ought to be. In addition, there is a Dummy protocol adapter that may be used for testing your code - it is a fake protocol that emulates a device.

The code is already pretty well tested, so I am confident that this initial release is mature enough for production environments.

Links:
Download
Project page
API documentation
Handbook (PDF)

Here is another initial release: SpiffWorkQueue is an asynchronous, multi-threaded queue. The following example shows how to execute two tasks in parallel. In the example, each task consists of a sequence of two actions:

from SpiffWorkQueue import WorkQueue, Sequence, Action

class MyAction(Action):
    def __init__(self, name):
        Action.__init__(self, name)

    def execute(self, lock, global_context, context):
        print "Hello world"

queue    = WorkQueue()
actions1 = [MyAction("one"),   MyAction("two")]
actions2 = [MyAction("three"), MyAction("four")]
queue.enqueue(Sequence(actions = actions1))
queue.enqueue(Sequence(actions = actions2))

queue.start()
while queue.get_length() > 0:
    pass
queue.shutdown()

Links:
Download
Project page
API documentation
Handbook (PDF)

SpiffSignal is a simple signal/event mechanism for Python. This is the initial release. Instead of screenshots, look at the following example that prints “hello world”:

from SpiffSignal import Trackable

class WatchMe(Trackable):
    def __init__(self):
        Trackable.__init__(self)

    def do_something(self):
        self.signal_emit('did-something', 'hello world')

def my_callback(arg):
    print arg

foo = WatchMe()
foo.signal_connect('did-something', my_callback)
foo.do_something()

Links:
Download
Project page
API documentation
Handbook (PDF)

I am proud to announce the release of a new version of Gip.

Release 1.7.0 adds several new translations, fixes some potential build problems and also adds a better desktop file. Thanks to Henry-Nicolas Tourneur for improving the build infrastructure to make it easier to use for packagers. Also thanks to all translators, including:

bg: Yavor Doganov
da: Keld Simonsen
de: Samuel Abels
es: Víctor Alonso
eu: Mikel Olasagasti
fi: Jorma Karvonen
fr: Michel Robitaille
ga: Kevin Scannell
id: Andhika Padmawan
ms: Sharuzzaman Ahmat Raslan
nl: Taco Witte
pl: Michał Trzebiatowski
pt: Gian Jaskulski
rm: Florian Verdet
ru: Peter Astakhov
rw: Steven Michael Murphy
sk: Andrej Kacian
sr: Aleksandar Jelenak
sv: Daniel Nylander
tr: Orhan Veli Esen
vi: Clytie Siddall
zh_CN: Ji ZhengYu
zh_TW: Wei-Lun Chao

The updated release can be downloaded here:
http://dl.debain.org/gip/gip-1.7.0-1.tar.gz

The project page is here:
http://code.google.com/p/gip/

After almost half a year of silence, I am pleased to make an announce:

Starting on Monday, I will dump large amounts of fresh free software on the public.

(Photo by Guille, some rights reserved.)

This had a long time coming; for about a year now I spent most of my programming time cleaning up, redesigning, and improving my projects, shaping them into higher quality software packages and simplifying everything from user interfaces to APIs to the build procedures. To me this is also an exercise in simplifying the release process. As a first step, I removed all of the project pages from my homepage, instead integrating the content on the project pages on code.google.com. I am hoping that this will save me from some maintenance work in the future.

So what is the plan? I will release at least two software packages every single day, for a week. That means all kinds of software: Some for end users, some for the web, some for Python developers; some are major updates or new releases, some bring higher quality and additional polish.

Looks cool and useful: http://code.google.com/p/protobuf/

With help from yura_dev in #anjuta I just figured out how to add a .desktop file to your project in Anjuta:

• Create the desktop file, name it test.desktop.in.in and place it in your project root.
• Edit Makefile.am and add the following lines:

desktopdir = ${prefix}/share/applications
desktop_in_file = test.desktop.in
desktop_DATA = $(desktop_in_file:.desktop.in=.desktop)
@INTLTOOL_DESKTOP_RULE@

%.desktop.in: %.desktop.in.in
sed -e 's,[@]PACKAGE_PIXMAPS_DIR[@],@datadir@,g’ $< > $@

• Edit the line that says “sed -e …” according to whichever variables you want to replace in your desktop.in.in file.
• Make sure that the replacement variables are defined in your project. You can do this under Project -> Properties -> Variables.

If this does not work then I will probably not be able to help you. I do hope Autotools finally die a quick yet painful death.

Proof by example (search for “proof by”):

• A person is currently looking at something cluttered and wants to fix the situation. In other words, the premise is a feeling of clutter, and the intended outcome is tidiness. In English, the verb relating to such situations most often refers to the premise (clutter) rather than the intended outcome (tidiness), in this case to unclutter. In contrast, the German translation is “aufräumen”, referencing directly to the intended outcome (aufgeräumt).
• The same is true for the time axis. For example, “to be sick of something” directly refers to a current feeling of sickness. The German language provides several similar constructs:
  • “ich fühle mich krank” (”i feel sick”) refers to an illness.
  • “es leid sein” refers to a general feeling of tired discomfort rather than a pain (similar to “to be tired of something”).
  • “ich bin es überdrüssig” does not have a direct translation, but is close to “i’ve got enough”.
  • “es macht mich krank” (”it makes me sick”) refers to an ongoing process that has yet to be completed.

  However, there is no German construct referring to a current feeling of circumstance-induced sickness.

Of course, there are a lot of exceptions to these rules, but I noticed them to be true in many cases. As a result, I find that English is often a lot better at expressing feelings. Also, English is not my native language, so perhaps I’m just missing something.

There has been talk about how to change the GNOME platform to make it easier to introduce changes without alienating developers by breaking API/ABI in short intervals.

• Building an abstraction from IDL for any public API sounds like a cool plan, because
  • A thin abstraction decouples from third party libraries that are used in GNOME but can’t be ported to our namespace. Gstreamer or even Cairo are examples that may benefit from such a wrapper. I can’t think of a better way to accomplish a consistent platform (a prime example here is Mono, IMO).
  • This could potentially turn the task of generating language bindings into a fully automated process, making it easy to integrate complete platform bindings into GNOME’s regular release cycle. Now if that does not rock, I don’t know what does.
• As for the desktop part of the platform, I still believe that switching to a GNOME certification based solution is a better way to do this. Currently, GNOME is a fixed set of applications, and what is included in this set is decided mostly on the desktop-devel-list. Taking part in some of the discussions sometimes left a sour taste: I do believe that most (if not all) of the current GNOME applications took their place deservedly, but some alternative solutions never got a real chance simply because the author was not well known in the GNOME community. I believe that a certification based desktop would make this a little easier - if more than one tool meets GNOME’s standards (HIG, API/ABI promise, …) and all are equally good, then they all deserve a GNOME certificate, leaving the task of choosing the shipped application to distributors.

Also, the developer base could benefit from integrating the Win32 and Quartz ports of Gtk into the regular release.