<?xml version="1.0" encoding="iso-8859-1"?>
<!-- name="generator" content="pyblosxom/1.4.3 01/10/2008" -->
<!DOCTYPE rss PUBLIC "-//Netscape Communications//DTD RSS 0.91//EN" "http://my.netscape.com/publish/formats/rss-0.91.dtd">

<rss version="0.91">
<channel>
<title>Pete Ryland's Web Log   </title>
<link>http://pdr.cx/~pdr/blog</link>
<description>I didn't want a blog but they made me do it.</description>
<language>en</language>
<item>
  <title>An Evening with William Gibson</title>
  <link>http://pdr.cx/~pdr/blog/geekstuff/gibson.html</link>
  <description><![CDATA[
<p>Last night I attended a quite memorable event entitled <a
href="http://www.sci-fi-london.com/news/article/1183989120/8">An Evening with
William Gibson</a>.  The author of classics <i>Neuromancer</i> and <i>Pattern
Recognition</i>, Mr Gibson read from chapter two of his new book <i>Spook
Country</i>, which he indicated was orignially intended to be the primary
chapter.  To be honest, his oratory skills pale in comparison to his
story-writing ability, but it was great to be read to by the author
himself.</p>

<p>The reading was followed by an interview on stage with <a
href="http://en.wikipedia.org/wiki/John_Sutherland">John Sutherland</a>, with
questions from the floor after that.  There was also the obligatory signing
once the formal part was over.</p>

<p>Many topics were discussed but a few topics recurred and stuck with me.
One was the political nature of the new book compared with the previous books
to which he stated that he wouldn't be offended if someone considered
<i>Neuromancer</i> (which was set some time in the future) anti-Regan, and in
the same way, <i>Spook Country</i> (which I haven't yet read, but is set in the
very near future) could be called by someone anti-Bush without causing offence
to the author.  I liked the way he phrased the sentiment, but his thinking is
that all his books have some political angle, and the time of the setting makes
little difference.</p>

<p>Reference was also repeatedly made to <a
href="http://www.nodemagazine.com/">Node Magazine</a> and the interactiveness
of modern fiction.  He considers that we are already in a world of interactive
fiction and that he planted many pages on the internet for people to find when
reading his books and performing web searches on the characters and other
things mentioned in the narrative.  This was very much the case with <i>Spook
Country</i> but was also the case with Pattern Recognition but to a much
smaller degree, and with less community involvement.</p>

<p>He mentioned he'd been working that day on the Wikipedia entry for the <a
href="http://en.wikipedia.org/wiki/Hubertus_Bigend">Bigend</a> character in the
book, which raised a chuckle from Prof Sutherland and he offered a more
French-like pronounciation to replace Mr Gibson's overtly Engligh-based take on
the fictional name.</p>

<p>See also:
  <ul>
    <li>the official <a href="http://www.williamgibsonbooks.com/">William Gibson Books</a> site,
    <li>the (unofficial) <a href="http://www.spookcountry.co.uk/">Spook Country UK Blog</a>, which has a brief write-up of the evening,</li>
    <li>the (unofficial) <a href="http://williamgibsonboard.com/">William Gibson Board</a> whose members were out in force and in style,</li>
    <li>Flickr's collection of <a href="http://flickr.com/search/?q=william%20gibson%20london&w=all&m=tags">photos of the evening</a>.</li>
  </ul>
</p>

]]></description>
</item>

<item>
  <title>Loop The Loop</title>
  <link>http://pdr.cx/~pdr/blog/geekstuff/looptheloop_solver.html</link>
  <description><![CDATA[
<p>I am quite fond of the <a
href="http://en.wikipedia.org/wiki/Slither_Link">Loop The Loop (aka Slither
Link) puzzles</a> so I decided to write a <a
href="/~pdr/looptheloop_recursive.py">solver in python</a> for them.  It reads
in files like this <a href="/~pdr/kojima034.txt">example puzzle file</a>.  It
wasn't very quick, so I ported it to this <a href="/~pdr/ltlr.tar.gz">C
version</a> which is much much quicker.</p>

]]></description>
</item>

