Rat, more easy PyGTK dialogs

We have been indulging in some Kiwi-love recently. You may have read the recent blog about easy PyGTK dialogs with Kiwi. After a chat with the author of another PyGTK helper library (called rat) and available at http://python-rat.berlios.de/, who also happens to be a good friend of mine, I have decided to blog a similar example of dialogs using rat.

Rat has a similar set of dialogs (a few extra, and a few missing). We shall start with a simple error dialog:


>>> from rat.hig import error
>>> error('You made a mess in your trousers',
... 'Or maybe the mess was already there',
... title='A big mess!')



A similarly simple API, and it gives us a similarly HIG-compliant error dialog:

Rat does not contain a yes/no dialog, but it does contain an ok/cancel dialog. Usage
is again very quick and simple:


>>> from rat.hig import ok_cancel
>>> from gtk import RESPONSE_OK
>>> r = ok_cancel('Are you sure you want to destroy something?',
... 'This Could be as evil as eval!',
... title='Please ensure...')
>>> r == RESPONSE_OK
True
The resultant dialog does everything you want it to, and can be used for the same purpose as the Kiwi yes/no dialog.


Mmmm, HIG-love!

The extra dialog I want to have a look at is something only Rat has. This is the "Save Changes" dialog. It is designed for any editing application, where the user may wish to close the application while there are unsaved files or buffers e.g. a text editor, or graphical editing program. A small example:


>>> from rat.hig import save_changes
>>> files_to_save, response = save_changes(
... ['foo.txt', 'bar.txt', 'baz.txt'],
... title='You asked to quit the application')
>>> files_to_save
['bar.txt', 'baz.txt']

Amazing! And to show you how wonderfully beautiful it looks:

You will notice that of the 3 files passed to the dialog call, we selected two of them, and these are the two returned in the files_to_save variable. Lovely.

I will conclude here that although there are two ways (Rat and Kiwi) of performing similar tasks, and choice is always good, each library contains things that the other doesn't. The maintainers of each library know eachother well. Isn't it time that they collaborate and join into a single library? We, the PyGTK developers will be the ultimate winners!

Popular posts from this blog

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

ESP-IDF for Arduino Users, Tutorials Part 2: Delay

How to install IronPython2 with Mono on Ubuntu