[Marble-devel] Re: Review Request: Move painting methods from MarbleModel to MarbleMap

Bernhard Beschow bbeschow at cs.tu-berlin.de
Fri Nov 26 15:04:09 CET 2010



> On 2010-11-23 00:11:07, Thibaut Gridel wrote:
> > A first look at the patch, excellent work. The hidden comment "This function will probably move to MarbleWidget in KDE4.1, making the MarbleModel/MarbleWidget pair truly follow the Model/View paradigm" is long overdue!

Thanks for your comment!


> On 2010-11-23 00:11:07, Thibaut Gridel wrote:
> > /trunk/KDE/kdeedu/marble/src/QtMainWindow.cpp, line 1139
> > <http://svn.reviewboard.kde.org/r/5902/diff/1/?file=41472#file41472line1139>
> >
> >     model seems not used anymore here

I think you're right and I'll remove it after I have a look.


> On 2010-11-23 00:11:07, Thibaut Gridel wrote:
> > /trunk/KDE/kdeedu/marble/src/lib/MarbleMap_p.h, line 66
> > <http://svn.reviewboard.kde.org/r/5902/diff/1/?file=41479#file41479line66>
> >
> >     I guess most of this code was moved, so more changes could still wait a bit.
> >     
> >     Is it expected to change to pointers here, at least for all layers so they could simply be added to the LayerManager, and have a consistent manipulation?

I agree that this patch should solve as few things at a time as possible. However, I wanted to make sure that the initialization sequence in the constructor is absolutely clear since that eases further refactoring significantly.

Having a common layer interface for all sorts of layers will be possible with the new layer interface which I want to postpone to 4.7 since I don't want to put more pressure on other developers.


> On 2010-11-23 00:11:07, Thibaut Gridel wrote:
> > /trunk/KDE/kdeedu/marble/src/lib/MarbleModel.cpp, line 155
> > <http://svn.reviewboard.kde.org/r/5902/diff/1/?file=41481#file41481line155>
> >
> >     Don't know enough of the StackedTileLoader to determine if it is more a model store or a layer rendering class...
> >     
> >     Maybe this class could benefit from a split, with storing in model and rendering in map? (maybe it doesn't have sense to split so...)
> >     
> >     Is it used in GL with either role?

The StackedTileLoader is responsible for merging/bleding tiles form different textures into one. As such, it is part of the graphical representation.

The split you mention is already there: There is one TileLoader which actually loads the tiles from different textures and passes them to the StackedTileLoader. The TileLoader currently lives inside the StackedTileLoader but I'd like to keep it this way in this patch since I don't want to increase the size and complexity of this patch even further. :)


> On 2010-11-23 00:11:07, Thibaut Gridel wrote:
> > /trunk/KDE/kdeedu/marble/src/lib/MarbleMap.cpp, line 827
> > <http://svn.reviewboard.kde.org/r/5902/diff/1/?file=41478#file41478line827>
> >
> >     In a later version, could be useful to have layers react directly to theme change.
> >     For instance, veccomposer would update its properties in its own slot for setMapThemeIt

An alternative approach would be to create a new stack of layers on every theme change. That way, the layers wouldn't have to deal with theme changes at all. All this could be implemented in a map builder class which creates a stack of layers from a GeoSceneDocument. With a nice GUI on top we could even have a graphical map theme editor.


- Bernhard


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://svn.reviewboard.kde.org/r/5902/#review8909
-----------------------------------------------------------


On 2010-11-19 16:07:35, Bernhard Beschow wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://svn.reviewboard.kde.org/r/5902/
> -----------------------------------------------------------
> 
> (Updated 2010-11-19 16:07:35)
> 
> 
> Review request for marble.
> 
> 
> Summary
> -------
> 
> Motivation
> ==========
> 
> The whole painting should be implemented in the view rather than in the model because it decouples data and its representation. This allows for having different graphics backends (hello OpenGL!) while having a common interface to the data.
> 
> 
> Implementation
> ==============
> 
> MarbleMap is now the owner of all painting objects, e.g. the MeasureTool, a new TextureLayer class, the LayerManager, and others. To see all painting objects owned by MarbleMap, see the modified MarbleMap_p.h.
> 
> Since the LayerManager object is now owned by MarbleMap, the layer-relevant methods, slots, and signals (such as addLayer(), removeLayer(), renderPluginsInitialized()) are now forwarded by MarbleMap and Marblewidget rather than by MarbleModel.
> 
> The DownloadRegionDialog has been modified to take a MarbleWidget instead of a MarbleModel. I wonder if it makes more sense to take a MarbleMap here.
> 
> Please test if the patch works for you as well. Since the patch changes some initializaton orders in the constructors and some re-initialization orders on theme change, it is important to test these code paths more extensively.
> 
> If you see that the patch violates some assumptions/invariants, please report as well.
> 
> 
> Diffs
> -----
> 
>   /trunk/KDE/kdeedu/marble/src/ControlView.cpp 1198738 
>   /trunk/KDE/kdeedu/marble/src/QtMainWindow.cpp 1198738 
>   /trunk/KDE/kdeedu/marble/src/lib/AbstractScanlineTextureMapper.h 1198738 
>   /trunk/KDE/kdeedu/marble/src/lib/CMakeLists.txt 1198738 
>   /trunk/KDE/kdeedu/marble/src/lib/DownloadRegionDialog.h 1198738 
>   /trunk/KDE/kdeedu/marble/src/lib/DownloadRegionDialog.cpp 1198738 
>   /trunk/KDE/kdeedu/marble/src/lib/MarbleMap.h 1198738 
>   /trunk/KDE/kdeedu/marble/src/lib/MarbleMap.cpp 1198738 
>   /trunk/KDE/kdeedu/marble/src/lib/MarbleMap_p.h 1198738 
>   /trunk/KDE/kdeedu/marble/src/lib/MarbleModel.h 1198738 
>   /trunk/KDE/kdeedu/marble/src/lib/MarbleModel.cpp 1198738 
>   /trunk/KDE/kdeedu/marble/src/lib/MarbleWidget.h 1198738 
>   /trunk/KDE/kdeedu/marble/src/lib/MarbleWidget.cpp 1198738 
>   /trunk/KDE/kdeedu/marble/src/lib/MarbleWidgetInputHandler.cpp 1198738 
>   /trunk/KDE/kdeedu/marble/src/lib/MarbleWidgetPopupMenu.cpp 1198738 
>   /trunk/KDE/kdeedu/marble/src/lib/PlacemarkLayout.cpp 1198738 
>   /trunk/KDE/kdeedu/marble/src/lib/StackedTileLoader.h 1198738 
>   /trunk/KDE/kdeedu/marble/src/lib/StackedTileLoader.cpp 1198738 
>   /trunk/KDE/kdeedu/marble/src/marble_part.cpp 1198738 
>   /trunk/KDE/kdeedu/marble/src/plasmoid/worldclock.cpp 1198738 
> 
> Diff: http://svn.reviewboard.kde.org/r/5902/diff
> 
> 
> Testing
> -------
> 
> Works for me using the KDE version in the majority of cases.
> 
> 
> Thanks,
> 
> Bernhard
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/marble-devel/attachments/20101126/8bc52174/attachment-0001.htm 


More information about the Marble-devel mailing list