<item>
  <title>DStats</title>
  <link>http://pdr.cx/~pdr/blog/geekstuff/dstats.html</link>
  <description><![CDATA[
<p>I was playing with <a href="http://code.google.com/webtoolkit/"><acronym
title="Google Web Toolkit">GWT</acronym></a> the other day, and with <a
href="http://oss.oetiker.ch/rrdtool/"><acronym title="Round Robin Database
Tool">RRDtool</acronym></a> as well, and made a little stats generation thing
for my computers at home:</p>
<a href="/~pdr/images/dstats_screenshot.png"><img
src="/~pdr/images/dstats_screenshot_small.png"></a>
<p>You can see it live too at <a href="/dstats/">http://pdr.cx/dstats/</a> but
note that it will come up with a broken image the first time you load it (I
have fixed that now, but it's not in a version ready for the live site) so just
click on the broken image to select the server, statistic and time period.</p>
<p>I don't have exactly oodles of outgoing bandwidth, but locally it is very
quick to load.  It updates every minute, and the stats are acurate to the
minute with no real lag involved.  It can actually be quite difficult to see
the graph moving but believe me, it actually is - no more refresh meta tags for
updating stats pages!</p>

]]></description>
</item>

<item>
  <title>EGG! Prototype 2!</title>
  <link>http://pdr.cx/~pdr/blog/geekstuff/egg20061018.html</link>
  <description><![CDATA[
<p>And here it is: <a
href="http://pdr.cx/~pdr/egg20061018.tar.gz">egg20061018.tar.gz</a> complete
with two example applications as described below.</p>
<p>A week on from last week's release and it has really moved on in leaps and
bounds.  The following is a list of the recent improvements:
<ul>
  <li>The variety of decorators has been replaced with one,
    <code>egg.eggify</code>, which intelligently decides how to wrap the
    method</li>
  <li>Toolbar support has been added</li>
  <li>Statusbar support has been added</li>
</ul></p>
Internally, the biggest change is that the wrapper now replaces the callback
method with a (callable) object of type Egg.  This turns out to be much more
efficient than simply adding attributes to the existing function, although
there is a tradeoff with the time it takes for the <code>getwidget()</code> et
al calls.</p>
<p>Anyway, on with an example:
<pre>
#!/usr/bin/python

import egg, gtk

class EGGFileView(egg.App):
  """A file viewer example application for EGG."""

  # Set up filename as a context since some functions require an open file.
  # When set to None, 0 or False, it will disable widgets needing this context.
  filename = egg.context(None)

  # The egg.eggify() decorator wraps all our callback methods in order to
  # provide necessary widgets automatically
  @egg.eggify()
  def open(self, filename):
    # Note that method docstrings are in the imperative
    """Open a file (read-only)"""
    # Pretty rough code: just read the *whole* file into a gtk TextBuffer
    file = open(filename)
    mytext = "".join(file.readlines())
    file.close()
    self.textbuffer.set_text(mytext)
    self.textbuffer.apply_tag(self.mytexttag, self.textbuffer.get_start_iter(), self.textbuffer.get_end_iter())
    # Tell the user what we've done
    self.feedback(filename + " opened.")
    # Provide the filename context, enabling appropriate widgets
    self.filename = filename

  # We provide the filename as our context to the eggify decorator function,
  # since we can't perform a close() without a non-None filename
  @egg.eggify(context=filename)
  def close(self):
    """Close the current file"""
    self.textbuffer.set_text("")
    # Tell the user what we've done
    self.feedback(self.filename + " closed.")
    # Remove the filename context, disabling functions requiring an open file
    self.filename = None

  def __init__(self):
    egg.App.__init__(self,
                     menu=[["_File", self.open, self.close, None, self.quit],
                           ["_Help", self.about]],
                     tools=[self.open, self.close, self.quit],
                     version="1.0",
                     authors=["Pete Ryland <pdr@pdr.cx>"],
                     copyright="Copyright (c) 2006 Pete Ryland",
                     license=egg.GPL
                    )
    # The below is standard gtk-type code.  This gives you an idea of what
    # we're saving ourselves from by using EGG.  Of course, EGG will eventually
    # provide TextView setup stuff somehow.  Please let me know if you have any
    # good ideas about this or other unprovided stuff like layouts.
    self.mytexttag = gtk.TextTag()
    self.mytexttag.props.family = "Monospace"
    self.textbuffer = gtk.TextBuffer()
    self.textbuffer.get_tag_table().add(self.mytexttag)
    textview = gtk.TextView(self.textbuffer)
    scrolltextview = gtk.ScrolledWindow()
    scrolltextview.add(textview)
    scrolltextview.set_policy(gtk.POLICY_AUTOMATIC, gtk.POLICY_AUTOMATIC)
    self.set_contents(scrolltextview)

if __name__ == "__main__":
  a=EGGFileView()
  a()
</pre>
<p>Here's a few things to note:
<ul>
  <li>The menu and toolbar are set up in the egg.App.__init__ call with lists
    of methods.  The About information is set there too.</li>
  <li>The methods are called <code>open</code> and <code>close</code> which
    happen to resemble the names of gtk stock items, and so those items along
    with their standard shortcuts and pretty icons are used.</li>
  <li>Because <code>open</code> takes a single argument called
    <code>filename</code>, eggify automatically knows to launch a file
    selection dialog first, and send it the filename.  The method name and its
    argument are used to determine whether the file selection with be an "open"
    or "save" one, work on directories, and/or allow multiple selections.</li>
  <li>The inherited <code>feedback</code> method sets the statusbar message,
    but it's still very early days for this part of the API.</li>
</ul></p>
<p>Well, please do try it out, the tarball is linked at the top.  And don't
hesitate to send me an email with any feedback you may have (whether positive
or negative!).</p>

]]></description>
</item>

<item>
  <title>EGG! Prototype now available</title>
  <link>http://pdr.cx/~pdr/blog/geekstuff/egg20061011.html</link>
  <description><![CDATA[
<p>
As promised, I have started on a higher-level pythonic API for gtk/gnome, built
on top of pygtk/pygnome.  As I'm too busy right now to package it properly, the
prototype is available as a single file called <a
href="/~pdr/egg20061011.py">egg20061011.py</a> so if you want to try it out
with the following examples, please rename it egg.py.
</p>
<p>
Well, after a brief amount of hacking about, egg now supports menus, buttons,
the about dialog and the start of file selection support.  On to the first
example:
<pre>
#!/usr/bin/python

import egg

class ButtonExample(egg.App):
  """A button example for EGG."""

  @egg.button()
  def clickMe(self):
    """Prints a message to standard ouput"""
    print "You pressed my button!"

  def __init__(self):
    egg.App.__init__(self, version="1.0")
    mybutton = self.clickMe.getbutton(self)
    self.set_contents(mybutton)

if __name__ == "__main__":
  a=ButtonExample()
  a()
</pre>
This example shows the general feel of what I'm aiming at.  Notice a few
time-saving features:
<ul>
  <li>Default menus are provided, with File->Quit and Help->About
  <li>A default About dialog is provided automatically
  <li>A button factory (clickMe.getbutton) is created automatically by the
      egg.button() decorator, and connects the button to the callback
  <li>The callback doesn't need to receive the widget that caused it as an
      argument
  <li>The docstring for the button is used for the tooltip and the callback
      method's name is used for the button's label string
  <li>The docstring for the App is used as the AboutDialog comment, and the
      class's name is used for the application name by default
</ul>
It's these sort of features that will help get both new and seasoned coders
producing applications quickly.  The plan is to enforce good GUI practice by
using sensible defaults, like the following example shows:
<pre>
#!/usr/bin/python

import egg

class MenuExample(egg.App):
  """A simple example of how to do menus in EGG!"""

  @egg.menuitem(accel=ord('n'))
  def newWindow(self):
    """Creates a new window"""
    print "My callback was called!"

  @egg.stockmenuitem(stock_id=egg.STOCK_OPEN)
  @egg.fileselector()
  def open(self, filename):
    print "Opening:", filename

  def __init__(self):
    egg.App.__init__(self, version="1.0",
                     menu=[["_File", self.newWindow, self.open, None, self.quit],
                           ["_Help", self.about]]
                    )

if __name__ == "__main__":
  a=MenuExample()
  a()
</pre>
This shows how to set up menus with egg.  Simply create the appropriate
methods, decorate them with one of the menuitem decorators, then specify them
in the menu parameter of the constructor to egg.App, which takes a special
format.  Each menu is represented as a list, with the first item being its
title, and the following items being either a menuitem method, a submenu array
or None for a separator.  The top-level menubar is different only in that it
doesn't contain a title.  There are also decorators for RadioMenuItems and
CheckMenuItems.  Notice how two decorators have been used on the open method;
one creates an intermediate callback that creates a file open dialog and then
calls back the open method with the filename if the operation was not
cancelled.  Notice how the open menu item's label has "..." appended?  Egg
knows the menuitem will be opening a dialog, so does this automatically.  Don't
be too scared, though, you can specify a label yourself too!
</p>

]]></description>
</item>

<item>
  <title>EGG</title>
  <link>http://pdr.cx/~pdr/blog/geekstuff/egg.html</link>
  <description><![CDATA[
<p>
Well, I've not done any major gtk programming for some time, and certainly not
much gtk stuff in python, so I thought I'd see where that was at, and was quite
dissappointed.  Last time I looked, the documentation was pretty sparse, and
pygtk was not much more than a <a href="http://www.swig.org/">swig</a>ging of
libgtk.  Now, well, it hasn't really improved a lot.  It's up to date with the
latest gtk and gnome versions at least and has improved the way gtk objects are
mapped, but the documentation is still pretty lame, and the few tutorials I've
found have been more about using glade than getting dirty with pygtk and
pygnome.  And quite right, too, it really does feel like a C API, which
basically defeats the purpose of using python -- I may as well just code in C!
The #gnome channel on gimpnet wasn't much help either, unfortunately,
suggesting that people were moving away from this API.
</p>
<p>
So, I've decided to take on the challange of writing a more pythonic
higher-level API for gtk, building on pygtk and pygnome (and their hard work)
using more pythonesque features, including some newer ones such as decorators.
The intention is to create an API that is primarily easy to use, so will do
things like allow gui objects to be provided automatically by simply decorating
a method with the appropriate wrapper, and provide sensible, working defaults
to enable users to get something working quickly, a bit like scaffolding in
RoR.
</p>
<p>
First things first then, the name.  After not too much thought, I came up with
EGG, Easy Gnome Gubbins.  So there we have it.  Expect to see some more about
this in the very near future!
</p>

]]></description>
</item>

<item>
  <title>Tomcat Wiki</title>
  <link>http://pdr.cx/~pdr/blog/geekstuff/tomcatwiki.html</link>
  <description><![CDATA[
<p>
Funny that <a href="http://wiki.apache.org/tomcat/">Tomcat's official wiki</a>
is Python Powered. :-)
</p>

]]></description>
</item>

</channel>
</rss>
