Occasionally though I’ll feel compelled to actually write some code to test out the idea. It’s good to prototype things. It’s particularly handy for testing out new tech without the constraints of an existing system.

The latest idea that’s been running around my head has been triplestores. I’ve still yet to need to use one, but wanted to get a better understanding of how they work and what they can be used for. Having spent a large number of years in the SQL database world, it seems like a good idea to try out some alternatives – if only to make sure that I’m not shoe-horning an SQL database into something purely because I know how they work.

So rather than do the sane thing and download a triplestore and start playing around with it, I decided to write my own. Obviously I don’t have unlimited time so it had to be simple. As of such I decided an in-memory store would still let me learn a fair bit, without being too onerous. Over the past few weeks I’ve been working on this triplestore and it’s now at a point where it’s largely functional:

https://github.com/lilspikey/mini-sparql

To be honest writing this has been almost more of an exercise – a coding kata.

A few key points of the implementation:

• PyParsing for the parsing SPARQL
• Lots of generator functions to make evaluation lazy
• Interactive prompt for running SPARQL queries
• Load triple data from file/stdin (as triples of data in simplified turtle format)

As the data is all stored in memory it’s no good as a persistence store, but for quickly inspecting some triple data it works pretty well. Simple point the minisparql.py script at a file containing triple data and away you go:

$ python minisparql.py birds.ttl
sparql> SELECT ?name WHERE { ?id name ?name . ?id color red }
name
'Robin'

PyParsing

PyParsing is a great project for writing recursive descent parsers. It makes use of operator overloading to allow you to (mostly) write readable grammars. You can also specify what objects you want to be returned from parsing – so it’s quite easy to parse some code and get back a list of objects that can then execute the code.

It also includes quite a few extra batteries. One of the most powerful is operatorPrecedence, which makes it a piece of cake to create the classic arithmetic style expressions we all know and love. For example, the operatorPrecedence call in minisparql looks like:

expr=Forward()
# code removed for clarity
expr << operatorPrecedence(baseExpr,[
        (oneOf('!'), 1, opAssoc.RIGHT, _unaryOpAction),
        (oneOf('+ -'), 1, opAssoc.RIGHT, _unaryOpAction),
        (oneOf('* /'), 2, opAssoc.LEFT, _binOpAction),
        (oneOf('+ -'), 2, opAssoc.LEFT, _binOpAction),
        (oneOf('<= >= < >'), 2, opAssoc.LEFT, _binOpAction),
        (oneOf('= !='), 2, opAssoc.LEFT, _binOpAction),
        ('&&', 2, opAssoc.LEFT, _binOpAction),
        ('||', 2, opAssoc.LEFT, _binOpAction),
    ])

This handles grouping the various operators appropriately. So rather than parsing:

5 * 2 + 3 + 2 * 4

And getting just a list of the individual elements you instead get a properly nested parse tree, that is equivalent to:

((5 * 2) + 3) + (2 * 4)

Where each binary operator is only operating on two other expressions (just as you would expect under classic C operator precedence).

This meant that implementing FILTER expressions was pretty straightforward.

Generators

Generator functions are one of my favourite features in Python. I was completely blown away by David Beazley’s Generator Tricks for Systems Programmers. He starts off with fairly simple examples of generators and shows how they can be combined, much like piped commands in Unix, to create extremely powerful constructs. Therefore it was obvious to me that generators were a good fit for minisparql.

The code for the regular, optional and union joins became pretty straightforward using generators. For example the union join looked like:

    def match(self, solution):
        for m in self.pattern1.match(solution):
            yield m
        for m in self.pattern2.match(solution):
            yield m

This simply returns the result of one query, followed by the results of another. The great thing about this is that if we only evaluate the first few values we might not even need to evaluate the second query. The better aspect though is that you can start getting results straight away. A more classical approach would entail building up a list of results:

    def match(self, solution):
        matches = []
        for m in self.pattern1.match(solution):
            matches.append(m)
        for m in self.pattern2.match(solution):
            matches.append(m)
        return matches

This code would always execute both queries – even if it wasn’t strictly necessary. To my eye the generator code is much clearer as well. yield stands out very well, in much the same way as return does. It’s certainly much clearer that matches.append(m) which does not immediately make it clear that data is being returned/yielded from the function.

