Plans for 0.8

[Jiří Techet <techet gmail com>]

Hi everybody,

as I promised, here's a list of things I'd like to implement during
the 0.8 development cycle (it'll be rather short, we have only 4
months left). The things I'd like to address in this release are
mainly architecture-related. I've been thinking a lot about
libchamplain architecture and the thing I'd like to achieve is to
create a compact core which can be easily extensible, but which
doesn't have to care about these extensions. The things I want to do
can be summarized in two points:

1. Implement this:

http://mail.gnome.org/archives/libchamplain-list/2010-January/msg00053.html

In my opinion this will simplify creation of new map sources and
unifies the things we currently do in a different way (data sources
for memphis basically are map sources, they just have a different
interface so it makes sense to have only one superclass for them).

2. I've been thinking a lot about simplifying ChamplainView which is
without any doubt the scariest place of libchamplain and a place where
hard-to-kill bugs live. The bad thing about it is that with the
current architecture it has to care about too many things - it has to
redraw polygons, it has to redraw layers, it has to redraw the scale,
and so on. This architecture also doesn't scale very well - for every
new graphical element we also have to add a set of functions to
ChamplainView that manipulate it. To make everything customizable we
would have to add a huge number of functions.

What I propose is to make ChamplainView just to draw the map and all
the rest to be implemented as clutter actors, which can be then
manually added to ChamplainView. We have to distinguish two types of
actors:

a. those which move together with the map (e.g. markers, polygons)
b. those whose position is static (e.g. the scale)

I think the current concept of layers for moving actors is OK, so
there won't be much change here for markers - the only difference will
be that ChamplainView will not have to know what type of layer is
redrawn - ChamplainView will just emit signals for particular events
e.g. when redraw is necessary and it will be the responsibility of the
layer to subscribe for this signal to get repainted. So apart from
displaying the layer on top of the map, ChamplainView will not have to
care about the layers at all.

For static actors it's even simpler - ChamplainView already implements
the ClutterContainer interface so the static elements can be inserted
to it very easily. Again, they can connect to various signals so e.g.
the scale gets updated when you move the map.

These are about all the main changes I'd like to do. In this release
I'd like to focus on the architecture so we don't have to change the
interface much in the future releases. I'm aware that breaking the
interface isn't very friendly towards the applications, on the other
hand I'm convinced that what I propose will make libchamplain much
easier to maintain and extend it in the future.

If there is some time left, I'd also like to address some enhancement
suggestions from bugzilla. In particular I have been thinking how to
make zoom in/out nicer and it shouldn't be too hard to implement.
First, though, I want to implement the architecture-related things
because the minor improvements can be done even after API freeze in
August.

Now it's your turn - please tell me if there is something you dislike
about my ideas or if there is something that you think should be
addressed with higher priority. And this is the right time to tell us
if you plan to implement some feature by yourself - this way it will
be easier to synchronize and avoid unnecessary merge conflicts.

Thanks,

Jiri