Re: Plans for 0.8

[Jiří Techet <techet gmail com>]

On Sun, May 30, 2010 at 21:42, Tomaž Vajngerl <quikee gmail com> wrote:
> Hi,
>
> On Sun, May 30, 2010 at 1:53 PM, Jiří Techet <techet gmail com> wrote:
>> 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.
>
> Yes this part needs to change. I hate it that ChanplainView has
> add_layer and add_polygon - it should have only one. To go even
> further I would like that a Layer is a representation of a invisible
> sheet to which whatever can be added not only markers but also
> polygons and pictures. A layer should have then handle all its group
> of elements - like show/hide, etc.
> Polygons could be seen as a layer on its own but only if BasicMarker
> is also a Point or a graphical representation of a Point. The
> consequence is that Markers could be connected with each other or even
> in a loop.
>
> So one of my suggestion is:
> * View has Layers.
> * Layers have Markers/Points
> * Markers/Points can be connected to form Polygons.
>
> Another suggestion is:
> * View has Layers
> * Layers has Shapes
> * Shapes are either Markers or Polygons
> * Polygons are connected Points
>

Up to here this is almost exactly what I want to do. The layers will
be ClutterContainer instances - exactly what you call "invisible
sheet". I just have to think a bit about the object hierarchy and the
best way to draw polygons.

> Also other enhancements (smaller and bigger) that I have in mind:
> * Inconsistencies in naming that I would like it is removed. A Point
> has lat, lon and BasicMarker has latitude and longitude. it would be
> better either the names are the same or BasicMarker should have a
> Point.

BasicMarker should inherit from ChamplainPoint - this is a duplicity
in the current interface that I don't like either.

> * ChamplainView should provide a BoundingBox of current view.
> longitude and latitude are not needed anymore because of
> BoundingBox.get_center

Possibly.

> * There are a lot of get set functions with addition to properties.
> Are they still needed?

Many of them will disappear I think.

> * Resize on zoom marker - which means that marker changes size (scale)
> depending on zoom level which makes the map more readable when zoom
> level is bigger.
> * When markers are to close together it is hard to select the right
> one - somehow make them selectable (maybe like in Google Earth or
> Marble). When they are selected have the ability to move the marker to
> front.
> * Ability to easy move markers and in case of polygons create new
> points (like in Google Maps or Merkaartor or JOSM).
> * Maybe not something for 0.8 but a WMS as a map source would be cool.
> * Another bigger thing map zoom level independent drawing - which
> means that zoom is not dependent on what map supports but zoom is
> fixed and map is rescaled if necessary.
> * Maybe some other things...

To be realistic, I think these won't be ready for 0.8, but many of
them are good ideas (including Keith's suggestion). Of course anyone
is welcome to implement them but it would be better to wait until I
make the bigger architecture changes.

Thanks for your feedback!

Jiri

>
> Regards, Tomaž
>