Now that Matt has gone ahead and announced this, I think I should send some more traffic his way. If you are interested in using Conduit to synchronize your iPhone contacts, calendar and notes then go and check out his work.
I hear people like this "iPhone" thingee
Also, I am still looking for volunteers to help me maintain the Google contacts/calendar Conduit dataproviders. They need some love, and I am just one developer.
ENAC
Hi Everyone, Its been a long time between blogging but I have an excuse. I have moved from Christchurch New Zealand, to ENAC, Toulouse, France. I have now been here for a month, working with the UAV team here.
The work has been really challenging, and I have settled into my routine, working towards some things I would like to demonstrate before I leave. I have spent a few weeks doing a lot of electronics design, updating the paparazzi autopilot board, the IMU, and the GPS boards. Nothing revolutionary, just some evolutionary improvements over the previous hardware.
Consolidation of the interfaces between the main board, and the IMU+GPS+Radio+Motors. IMU interface is now SPI only, GPS interface is I2C only / UART only.
Addition of a 24bit ADC on the main board to directly measure the pressure sensor, no more op-amp+calibrate the offset at startup.
Physically smaller stackable board design.
A lot of this work has been done with an eye towards moving some of the off-board vision processing I am currently doing onto the flying aircraft. I have been experimenting with the beagleboard, and one of the goals of the hardware refactoring above is to free up an interface to push data between the beagleboard and the flight controller. Probably I2C or UART, I am not sure yet.
Can anyone get hold of a Gumstix Overo for me?
I am hoping to be able to demonstrate some biomimetic control responses from my onboard vision system, using image motion information. I also hope to demonstrate hybrid external position estimation system using an off aircraft 3d vision system aided (kalman estimator) by on-board IMU .
Plenty of work for me ahead.
Ubuntu
I finally managed to upgrade to the Ubuntu Intrepid beta. I was pleased to see that it contained all sorts of productivity improvements;
I used to waste about an hour a day keeping up with the US election news on Youtube, watching Sarah Palin insult the intelligence of all mammals on the planet with her existence. Intrepid fixed this for me by removing the feature where sound embedded in flash videos was played through the soundcard of my computer. Phew, thats a relief. I guess I will just need to go and watch Fargo instead.
Keeping in contact with my family via Skype was also a PITA, luckily Intrepid removed the ability for me to do that too, no sound to hear my parents nag me, and no video which would let them see me all hung over and tired.
Im sure everyone reading this is aware of that feeling when you go and use a friends brand new $2000 Windows Vista computer. The way it runs so slowly with 2GHz of processing power at its disposal, crashes all the time and takes 6 minutes to turn on. It is brand new FFS. When I am in that situation it makes me feel like the entire engineering profession has failed me.
I got that feeling with Ubuntu this week.
Conduit
Unfortunately I have not been able to work on Conduit very much over the last month, and it appears that no one else seems to have had the time to either. This upgrade pain has destroyed my motivation, and I only just recovered from the previous month, where approximately 14,000 people reminded me that the Conduit GUI made them vomit in their mouth. Some positive re-inforcement (and some help hacking) would be a welcome change about now.
Summer of Code This has now finished, and I am really happy with how it went. I was able to complete a Python binding to libsyncml. This was done with the help of Pybindgen, which aside from a few quirks, performed admirably. Expect this to become the premier tool to automatically create python bindings to C/C++ libraries. The binding still contains too many bugs to be considered usable in Conduit trunk (read: crasher bugs) but I can see the light at the end of the tunnel.
Alexandre Rosenfeld was also successful in his Conduit Summer of Code project. He contributed audio and video support for the iPod, and a comprehensive audio/video converter/trans-coder using python-gstreamer. The iPod support seems quite comprehensive, and the converter component is a necessary component of the Conduit architecture for our future plans.
Conduit
While it may look like I have been dormant at Conduit hacking, work has been ongoing in a number of branches.
One of the major tasks necessary for the GIO port was the isolation of the platform specific parts, such as GConf, and GnomeVFS. One thing that fell out of this work is that Conduit now works on Windows. With no (~10 lines) code changes. Amazing really. It should be noted that this is not actually using GIO on windows, it is using a pure Python File class implementation.
Conduit can haz Windows!
I am not really serious about maintaining this port, but it shows what is possible. If someone wants to hack on this I can point them to the necessary places. But basically you will need
Goocanvas and PyGoocanvas installers
The conduit-win32 branch (not accessible ATM, due to aforementioned bzr brokeness)
I have also moved over to using PyWebkitGtk for the Conduit Web browser. They just made a 1.0 release, and I would really like it if those responsible for packaging Conduit, could please also package PyWebkitGtk, and ensure that it gets the necessary exceptions so that it is accepted into the appropriate distributions. Words cannot express how happy I am to be rid of gtkmozembed. It is a shame that webkitgtk was not accepted as an external dependency for GNOME 2.24, as this now makes getting things like pywebkitgtk into distributions a royal PITA.
Openstreetmap GPS Widget Some time ago I mentioned the osm-gps-map widget that I have been working on, semi-related to my PhD. I just made the inaugural 0.1 release. This widget basically lets one easily write moving-map display widgets very easily, showing points of interest, and multiple gps paths atop of tiles fetched from openstreetmap, or other mapping providers. It started as a port of Tango GPS, and can now basically do everything that application did, but behind a simple GObject API. Python bindings are also provided
Documentation (soon)
Miscellany
Dear Ubuntu. Please make this your theme.
RMS spoke at the University of Canterbury last week. It was quite good and well attended.
I am off to France in 10 days for a two month PhD excursion/exchange to ENAC
If you know a packager for a distribution, then poke them to package PyWebkitGtk
It all started so well. While Conduit was not accepted into GNOME 2.24, it was blessed as an external dependency for this cycle. That is great news for online service integration, and synchronization on the GNOME desktop. Congratulations to everyone who has helped me work on Conduit over these years, and well done to those who made it into the release set.
I was also able to make a 0.3.13 release incorporating those fixes and UI improvements I discussed last time around. After that things started to get worse.
The disk holding my /home partition crashed. Taking a whole bunch of stuff with it. Like a good geek most of it was backed up or in a RCS, with the exception of my SSH key. FAIL.
This meant I was unable to make the now customary Conduit x.x.x.1 brown paper bag release in time for the GNOME release. I do owe many thanks to our amazing sysadmin, Olav, for getting my new key onto the GNOME servers in a matter of hours.
The disk crash took with it a week+ of my SOC work, making me very angry. To calm the tempers I thought I would work on the conduit-gio branch.
Then Christian Schlotter contributed a really nice Conduit dataprovider which supports sync/backup to Amazon S3.
I then realized the implications of Webkit not being blessed as an external dependency. It means that I have two choices. Continue to drag around the pain that pthon-gtkmozembed brings, or move to using the unreleased (Py)WebkitGtk. I really encourage the WebkitGtk and PyWebkitGtk teams to make stable releases ASAP, to ensure they get into $DISTRO.
Then I found that I could not push to bzr-playground.gnome.org anymore. It appears that it did not pick up my new SSH key. And loggerhead source code browsing is broken there.
Completely fed up with software, I thought I would play with my new hardware toy. This is destined to replace the terrible, unsupported mess that was the Phytec phyCORE LPC3180 module for the purposes of my PhD work.
My brand new beagleboard (photo)
But then the FAIL continued. http://www.openembedded.org has been down for the last 5 days, making it impossible for me to check out the openembedded tree that supports this board. Does anyone know why it is down?
Thanks once again to the many people who commented on my last two blog posts. All the feedback has been gratefully received. I just released Conduit 0.3.13 which, amongst other things, features some UI improvements based upon this feedback.
Improvements to the Conduit user interface.
Technically speaking, the release adds a knowledge framework to the application. This makes it easy to assist the user as they work through the interface. New features, utilizing this framework are;
Conduit now ships with a few example synchronization groups. These groups are shown to the user based upon the devices connected, and the data providers loaded. When the user selects an example, it is added to the canvas automatically.
I have added a message area to the bottom of the window. This provides a limited number of hints to the user depending on their interactions with the application.
Coming Up This release also lay a lot of the foundations for the few remaining big ticket items on the 0.4.0 TODO list. In the very near future we will see
Merging GIO port
Merging of Alexandre's SOC work, which will improve sound and video support in Conduit
The first release supporting Windows Mobile synchronization
Miscellaneous PIM improvements (Improved Google support, ability to merge attributes during conflict)
John Carr is currently working on the ATK accessibility implementation. As far as we can tell, there are no other PyGTK applications that have implemented accessibility in manner we wish to (manual implementation of the Atk interfaces from a objects not derived from GtkWidget). Lucly he works with Mark!
As far as using and distributing Conduit goes, it may get painful before it gets better. The next release will likely depend on PyGObject > 2.17 (for GIO support), and maybe PyWebkitGtk (SVN because of lack of recent, stable, compatible releases of this and WebkitGtk). My experience with (py)GIO so far has been exceptionally positive, and those out there who have used the train wreck that is gtkmozembed before will appreciate my desire to move to PyWebkitGtk.
Thank you everyone for their constructive comments on my previous post. A number of posters suggested the rounded boxes that conduit uses to group dataproviders were too bold, unnecessary, or both. I would like your opinion on which of the following four choices is the most suitable as a replacement.
Which is the best; 1,2,3 or 4?
Number four is the current implementation. I am leaning towards the first option as a replacement. From testing it seems to look the most consistent on different themes, and I believe it is the most suitable background to place (future) drag and drop hints on.
The discussions regarding my proposal for inclusion of Conduit into GNOME 2.24 seem to be going OK. The inevitable issue of Conduit's user interface has been raised, and it is good to see some constructive comments being posted.
It is a bit of a simplification, but I see basically three schools of thought with regard to the user interface for synchronizing things. What follows is a brief discussion of the pros and cons of each approach.
Everything should be automatically configured, and the current Conduit user interface should cease to exist - synchronization functionality/UI should be put into the respective application, calling into Conduit over DBus.
While I agree in theory, there is a enormous divide between theory and practice. For the foreseeable future it is not going to be possible to auto-configure synchronization parameters for all mobile devices. This is in part due to quirks in the devices, and in part because its sometimes not possible to enumerate all the things that a device supports without first configuring/pairing/connecting/etc with it.
Many web services require a authorization step, either once per application, or once per session. To make this easier on the user, Conduit hosts its own web browser for showing the login dialog in a consistent manner. I believe that this is the least surprising result to the user, if they sync something in conduit, the authentication should be done in conduit, not in the users default web browser, where they may not immediately recognize that it is Conduit that requires the authentication. Until we get some more online-desktopy stuff into GNOME (sharing auth cookies, authenticating services, etc) I think our approach is a good one.
I think it is important to have a single, consistent interface for resolving conflicts, this is currently in the Conduit GUI, but perhaps we could export it over DBus, like we do for the configuration dialogs.
Doing everything in other applications, reduces Conduits power to the lowest common denominator of these applications. Some of the cool power of Conduit is in the synchronization partnerships you can create that are not even tied to an application. For example, its possible to configure a 'sync' from Youtube, onto your iPod, that downloads and transcodes videos from you favorite user/channel. In what app would something like that go?
The conduit GUI should be simpler once you have configured everything.
This is the approach I agree with the most. I think. This could potentially involve some sort of minimize/maximize type button that when pushed, would collaps the main canvas down into something like the iSync user interface.
While I quite like that approach, I would almost rather implement an entire second GUI using only the Conduit DBus interface. This is the approach being persued by Alexandre (SOC student working on iPod support), and by John Carr (for a simplified windows mobile experience)
It was also suggested to make configuration easier, we should try gtk.Assistant.
Redesign the entire UI
Redesigning the Conduit GUI Today I decided to work on improving the current UI based upon some feedback on desktop-devel-list. First I spoke with my user interaction designer friend, and asked her what she thought. After 15 minutes of talking to an imaginary person that did not exist (any volunteers to be my interaction designer friend?) I decided to instead make some incremental improvements to the current UI. Some people may see this as re-arranging deck chairs on the Titanic, but hey, what have I got to lose?
The first step was to use the current theme colors. After a bit of looking around, I couldn't actually find a simple way to see what these were, so I wrote a quick application that draws color swatches for all the theme colors, in each of the widget states. If anyone wants so play with it, the code is available from my git repository.
Rounded rectangles make anything pretty.
With an idea of what colors are actually present, I changed the Conduit and DataProvider colors to use sensible colors from the theme. I also implemented some subtle gradients to make things a bit more GNOME.
Just kidding.
The result turned out pretty nice I think. This is the first time I have actually tried to make a custom widget match the user theme, and it was not too painful. One annoying limitation is that I only seem to get access to the matching style, but I would quite like to use colors from the tooltip style. It also gave me the opportunity to remove some UI clutter; I no longer show sources and sinks in different colors. Anyway the final result was;
Beautiful in brown, blue and black.
When I said subtle I really meant it. I would really appreciate it if a talented artistic hacker had a look at the code, and experimented with some more creative gradient settings. The function in question is get_style_properties which lives in conduit/gtkui/Canvas.py, and is implemented in all CanvasItem derived classes.
I then moved onto experimenting with waking the user through the sync and configuration process. I did some experiments using the Gedit message area to suggest steps the user could take. Thanks to Colin and HotSSH for the widget. Im not sure about this one.
Too much like Clippy?
Mathias suggested a visible drop target. I think this will be my next challenge. I also did an example implementation showing what the Conduit UI would look like if the outer, grouping, rounded rectangle was removed. Now a simple line differentiates different between conduits. What do you think?
Now with 29% less rounded rectangles.
Summary
I'm pretty happy with the themed colors. The work is available in my bzr branch, and will make it to trunk soon
There is continued discussion regarding UI ideas happening on live.gnome.org
My Gtk theme swatch too is available from
There will be a Conduit UI, of some sort, for the forseeable future. Lets spend some time making it better!
Updates
Fixed BZR Urls.
Added an example showing what Conduit look likes using a dividing line to differentiate dataproviders.
The theme swatch utility has been moved to github
GUADEC was effing awesome. I have successfully repayed my sleep debt, and can reflect on all that I observed and learned for the week. In bullet point form;
_Insurance for the last night (WAKE ME UP, English and Turkish) _
My Conduit talk went really well. I thought I was able to reach a good balance between 'this is cool for users', 'this is cool for developers', and 'this is a flagrantly useless technical demo because I can'. Following the talk, and over the rest of the week I had a number of chats with people regarding
Improvement hints for the UI. Thanks a lot Bastien and co.
What is considered a useful, and achievable, level of mobile device support.
Some technical clarifications on matters how to integrate into the desktop (webkit, gio, ui-via-dbus, etc)
I felt the reception to Conduit was positive, and I look forward to the module inclusion discussions for 2.24.
I was not productive on my summer of code project for that week, but I have come back with an overflowing amount of motivation to not only complete my work on binding syncml, but to also continue to add improvements that will help Conduit operate on Maemo and iPhone, and operate really well with Windows mobile devices, and Nokia devices (via gnome-phone-manager).
It was great to meet some of the people I have been corresponding with over email, and have never actually seen. You know who you are!
Electronica Festival Istanbul was a great adventure. Thanks to all that made it happen
Thanks to the GUADEC volunteers.
The 'tab meme' on planet.gnome.org was pretty funny. I was most fooled by Davyds. (am I the only one who kinda likes this metaphor?). I was also fooled in Federico's key note, when he proposed the NET_WM_I_CAN_HAS_TABS window hint for easy window -> tab transitioning (just kidding).
Captain common sense awards are hereby given to:
Team Gtk+: For the reasoned future of Gtk+ discussion/keynote. While I was disappointed to learn aboutthe lack of canvas plans, it is not really surprising. I use Goocanvas, but I am hardly a power user, and without a chosen Canvas, I have zero motivation to switch. I would describe the Gtk3.0+ plan as necessary+pragmatic. That is a damn site better than what it has appeard to be over the last few years (stagnant+idealistic).
Realease Time: Nice reveal on the Gnome 2.30 -> Gnome 3.0 animation
The BZR vs. git thing seemed to reach a whole new level of weirdness at GUADEC. First there was team BZR, whom I shall liken to a Turkish taxi driver. They seem to promise everything, they have the hard sell on, and you can never really be sure how much the cost will be. The git team seems to be like the seasoned traveller. They are showing the finger to the taxi drivers, and generally alternate between cursing at the incompetence of the taxi service, and ignoring them with glee. Instead of discussing the price with the taxi drivers, they instead have a prepared presentation on how flying cars are actually a million times better than taxis because they look so hot.
I actually dont really care what I use. Im not a power user. If I could somehow pay some sysadmin money to setup a unified GNOME themed viewvc that tracked both git and bzr I would. Thats all I want - to be able to track and see what folks are up to. I wrote more about this subject here.
I also support the notion of 'Pick the system that makes it easiest for the distributor to work with'. That likely means git. As a thought experiment, what might be the result of choosing git, or more correctly, rejecting bzr, in the wake of the Ubuntu is moving to KDE fear meme.
I Didnt realize the enormous (positive) influence that Nokia has on GNOME. Positive influence is a polite way of saying 'how much money they spend on Gtk+ related subcontractors, and employees'. Apparently something cool is coming for Maemo $NEXT_VERSION
If I have forgotten anyone, apologies. See you all next GUADEC!
Does anyone look like their Hackergotchi? (and can someone make me one - if you have a photo of me, and its moderately acceptable...)
Funniest moments would have to be
John Carr with a rats tail and silver necklace!
Me and Marks completely ineffective adventure from one side of Istanbul to the other, with no phone, no watch, no computers, no idea where anyone is, and death by hangover.
The humiliation/irony of singing really bad English Kareoke in a country whose official language is Turkish.
I have some interesting Conduit work going to land soon
Officially supported Windows Mobile sync support
Nokia phone support via gnome-phone-manager
Massive refactoring to improve platform abstractions
Which includes a move to GIO
Which adds a pygtkwebkit based browser
Which removes the hard dependency on gnome-keyring
Which adds and native python file/vfs abstraction
These improve performance and make it a billion times easier to run Conduit on Windows and Mac.
Well the first week of summer of code has finished. This week I spend my time evaluating and testing the various options available to (semi)automatically wrap C code (libsyncml) so that it is accessible from Python. My priorities when evaluating the options go something like,
Capability - the tool should be able to (semi) automatically wrap a large majority of the libsyncml api. Any customizations required in order to make the wrapping more complete should be readable and maintainable by people other than myself.
Documentation availablitly. Follows from #1, can I actually learn and use the tool within the SOC duration.
The wrapping tool is actively developed.
Does not introduce additional runtime dependencies other than the library being wrapped.
Minimal compile time dependencies when creating the bindings.
Community service value (i.e does the selection and use of the tool bring a positive benefit to the FOSS ecosystem greater than the actual library being wrapped).
The following is a list of available options I looked at (see cython for more explanation)
Pyrex Produce very nice and clean C file, which you just compile to .so and that's it. Allows to wrap almost any C and C++ code. IDL is python-ish.
Cython The same as Pyrex, but some new nice features added
SWIG The defacto standard I guess. SWIG is one of the oldest and most mature methods of wrapping C or C++ code into Python (SWIG works for other target languages as well). SWIG produces a C file from an IDL, which gets compiled to a .so, but then it also produces a Python wrapper on top of this. Because Python wrappers are written for you, if their design is not exactly what you want, you end up doing more work to create your final Python API.
SIP Similar to SWIG, but only aimed at wrapping C and C++ to Python. Unlike SWIG there is no Python wrapper. Used by PyQT and PyKDE.
Boost.Python Writes C++. Not evaluated due to the additional dependencies required.
Ctypes Ctypes is included standard in Python 2.5. The IDL is typically a python class hiding the ctypes calls, making the API more pythonic. It allows one to call library functions defined in shared object libraries directory from interpreted Python code.
Py++ It generates Boost.Python wrappers. Not evaluated.
f2py It's mostly for wrapping fortran files, but it can also wrap C files, even though it's not a very well-known feature. Not evaluated
PyD This works like boost.python, but for the D language. Not evaluated.
Interrogate This works similar to SWIG. It created dynamic link libraries that can be used both from python and c++ via the Python C API. No other files are needed. Its not very well documented but is used in several commercial mmorpg's and is native to the Panda3d engine. Not evaluated.
Robin Insufficient documentation to evaluate.Similar approact to swig, sans the intermediate IDL.
PyBindgen The IDL is itself python, and it generates clean readable dependency free C code. Designed for wrapping C++, but has some support for wrapping C libs.
pygobject (codegen.py and h2defs.py) The Gobject way, and the way I am most familiar. Unfortunately, in order to wrap the libsyncml library I would first need to wrape it in GObject.
Conclusions
The libsyncml library uses the Gobject mainloop, and custom error types. In order to integrate this with pygtk applications It would need to link to Pygobject/C, and propogate the error types to exceptions.
Somewhat unsurprisingly, the weak point in almost all of these approaches is there documentation. While I like the look of PyBindgen, it is a nightmare to build, and docs are sparse. The SWIG IDL is hairy, and one must also maintain pythonic wrappers to make a nice library. Pyrex and friends do not seem suited to the integration of libsyncml and pygobject without additional C glue
At this stage I am leaning towards SWIG, for community service value (others can come along after and make C# wrappers for instance), its availability of documentation, and even if the IDL is quirky, others are familiar with it.
Distributed Version Control Systems and visibility of development
My opinion on the 'best' DVCS is not relevant. What I am concerned about is that if GNOME does not pick one, and/or provide some sort of hosting or method to track other peoples development branches then the visible activity level, and subsequently health of the whole project will suffer.
The premise here is that centralized version control systems make it easy to follow what developers are working one, and the activity level of development, via the svn-commits mailing list for example.
I can only offer anecdotal evidence here, but I think that the visibility a projects development is just as important as the actual rate of development being done.
If developers cannot see what other people are hacking on, then there is the potential for duplication of work, or conflicting implementations.
If users do not see people actually doing work, then there is a tendency to assume the project is 'abandoned' or dead. The only thing worst than a 'dead' project is being proclaimed as such when one is not.
I consider the plethora of ways one can follow what developers are doing part of the problem, not part of the solution.
Who has time to follow planet, IRC, github, repo.or.cz, freedesktop git, launchpad.net bzr, mailing lists, twitter, $COMPANY gitweb, $PERSONAL gitweb, $DISTRO viewvc and gnome.org/$USER_HOME_DIR to see what people are working on.
This post is not meant to be Reductio ad absurdum, its just a slight generalization of why I read planet.gnome.org/svn-commits, etc, etc.
Part of the reason is to see what other hackers are up to.
Part is academic, to learn techniques and design from some of the great hackers on here.
Part is flagrant procrastination.
The small remaining part is the keep the voice in my head thats says "you should be using KDE, it appears to be more actively developed" at bay.
Conclusions, if any;
planet.ubuntu.com seems to have excellent visibility of active development, even if it doesn't have as many developers as other distributions.
freedesktop (via planet.freedesktop.org and http://gitweb.freedesktop.org/) seems to have excellent visibility of development (many people put git branches in their home directories, which are subsequently picked up by gitweb).
I am not advocating activity over productivity (obviously we are all free to use the tools which allow us to be the most productive, not just appear the most active). I just think that public FOSS development is an interesting space, in many ways the developers of the products are the marketers of it.
GNOME used to have the balance of visibility about right, but I think we are losing that with all this dilution.
Change scares me. That is all.
Frantic would be how I described my last two weeks. I have had very little free time to work on Conduit. Everything seems to have come at once!
I got accepted for summer of code - adding SyncML support to Conduit.
Alexandre Inacio Rosenfeld also got accepted to SOC to work on Ipod and media support in Conduit.
I got accepted to speak at GUADEC, which I will be attending, providing all finances work out.
It looks likely that, as part of my PhD, I will be spending a few months at ENAC (home of the Paparazzi UAV).
Random
I have been playing with barpanel, a very functional GNOME panel replacement.
Grape is certainly an interesting UI/desktop mock up. If I had infinite spare time I migh have a hack on it, as an excuse to play with Clutter.
Props to Jan Bodnar for his excellent Gtk+ and Cairo tutorials.
My (bad) experiences with Ubuntu 8.04 can be best described by the following picture..
Openstreetmap GPS Mapping Widget
Somewhat tangentially related to my PhD, I have been hacking on a simple Openstreetmap GPS mapping/display widget. Basically because after investigating all the existing mapping programs on linux, none of them supported openstreetmap/openaerialmap and were able to be easily embedded.
It's basically a port of tangoGPS (by Marcus Bauer) to libsoup and considerable clean-up. The whole thing is now hidden behind a derived GtkDrawingArea with a nice simple 4 function api (other parameters such as zoom, lat, lon, are accessible as gobject properties)
set_map_center(double lat, double lon, int zoom)
add_gps_point(double lat, double lon)
add_roi(double lat, double lon, GdkPixbuf *pixbuf)
get_bouding_box()
Things like double click, map dragging, scroll to zoom, etc are all handled automatically as you would expect. It caches downloaded tiles and it's pretty much complete at this point. I hope to be able to post code soon.
