Posts

Showing posts from November, 2007

Using Storm and SQLite in Multithreaded Web Applications

Pysqlite doesn't allow you to access the same connection from different threads. The pysqlite manual says: "SQLite connections/cursors can only safely be used in the same thread they were created in." When using Storm (the ORM) with Werkzeug (the WSGI utility lib) we suffer from the problem that the Werkzeug reloader runs code in a thread. Ok this feature is not exactly important in a production environment, but I can't guarantee that whatever platform I will be deploying the application on will not be threaded, so database access should be proofed against this. The solution? The Storm manual mentions that you should use a Store/connection per thread. Someone has already done this with the Middlestorm application, which provides a threadsafe store in the WSGI environ. Rightly or wrongly (since I really don't want to have to wait to have a WSGI environ to get the store instance), and I am not exactly sure this kind of thing should be middleware, but that

Leopard Spaces Is Unusable

With Leopard, OS X finally has a bundled virtual desktop implementation. Pre-leopard I used a (now unmaintained) 3rd-party app called VirtueDesktops to get this feature, and while not perfect, it worked fairly well. It certainly didn't annoy me. Spaces, on the other hand, does annoy me, to the extent that I find it unusable. Spaces SWITCHES MY DAMN DESKTOP WITHOUT ME ASKING IT TO. When I command-tab between applications, Spaces changes to the desktop with the active window. Now, at first when I encountered this feature, I thought "oh, that's pretty nice," and indeed it would be ok if it worked consistently. It doesn't, though. Usually Spaces switches correctly, but occasionally (say every 5 or 10 application-switches) it switches to the wrong desktop! If you don't believe me, try this out: Open two terminals, and put them on different desktops. Now open a browser on one of these desktops. Command-tab between the browser and the terminal a few times, and see w

Desktop Widgets with PyGTK, Launchpad Remote Control

Image
""" Desktop Widgets with PyGTK, Launchpad Remote Control We shall today be looking at a dumb hack I glanced upon while foolishly reading the list of GDK Constants in the PyGTK documentation. This hack sets the type hint of a GTK Window instance (the thing that tells the window manager how to treat it) as a desktop window, and hence embeds the thing in the desktop. It even works quite well: The window and widgets appear in the desktop The widgets are raised when the "Show desktop" command happens The widgets appear on all desktops (in Gnome and XFCE4, but not in KDE) The widgets appear fully functional So I got all excited and tried to think of an awesome use-case as the first plugin for a new kind of desktop widget framework. One which couldn't care less about eye-candy, and focussed on truly functional and useful desktop-based applets. As a friend commented while I was discussing the idea: "I am often hacking away in emacs when I decide that I want to