[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-devel
Subject: Re: seeking QGraphicsView wisdom
From: Jason Harris <kstars () 30doradus ! org>
Date: 2006-05-29 14:21:28
Message-ID: 200605290721.28828.kstars () 30doradus ! org
[Download RAW message or body]
On Friday 26 May 2006 00:34, Andreas Aardal Hanssen wrote:
> On Thursday 25 May 2006 17:55, Aaron J. Seigo wrote:
> > > (2) Is it feasible to extend QGraphicsView such that it uses a
> > > spherical coordinate system, rather than a rectilinear one? Are the
> > > transformation and clipping functions exposed in the API?
> >
> > that i'm not sure about. i don't think so, however. andreas hanssen could
> > answer authoritatively on this, however. ergo the CC =)
>
> QGraphicsScene is strictly rectilinear, so if you want
> spherical coordinates, you probably need to maintain both
> coordinate systems, and map your spherical coordinates (and
> transformations) to rectilinear ones.
>
> I cannot imagine an API that provides an abstract coordinate
> system ;-). If you can come up with one, I'm all ears!
>
Wouldn't you just put the transformations into a function that can be
subclassed? Your transformations in QGraphicsView assume that the Data
coordinate system is a rectilinear coordinate system, so your transformations
will just involve a global rotation and a linear scale factor (probably
implemented with a matrix transformation). You could put this into a pair of
functions:
virtual QPointF toScreen( const QPointF &DataPoint );
virtual QPointF fromScreen( const QPointF &ScreenPoint );
(I've assumed that QGraphicsView "knows about" the scale and rotation, so you
don't need to pass them as arguments)
Then I could subclass KStarsSphericalView from QGraphicsView, and override
these functions to do the data-to-screen transformations that I need. Would
it impact the performance of QGraphicsView to make the transformations a
function call like this?
Assuming the transformations can't be abstracted in this way, then our only
alternative would be as you say: we have to transform to rectilinear
ourselves, and then populate the QGraphicsView item tree with the
rectilinearized coordinates. However, we have to re-project every time the
center position is changed, so we'd be constantly repopulating the item tree
in QGV. I guess this would slow things down quite a bit.
--
KStars: http://edu.kde.org/kstars
Community Forums: http://kstars.30doradus.org
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic