[status update] Menu System

= The Good =
+ entries are sorted by title (A=black, Z=white, and layed out in a
predictable position.)
+ It works as an application launcher, or as a web-based links page
+ You can try it yourself:
Web: http://www.srcf.ucam.org/~dl325/python/links/links.py?username=YOUR_NAME
Desktop:
$ sudo aptitude install git-core pyqt4-dev-tools libqt4-dev qt4-designer python-xdg xdg-utils python-sqlite kdebase-bin
$ git clone http://www.srcf.ucam.org/~dl325/python/links/.git/
$ python qsmenu.py

= The Bad =
– Currently, it just picks the first menu entry it finds for each program, and
doesn't prefer working/svg icons over broken/pixelated ones
– It needs a name! Post ideas here:

https://www.blogger.com/comment.g?blogID=6107001&postID=663834070309131498

= The Future =
+ I reckon my menu system could be adapted to work with file menus as well
(create a DataEngine that understands KDE's XMLGUI crap). That would be
hardcore (and *better* than MS Office's ribbon, with less manual work).
+ Add an info panel at the bottom, for more verbose info on entries.
+ Make a data engine with a[n incremental] search function that modifies the
scores.
+ Add sub-folders to the menu, which cause the entries within to stand out.
+ Experiment with regions that contain other regions
+ Experiment with highlighting to show newly available/last used entries.
+ Make the data engine thread-safe, and event-driven.
+ Port to Plasma for KDE4

= The Inner workings =
There are 3 components:
* Data Engine
* Layout Engine
* Rendering Engine

The Data Engine is responsible for collecting and ordering data, and assigning
scores. It is also responsible for compiling the data into a 1-D list of
entries.
The Layout Engine takes the 1-D list of entries, and maps each entry into a
region (of one or more squares on a 2-D space). It passes this data to the
rendering engine by calling draw_square() repeatedly. It also calculates the
center of the region, using a bit of GCSE maths.
The Rendering Engine deals with the user interface crap. It draws the squares,
and deals with clicks by sending them to the data engine.

The layout algorithm is a case of "cut parent square into 4 children, and
repeat until there is only 1 entry in each child square, then paint."
The sub-dividing and checking for entries is done in 1-D rather than 2-D, so
it's pretty fast.
The slow bit is the rendering, which is done using C libraries anyway :D.

= "But how do you make it look so pretty?" =
I fudge it. I leave a gap with no information in it. That way, "there is only
1 entry in the child square" happens after only a few sub-divisions. This is
something that I stumbled upon by accident, when I fed it some bad input
data.

To give you an idea of how nasty it *could* look, this is a picture drawn with
the gaps as normal:
< http://www.srcf.ucam.org/~dl325/python/links/map_DTsoSj.png >
and this is the picture with
< http://www.srcf.ucam.org/~dl325/python/links/map_EJjvka.png >
brown=fudge (I decided on fudge_factor rather than blur, as that's what it is)
lines are drawn in the brown by sub-dividing, to create the simplest possible
regions (ie ones with the largest/fewest squares).