Potlatch 1/Development overview/five-minute overview
Hacking the client code
The 3000+ lines of ActionScript that make up the Potlatch SWF are the main focus of development.
- all the drawing and editing logic
- generic user interface code (for pull-down menus, etc.)
(The icons are drawn with Perl Ming primitives, in potlatch_assets.pl. You probably won't need to change these.)
You don't need the commercial Flash IDE to compile, just the Ming library.
The Potlatch ActionScript is very hackery. If you're an OO fundamentalist or you don't like global variables, Potlatch is not the project for you. You should definitely have used Potlatch a fair bit before hacking on it.
There are a few main object types: ways, 'anchor points' (red or blue nodes in selected ways), and POIs. These have methods like redraw, select, load, save, delete. They're built on movieclips, which means they can be moved, scaled and recoloured like anything else in Flash. Most work is either carried out in these, or a vast array of procedural helper functions.
Don't get confused by the way that the rest of OSM operates. Nodes are not objects in Potlatch, unless they're POIs. (Given that each movieclip has a 1k overhead, viewing a big city would boggle the Flash Player if each node was an object.)
The code is reasonably well-commented, and ActionScript is very easy to learn (there's an online reference) for anyone with scripting language experience.
Hacking the server code
The server code (amf_controller.rb) is pretty stable. You'll only need to look at it if you're planning anything really convoluted, like adding relation support. Otherwise, the way and point reads/writes generally work well and don't need to be altered. It's documented at Server overview and you should have spent some time poking around the OSM db: if you need any more info, do ask Richard.
Some of the GPS code resides on the server, too (at swf_controller.rb). The SWF-generating bit of this is pretty gnarly, but the database query is very obvious and would be easy to change.
If you're thinking of hacking on Potlatch, here are three design principles to bear in mind:
- No dependencies
- Uncomplicated UI
There's lots to be done: see the future plans and feedback pages. Potlatch could be speeded up in several areas, too, such as by reducing the use of _visible=false clips (which take up time even though they're not visible), and by not redrawing the entire way when a new point is added.