[Qgis-developer] What will be in QGIS 2.0
Radim Blazek
radim.blazek at gmail.com
Thu Jul 12 23:57:01 PDT 2012
On Thu, Jul 12, 2012 at 10:12 AM, Martin Dobias <wonder.sk at gmail.com> wrote:
>> I have doubts for example, if the quantity of circular dependencies is
>> good. See for example
>> http://qgis.org/api/classQgsMapCanvas.html
>
> Personally, I do not see a problem in this particular instance, do
> you? The only circular dependencies shown there are between
> QgsMapCanvas and QgsMapTool / QgsMapCanvasMap / QgsMapOverviewCanvas -
> and those are fine because they need to communicate with QgsMapCanvas.
As I said, I have doubts, I am not sure if it is a problem or how it
is important. I remember, that once I was looking for something
around QgsMapCanvas and I found it quite difficult due to the circular
dependencies. I think that it is especially a problem for readability,
which I consider very important in OS project.
For example, QgsMapCanvasMap is using QgsMapCanvas in 2 methods to get
QgsMapRenderer (QgsMapCanvas member) and call its methods. When
reading QgsMapCanvasMap source, you don't see that calling
QgsMapCanvasMap methods modifies QgsMapRenderer:
void QgsMapCanvasMap::resize( QSize size ) {
...
mCanvas->mapRenderer()->setOutputSize( size, mPixmap.logicalDpiX() );
}
it is used in QgsMapCanvas:
mMap->resize( size() );
I would prefer to set QgsMapRenderer size in QgsMapCanvas, either
simply something like
mMap->resize( size() );
mMapRenderer->setOutputSize( mMap->size() );
or with a resize signal from QgsMapCanvasMap.
The second method is
void QgsMapCanvasMap::render() {
...
mCanvas->mapRenderer()->render( &paint );
}
which may be simply changed to
void QgsMapCanvasMap::render( QgsMapRenderer* renderer) {
...
renderer->render( &paint );
}
We would have one circular dependency less with just 2 simple changes.
In this case I don't see any real reason for circular dependency, it
does not seem to be intentional design, it seems that this
constellation appeared somehow itself during code evolution.
I believe that 2.0 API break is good opportunity to review such places.
Radim
More information about the Qgis-developer
mailing list