Anyway, so here’s my silly little bit of exploration. I’ve learnt a fair bit and got to play with a some different ideas.

If I was to take this any further I’d probably want to add some sort of disk-based backend. That way it might be useful for small/medium-sized SPARQL/RDF datasets for simple apps. Much like SQLite for SQL databases or Whoosh for full-text search.

To reduce the number of queries to just one we can use select_related. Prior to Django 1.2 select_related did not support the reverse direction of a OneToOneField, so we couldn’t actually use it with the user and user profile models. Luckily that’s no longer a problem.

If we are clever we can setup the user profile so it stills works with get_profile and does not create an extra query.

get_profile looks like this:

def get_profile(self):
        if not hasattr(self, '_profile_cache'):
            # ...
            # query to get profile and store it in _profile_cache on instance
            # so we don't need to look it up again later
            # ...
        return self._profile_cache

So if select_related stores the profile object in _profile_cache then get_profile will not need to do any more querying.

To do this we’d define the user profile model like this:

class UserProfile(models.Model):
    user = models.OneToOneField(User, related_name='_profile_cache')
    # ...
    # other model fields
    # ...

The key thing is that we have set related_name on the OneToOneField to be '_profile_cache'. The related_name defines the attribute on the *other* model (User in this case) and is what we need to refer to when we use select_related.

Querying for all user instances and user profiles at the same time would look like:

User.objects.selected_related('_profile_cache')

The only downside is that this does change the behaviour of get_profile slightly. Previously if no profile existed for a given user a DoesNotExist exception is raised. With this approach get_profile instead returns None. So you’re code will need to handle this. On the upside repeated calls to get_profile, when no profile exists, won’t re-query the database.

The other minor problem is that we are relying on the name of a private attribute on the User model (that little pesky underscore indicates it’s not officially for public consumption). Theoretically the attribute name could change in a future version of Django. To mitigate against the name changing I’d personally just store the name in a variable or on the profile model as a class attribute and reference that whenever you need it, so at least there’s only one place to make any change. Apart from that this only requires a minor modification to your user profile model and the use of select_related, so it’s not a massively invasive optimisation.

As the Chumby runs Linux, is on the network and is able to run a recent version of Python (2.6) it seemed like it would be pretty easy to get it to send Growl notifications to the local network.

This did indeed prove fairly easy and involved three main activities:

• Listening to the serial port for the doorbell to ring
• Using Bonjour (formally Rendezvous)/Zeroconf to find computers on the network
• Sending network Growl notifications to those computers

Getting Python and PySerial running on the Chumby is pretty easy. The Chumby simply listens for the doorbell to send the string ‘DING DONG’ and can then react as needed.

def listen_on_serial_port(port, network):
    ser = serial.Serial(port, 9600, timeout=1)
    try:
        while True:
            line = ser.readline()
            if line is not None:
                line = line.strip()
            if line == 'DING DONG':
                network.send_notification()
    finally:
        if ser:
            ser.close()

port is the string representing the serial port (e.g. /dev/ttyUSB0). network is an object that handles the network notifications (see below).

The network object (an instance of Network) has two jobs. Firstly to find computers on the network (using PicoRendezvous – now called PicoBonjour) and secondly to send network growl notifications to those computers.

A background thread periodically calls Network.find, which uses multicast DNS (Bonjour/Zeroconf) to find the IP addresses of computers to notify:

class Network(object):
    title = 'Ding-Dong'
    description = 'Someone is at the door'
    password = None

    def __init__(self):
        self.growl_ips = []
        self.gntp_ips = []

    def _rendezvous(self, service):
        pr = PicoRendezvous()
        pr.replies = []
        return pr.query(service)

    def find(self):
        self.growl_ips = self._rendezvous('_growl._tcp.local.')
        self.gntp_ips  = self._rendezvous('_gntp._tcp.local.')
        def start(self):
        import threading
        t = threading.Thread(target=self._run)
        t.setDaemon(True)
        t.start()

    def _run(self):
        while True:
            self.find()
            time.sleep(30.0)

_growl._tcp.local. are computers that can handle Growl UDP packets and _gntp._tcp.local. those that can handle the newer GNTP protocol. Currently the former will be Mac OS X computers (running Growl) and the latter Windows computers (running Growl for Windows).

I had to tweak PicoRendezvous slightly to work round a bug on the Chumby version of Python, where socket.gethostname was returning the string '(None)', but otherwise this worked ok.

When the doorbell activates netgrowl is used to send Growl UDP packets to the IP addresses in growl_ips and the Python gntp library to notify those IP addresses in gntp_ips (but not those duplicated in growl_ips). For some reason my Macbook was appearing in both lists of IP addresses, so I made sure that the growl_ips took precedence.

    def send_growl_notification(self):
        growl_ips = self.growl_ips

        reg = GrowlRegistrationPacket(password=self.password)
        reg.addNotification()

        notify = GrowlNotificationPacket(title=self.title,
                    description=self.description,
                    sticky=True, password=self.password)
        for ip in growl_ips:
            addr = (ip, GROWL_UDP_PORT)
            s = socket(AF_INET, SOCK_DGRAM)
            s.sendto(reg.payload(), addr)
            s.sendto(notify.payload(), addr)

    def send_gntp_notification(self):
        growl_ips = self.growl_ips
        gntp_ips  = self.gntp_ips

        # don't send to gntp if we can use growl
        gntp_ips = [ip for ip in gntp_ips if (ip not in growl_ips)]

        for ip in gntp_ips:
            growl = GrowlNotifier(
                applicationName = 'Doorbell',
                notifications = ['doorbell'],
                defaultNotifications = ['doorbell'],
                hostname = ip,
                password = self.password,
            )
            result = growl.register()
            if not result:
                continue
            result = growl.notify(
                noteType = 'doorbell',
                title = self.title,
                description = self.description,
                sticky = True,
            )

    def send_notification(self):
        '''
        send notification over the network
        '''
        self.send_growl_notification()
        self.send_gntp_notification()

The code is pretty simple and will need some more tweaking. The notification has failed for some reason a couple of times, but does usually seem to work. I’ll need to start logging the doorbell activity to see what’s going on, but I suspect the Bonjour/Zeroconf is sometimes finding no computers. If so I’ll want to keep the previous found addresses hanging around for a little longer – just in case it’s a temporary glitch.

You can see the full code in my doorbell repository.

At work I do a lot of Java web development, which normally involves compiling code, packaging into a .war file and deploying it to Tomcat (running locally). I make use of the maven tomcat plugin, so it’s just a case of calling maven tomcat:redeploy. However it still takes tens of seconds (or more if there are tests to run). For quick tweaks of css it’s nice to be able to short-circuit this process.

Tomcat unpacks the .war file to another directory after the app has been deployed. All the .jsp pages, css and javascript files can be edited in this directory and changes can be seen immediately. However getting into the habit of editing these files within this directory is usually a bad idea, as the files will get overwritten at the next deployment.

We’ve been using compass lately for css and it has a handy command:

    compass watch

That monitors .sass files for changes, then re-compiles them to css as they change, so you can see changes quickly (without needing to manually run compass each time).

So I thought I could do something similar for the editable files within the war file. So I created watch-cp.py. It simply monitors a set of files and/or directories for changes and copies over files that have changed to a source file or directory. To provide a bit of feedback it prints out when it spots a changed file, but beyond that it’s pretty brute-force in it’s approach.

