Desktop Widgets with PyGTK, Launchpad Remote Control

"""
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 know what the
weather is like, but I am too lazy to look out the window, so I use my weather
desklet."

And that is the point, these desklet things are absolutely useless in my
opinion. I thought and thought and I came up with a handful of barely useful
things, which are too dumb to even mention. I would be grateful if anyone has
any ideas.

Maybe I am the problem. I don't use a desktop at all. I turn the feature off
in XFCE4 (my preferred desktop environment) and don't have to suffer icons and
right click and things like this. (Incidentally the hack works on noremal
desktops, even preserving the original desktop functionality - so you can
click on icons and see the weather at the same time.

So my lack of real-world use-case discouraged me from attempting the
framework. But I would feel bad not to mention it here at least.

A nice simple thought was to use Malone's XMLRPC to read any numbered bug from
the launchpad and display it on the desktop. As I say this isn't a real world
application, since you would just fire up a browser. And then I realised that
you can only use the Malone XMLRPC for filing bugs.

So I guess it will be a less pleasant thing that just opens your browser at
the bug page. Hopefully Launchpad will add simple things like this to the API
sooner rather than later.

So, on to the process:

First let's get the Launchpad bit out of the way

"""

# Python standard library module that does portable web-browser opening
import webbrowser
# You could make the product optional
BASE_URL = 'http://bugs.launchpad.net/pida/+bug/%s'

def navigate_bug(number):
  """
  Open the web browser at the required URL
  """
  url = BASE_URL % number
  webbrowser.open(url)
"""
Now we can concentrate on the more interesting desktop embedding
"""

import gtk
# Create the user interface for the application
class BugEntry(object):
"""
A miniature user interface for entering a bug number.
"""
def __init__(self):
   # an entry, a button, and a box to put them in
   hb = gtk.HBox()
   self.entry = gtk.Entry()
   hb.pack_start(self.entry)
   button = gtk.Button(stock=gtk.STOCK_OK)
   hb.pack_start(button, expand=False)

   # Connect a signal callback for the button
   button.connect('clicked', self.on_button_clicked)

   # A window to hold it all
   self.window = gtk.Window()

   # Set the type hint on the window to make the window manager think it
   # is a desktop
   self.window.set_type_hint(gtk.gdk.WINDOW_TYPE_HINT_DESKTOP)
   self.window.add(hb)

   # Don't forget to size and move your window where you want it
   self.window.move(100, 100)
   # If you wan to resize it: self.window.resize(x, y)
   self.window.show_all()

def on_button_clicked(self, button):
   """
   Called when the button is clicked
   """
   # A sane implementation would catch errors in the conversion,
   # But we just call the web browser launcher function:
   navigate_bug(self.entry.get_text())


if __name__ == '__main__':
   # Instantiate the interface, and run the gtk main loop
   be = BugEntry()
   gtk.main()
"""
Ok it looks really ugly, but you can see the promise there, The main thing is
that it really really works.




If anyone can think of a decent thing to do with this, please let me know!
"""

Popular posts from this blog

PyGTK, Py2exe, and Inno setup for single-file Windows installers

I am lucky, as part of my job, I get to code PyGTK. The downside is of course that I have to deploy these applications on Windows. Now these Windows users (especially at the price they are paying for this stuff) don't install dependencies, don't understand what a scripting language or interpreter is, and frankly they should not have to. Unfortunately, the list of dependencies for a PyGTK application (at the very minimum) is Python, GTK, PyGTK, PyGObject, PyCairo. 5 installers! So very early on in this project I found the way to give them exactly what they want and deserve, a single-file executable installer. There are a few guides online about how to achieve this, but none seem to work, and none are particularly new. How do we achieve this? The toolchain involved consists of two elements: 1. Py2exe website 2. Inno Setup website NOTE: The documentation for all the tools used is extensive, I will not repeat everything in there. Py2exe Py2exe is a distutils extension that searches...
Read more

Kiwi proxy widgets, a common widget API

Image
While we are on the notion of Kiwi , the PyGTK helper library, we should be discussing the proxy widgets. They offer a certain set of advantages over their plain PyGTK counterparts: They have a common signal emission API for change in content They offer a common API for setting and reading their value. They offer validation, and coercion They contain a few general improvements over the plain PyGTK widgets What does this mean? Simply it means you can make any data widget (eg Entry, CheckButton, Combo etc), you can connect its signal "content-changed", you can read the data with widget.read(), and set the value with widget.update(). If you have read any of the previous blogs about adapting Zope.schema fields to widgets, and you are alert, you will notice that this is amazingly useful. It means that we can define an interface for a general InputWidget type, something like: class IInputWidget(Interface): def read(): """Read the value in the widget"""...
Read more

Using threads in PyGTK

Well, all this thought of asynchronicity is getting to me. But since we mentioned how to use subprocesses and Twisted, I think it is only fair to talk a bit about threads. So, what will we be doing? Create an abstraction for running threads in PyGTK Use it Now the thing which we will be wanting to run is a generator, call it "take_really_long". And it will surely block, and might be a bit intensive, and well we obviously need something asynchronous. A generator is a bit nicer to use than a single plain long-running function, because we can update the user interface every time it returns, making it much much easier to do things like Progress Bars. You must remember two things when using threads with PyGTK: 1. GTK Threads must be initialised with gtk.gdk.threads_init: import gtk gtk.gdk.threads_init() 2. Any code that modifies the UI (basically any code) that is called from outside the main thread must be pushed into the main thread and called asynchronously in the main loop, w...
Read more