[Marble-devel] Projection classes

[Inge Wallin]

On Thursday 01 May 2008 14:05:39 Torsten Rahn wrote:
> On Thursday 01 May 2008 10:49:54 Inge Wallin wrote:

> > this is VectorMap::paintBase() which paints the background of the map
> > before the actual map itself is painted. There are many more spread
> > around the code.
> > So, where should I put code like that?
>
> Well, I can't answer the question "like" that as I suspect that each of
> those cases is rather unique and hence would require a case by case
> decision.

That may very well be the case.  Perhaps in some cases a 'switch' statement is 
best, even if I doubt it.

> For this particular case we are talking about backend code that is meant to
> perform an action that is specific to the plugin (the vector backend
> plugin). This action would have to be executed differently depending on the
> projection.

I didn't say it, but painting the background of a bitmap is definitely not 
vector stuff.  So in this case, not only is the structure not good (switch, 
etc), but it is also totally in the wrong place.  But since that is of no 
matter for the question at hand, I just didn't mention it.

> So we are talking about plugin specific code. Given that this plugin might
> be removed, replaced and accompaigned by other plugins I don't think that
> this code (which is very specific to this particular plugin and certainly
> won't be used elsewhere) should get added to our current projection class
> -- especially given that we'd like to maintain API/ABI compatibility
> somewhere this year.
> Another reason is of course the fact that "painting a backend" is not
> subject to a "projection" class. Have you ever seen a projection "paint a
> base"? No. A projection gets maybe used to paint something but the
> projection per se isn't responsible for tasks like this.

A projection itself, maybe not.  But the visualization of a projection: 
definitely.  And that is what we are talking about here.  In marble, it's not 
the projection itself (which is just a short mathematical formula) that is 
important, but the visualization of it. 

So yes, painting the background of the visualization of the projection is 
something that belongs to the projection as it is used within Marble. 

> So I don't think that this code should be added to the current projection
> classes.

If we decide that the projection classes should not only deal with the 
mathematical abstraction, but also with visualization, I do think it should 
be added.

And in fact, I'm leaning very strongly in that direction now.

> Solution 2 would be about having a "dumping place" like set of projection
> helper classes where we collect code from different plugins that are
> specific to these classes and that don't fit elsewhere. A 3rd party
> developer of a plugin wouldn't be able to add further code to these helper
> classes without changing the original code or without shipping a set of
> helper classes inherited from the original helper class.
>
> By the way: like with the other example you came up with this particular
> issue has a general solution for most "flat" projections ("draw a
> rectangle") and a special one for others.
>
> > Right now I lean towards #1, but can be persuaded to use #2 or even some
> > other, even better, scheme if somebody comes up with good arguments for
> > either.
>
> Yeah, this is definetly a "pick your poison case" (again I'm only talking
> about this particular paintBase case).
> For the reasons given I'd rather prefer #2 if I had to choose between those
> two. I dislike both solutions as they
>
> a) encourage thoughtless additions of code that could actually get added in
> better ways and in a more generic way elsewhere.

We will always have that problem. In fact I'd go so far as to state that we 
have that exact problem right now.

> b) they don't take the nature of the plugin architecture into account.

They do.  For one thing, projections are not plugins themselves right now, but 
if we ever want them to be, we *need* to collect everything that has to do 
with (the visualization of) projections in one place.

And there is nothing that says that we couldn't use this scheme to provide for 
a number of helper functions to be used in the other plugins.

> c) they offer little merit over the existing switch statements (which I
> dislike, too) and add a significant amount of additional code and files
> that don't make maintenance easier.

The main merit is that they collect things that have to do with a single 
projection in one place.  And that's a big merit.  And frankly I don't 
understand how it would add much code at all.

	-Inge