watch-cp.py works in a very similar way to the cp command, but without as many options. For example:

    # recursively copy files from src/main/webapp to tomcat
    watch-cp.py -r src/main/webapp/* ~/tomcat/webapps/mywebapp

This is great as it means I can edit my sass files, have them compiled to css by compass, then copied over to tomcat without needing to intervene. It takes a second sometimes, but it’s fast enough for the most part.

Feel free to fork the gist of watch-cp.py on github.

After playing around with iPhone javascript apps, I thought it would be interesting to try and create a javascript app for the bus times. I had some specific ideas about how I wanted the app to work. I was also keen on trying out some more “HTML 5″ tech. Plus I do like things to be (at least in principle) cross-platform, so this has a chance of working ok on Android phones (though I’ve not tested it on one).

There are still a few rough edges, but you can try out the app yourself at:

• http://buses.psychicorigami.com/

It will prompt you to add a stop. If you type in the text field, you’ll get a list of stops that match. If your browser supports geo-location, you’ll also see a “Find nearby” button, which will list the nearest few stops.

I had the pleasure of demoing this app at the Async Javascript show’n'tell last month. I quickly outlined how it worked, which involves the following:

• Offline App Cache – to make startup quick (key when you don’t want to miss your bus)
• Client-side Local Storage – to record which bus stops you add
• Geo-location – so you can find nearby stops
• JQuery – for front end
• Bottle.py – for back end
• BeautifulSoup – for scraping bus times

Getting the data

The buses.co.uk site has an API, which I used to scrape all of the bus stops in Brighton. I chose to scrape the update data from the website itself though, as I couldn’t get the API to give me the combined services for each stop (so you can see when the next 7 and 81 are coming for example). There are typically two stops for each name – one either side of the road. The updates are for both directions, so I actually merged the stops together – which makes searching easier.

All of the stop data was stored in a single SQLite database – mostly for convenience. The database is used in a read-only method in the actual running app. I’m sure I could use something a bit better, particularly when it comes to the distance queries. Currently, as there are a relatively small number of stops I’m using a brute force method to find the nearest stops, but I’m sure with the use of a proper spatial index this could be done a lot more efficiently. If this was scaled up to work for all stops in the UK, then that would be a necessity.

Geo-location

Initially the geo-location was pretty straightforward – I simply used the getCurrentPosition function and I got a latitude and longitude back. Testing in Firefox and Safari on the mac gave fairly reasonable results. However on the iPhone itself I started to notice it wasn’t very accurate. Sometimes it was out by several 100 metres, meaning that stops I was standing next to were sometimes not showing up at all! I had noticed, in the past, that the built-in map app sometimes has a bit of “lag” in getting an accurate position. So I switched to using watchPosition and polling for the position for several seconds. This worked pretty well, as the initial result would only be vaguely in the right place and then after a few seconds the position would become more accurate and the listing of nearby stops would start to look more sensible.

Look and feel

Originally I’d planned to mimic the look and feel of the iPhone’s built-in weather app. The app is built around a similar concept – you search for bus stops and add them to a list of stops that you can flick through. I tried to get a nice animated sliding action working, but kept on running into trouble on the device itself. In Safari and Firefox the animation all worked ok, but I suspect there’s an issue on the iPhone when you are dragging an area that limits redrawing. In the end I had to ditch the flip/swipe gesture too – interfering with the touch events again seemed to cause some rendering issues on occasion. So instead simply clicking on the left or right of the timetable moves between pages. It’s a slightly less complicated way of doing things, so there’s less that can go wrong really.

Deployment

As this was a nice simple app (on the back-end at least), I decided to take a little time to create a Fabric file to control deployment. The app is hosted on Webfaction, where I have already setup key-based login for ssh. The app is deployed using mod_wsgi with a daemon process, so that one merely needs to copy over the new code, then “touch” the .wsgi file restart the daemon process. Not exactly tricky to do, but making it a one-button process saves making any mistakes.

To trigger the deployment I run my fab file like this:

fab --user=lilspikey --hosts=lilspikey.webfactional.com deploy:webapps/buses/app/

I actually have that in a shell script, that isn’t checked into git, so that the deployment specific username, host name and remote directory aren’t checked into source control. If I wasn’t using key-based login, I’d need to specify a password and I definitely wouldn’t want to check that into git!

Source code

You can get the source code on github in my buses repository.

First you’ll want Python on the Chumby. At the time the latest version already compiled for the Chumby is Python 2.6, so it’s pretty up-to-date.

Once you’ve got Python installed and on a USB stick you’ll also want to download PySerial – I picked the latest version PySerial-2.5-rc2.

With PySerial expanded and on the USB stick (alongside Python) you’ll want to put the USB stick in the Chumby and connect to it via SSH.

Change to the directory for the USB stick (e.g. cd /mnt/usb).

You should see (at least) two directories, one for Python and one for PySerial:

chumby:/mnt/usb-EC5C-3D0A# ls -l
drwxr-xr-x    6 root     root         4096 Jun 26 21:15 pyserial-2.5-rc2
drwxrwxrwx    4 root     root         4096 Jan 10 13:51 python2.6-chumby

You’re first instinct may be to try and install PySerial via the usual call to python setup.py install. However this appears not to work.

All is not lost though – just manually copy the relevant directory (serial) from PySerial to the python site-packages directory, e.g.:

cp -r pyserial-2.5-rc2/serial python2.6-chumby/lib/python2.6/site-packages/

Know to check that’s worked open a python prompt and try to import the serial library:

chumby:/mnt/usb-EC5C-3D0A# python2.6-chumby/bin/python
Python 2.6.2 (r262:71600, May 23 2009, 22:28:43)
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import serial
>>>

If you don’t see any errors (as above) then everything has installed ok.

Next step is to try out connecting an Arduino.

So first off you’ll want to ensure the Arduino has a program that can read from the serial port – to show that everything is working ok. In my case I picked my Morse Code program. This will read bytes from the serial port and toggle the built-in LED (on pin 13), so it’s handy for verifying the serial port is working.

So now you have a program loaded on the Arduino, connect it to the Chumby. The Arduino should get enough power from the Chumby to start up ok.

You need to work out which serial port the Arduino is using on the Chumby. List the tty’s in /dev and pick the most likely looking one (should have USB in it’s name):

chumby:/mnt/usb-EC5C-3D0A# ls /dev/tty*
/dev/tty      /dev/ttyS00   /dev/ttyS02   /dev/ttyS1    /dev/ttyS3
/dev/ttyS0    /dev/ttyS01   /dev/ttyS03   /dev/ttyS2    /dev/ttyUSB0

On my Chumby the serial port was /dev/ttyUSB0.

Now open up a python prompt again and try talking to the Arduino. You’ll need to configure the baud-rate of the serial port to match the program on the Chumby. In my case this was 9600.

chumby:/mnt/usb-EC5C-3D0A# python2.6-chumby/bin/python
Python 2.6.2 (r262:71600, May 23 2009, 22:28:43)
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import serial
>>> ser = serial.Serial('/dev/ttyUSB0', 9600, timeout=1)
>>> ser.write('sos')
3

If you are using the same morse code program you should see the LED blink out ‘DOT-DOT-DOT DASH-DASH-DASH DOT-DOT-DOT’ – confirming that the serial port works.

This is really quite handy, as the Chumby is a small low-power Linux server. Coupled with Python this means it’s really easy to get any Arduino based project online, without needing a “normal” computer constantly running. Not quite as self-contained as using an Ethernet Shield, but the Chumby is fairly small, so it and an Arduino will easily sit on a window ledge (for example).

So you can now find the hybrid Python, Javascript and Flash Chumby postcast client I dubbed chumbycast, on github. I’m providing the code just for the curious – I’ve had at least one request for it, but I’m not really going to detail too much of how it works. Though some of this is outlined in the original post where I mentioned the project.

I am tempted to revive this project a bit, but probably by trying a different approach. I mostly gave up on this as I was creating a UI on the Chumby in Flash and my Flash skills aren’t exactly great, plus I was trying to use mtasc which hampered things further. Which is not to belittle mtasc – it’s just with limited time and no previous Flash experience I wasn’t exactly helping myself by not using some nice friendly Flash IDE.

I’ve since realised that if I ditched the Flash UI I could probably get quite a bit done. The Python httpserver side of things was pretty easy. So if I focussed on that I would then have a few of ways of providing a UI by hijacking existing functionality on the Chumby.

• The Chumby runs a httpserver on port 8080 when an ipod is plugged in, which the UI uses to access playlists etc. I could mimic this approach and effectively make the podcast client look like an iPod as far as the Chumby’s UI was concerned. By plugging in a USB stick loaded up with the podcast client everything would behave the same as if you had plugged in an iPod.
• It’s possible to create playlist files and edit the “My Streams” section programmatically. Each podcast subscribed to would create a matching pls or m3u file and be added to the “My Streams” section.
• Create a javascript/web UI for controlling the playback and subscriptions to podcasts and other podcast management tasks (like removing old files, manually downloading older episodes etc) from another computer. Possibly adding bonjour/zero-conf support so the Chumby can be browsed to easily

I would need to see whether those first two could be made to work for my purpose, but it would make sense to just use the existing UI on the Chumby – rather than creating a new one. The existing chumbycast code already provides a javascript/web UI for controlling the playback on the Chumby. This was originally done so I could remote control the chumby, but also so that I could easily create and debug an API for the Flash UI to use.

The other major missing feature is allowing the podcasts to be paused part way through. The current client does not support this, as the audio files are streamed and not downloaded. So that would be the first change to make. Now that I’ve dug out the code maybe I’ll be inspired to play around some more. I’ve also been listening to a lot more podcasts (thanks to Huffduffer) so it might happen yet.

A liberal dose of select_related helped. However that was only useful in the cases where a ForeignKey needed to be pre-fetched.

In the case however there was a page that was selecting a set of objects that had tags. The tags for each object were being displayed along side a link to the main object. Given that the initial query returned over three hundred objects, this meant the page was performing another three hundred (plus) queries to fetch the individual tags for each object! Now we could cache the page and that’s was indeed what was being done. The trouble however was when the cache expired. It also made things painful when developing – as I’d typically want to disable caching whilst I’m making changes to pages frequently.

I came up with a specific solution for this project – to perform the initial query, then a second query to fetch *all* of the other tags in one go. The results of the second query could then be stitched into the original results, to make them available in a handy manor within the page’s template.

I took the original idea and made it re-usable and am now releasing that code as Django Batch Select. There are examples of how to use it over at github, but it works a bit like this:

>>> entries = Entry.objects.batch_select('tags').all()
>>> entry = entries[0]
>>> print entry.tags_all
[<Tag: Tag object>]

It’s a very early release – after the result of only a few hours coding, so use with care. It does have 100% test code coverage at the moment and I’m reasonable confident about it working. Please try it out and let me know whether it works for you.

The defaults are generally pretty good, but it’s often the case that you’ll want to tweak and change it (particularly when you have clients involved). Luckily it’s pretty easy to customize.

One common change that many people will want to do is to display a thumbnail of an uploaded image in the admin. The default image field (when an image has been uploaded) in the admin looks like:

and we want to change it to look like this:

In my case I had images that I knew would be fairly small so I didn’t need to use any auto-resizing or anything like that. I found this snippet for doing the same task, but decided to simplify it a fair bit and ended up with:

from django.contrib.admin.widgets import AdminFileWidget
from django.utils.translation import ugettext as _
from django.utils.safestring import mark_safe

class AdminImageWidget(AdminFileWidget):
    def render(self, name, value, attrs=None):
        output = []
        if value and getattr(value, "url", None):
            image_url = value.url
            file_name=str(value)
            output.append(u' <a href="%s" target="_blank"><img src="%s" alt="%s" /></a> %s ' % \
                (image_url, image_url, file_name, _('Change:')))
        output.append(super(AdminFileWidget, self).render(name, value, attrs))
        return mark_safe(u''.join(output))

Then to use it I simply override formfield_for_dbfield to return a field that uses that widget for the field I’m interested in:

class MyAdmin(admin.ModelAdmin):
    def formfield_for_dbfield(self, db_field, **kwargs):
        if db_field.name == 'profile_image':
            request = kwargs.pop("request", None)
            kwargs['widget'] = AdminImageWidget
            return db_field.formfield(**kwargs)
        return super(MyAdmin,self).formfield_for_dbfield(db_field, **kwargs)

It’s a fairly straightforward alteration to how the ImageField widget renders in the admin, but it is often a big help to be able to actually see the image in question.

UPDATED: Feb 24th, 2010. Based on Jeremy’s comment below and having upgraded to Django 1.1 I’ve modified this example to remove the “request” param from kwargs before passing it db_field.

The app is called NoteComb and is written in Python using wxPython. It’s essentially a specialised text-editor. The core feature is a grep-like search functionality coupled with the ability to edit text in-place during a search. Lines that don’t contain the search terms get hidden, leaving you free to edit the remaining lines as you want:

I’ve decided to take the time and try to package it up “properly”. So NoteComb is available as Mac and Windows apps, complete with icons etc. In fact to “regular” users it should appear that NoteComb is an app like any other – the fact it’s written using Python is largely incidental.

This packaging works pretty well overall and is pretty seamless once the app is downloaded, but it does tend to make for rather large apps. The Windows version when packaged as an installer runs in at about 4Mb, which isn’t too crazy, but the OS X app packed into a compressed DMG file weighs in at 15Mb! At the end of the day the app does include Python + wxPython + various libraries, so it’s not a surprise really, but I guess I was kind of hoping that I might develop in Python and get everything for free…

This is an early version of NoteComb (version 0.2.1), but it’s core functionality is there. Most of the extra work I’ve done has been on adding those little extra bits that aren’t core to the app, but are generally just expected (e.g. remembering previous window positions, copy/paste, undo/redo etc).

So feel free to download NoteComb and give it a go.