[Marble-devel] Projection classes

[Torsten Rahn]

On Thursday 01 May 2008 15:41:50 Inge Wallin wrote:
> > 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. 

Yes it is vector stuff. And in this case the point of having the background 
painted by the vector backend is done for a good reason: in this case it's 
not about bitmaps: we want to avoid filling a bitmap with a certain color to 
be able to avoid that a QImage needs to get transferred to the graphics card.

This particular backend paints everything it receives as polygons using the 
QPainter API. So we are expressing the body of the planet in terms of 
something that can get rendered by the vector backend API.
Actually you might be right that there is a more fitting place: the 
GeoSceneTarget object could provide data that describes the outline of the 
globe and that outline could get rendered by the vector backend (using the 
projection) and filled with the specified color. That would be a pretty hard 
to do solution though.


> A projection itself, maybe not.  But the visualization of a projection:

There is no such thing as a "Visualization of a projection". 

A projection always gets applied to some data. A projection is something 
abstract. You are right that a projection only can get visualized if there is 
some data that the projection can get applied on. However that's not subject 
to the projection itself.

Allowing the addition of all kinds of visual kind of data classes would not 
only introduce lots of dependencies of the projection class to various 
classes all over Marble. You'd basically allow the inclusion of everything 
that gets projected (that's all kind of data) to be part of the projection 
class. 

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

Nope, the fact that you are using the verb "painting" a polygon (using a 
projection) and not "projecting" (a polygon using a painter) should make 
pretty clear what's going on here :-)

> 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.

I think then we can basically add all kinds of placemark methods as well, as 
placemarks visualize the projection as well. And we could add all kinds of 
texturemapping methods as they visualize the projection in terms of textures.

Sorry, but for obvious reasons I have a strong dislike for opening this can of 
worms.

> > 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.

We want functionality in terms of layers to be added in the first place. And 
for that to happen I don't see how we can choose an approach that isn't 
viable for 3rd party developers.

> And frankly I don't 
> understand how it would add much code at all.

It would add 2 files per projection, including comments, constructors method 
names #ifdef's in a completely different place. It would sort them in 
arbitrary order in long files with the relationship to the actual location 
where they are needed to be only "suggestive" via grepping. 

Torsten

> 	-Inge
> _______________________________________________
> Marble-devel mailing list
> Marble-devel at kde.org
> https://mail.kde.org/mailman/listinfo/marble-devel



-- 
 Torsten Rahn

 Tel.: 0 21 61 - 46 43 - 192

credativ GmbH, HRB Mönchengladbach 12080
Hohenzollernstr. 133, 41061 Mönchengladbach
Geschäftsführung: Dr. Michael Meskes, Jörg Folz