Commit by beschow :: r1253658 /trunk/www/sites/edu/marble/download.php: (link)

use download from files.kde.org

Commit by beschow :: r1226647 marble/trunk/KDE/kdeedu/marble/src/lib/ (MarbleWidget.cpp MarbleWidget.h): (link)

allow to add/remove layers to/from a MarbleWidget by forwarding MarbleMap::addLayer() and removeLayer()

Commit by beschow :: r1226647 /trunk/KDE/kdeedu/marble/src/lib/ (MarbleWidget.h MarbleWidget.cpp):

allow to add/remove layers to/from a MarbleWidget by forwarding MarbleMap::addLayer() and removeLayer()

Commit by beschow :: r1226644 marble/trunk/KDE/kdeedu/marble/src/lib/ (3 files): (link)

StackedTileLoader: merge reloadTile(), tilesOnDisplay(), and reloadCachedTile() into reloadVisibleTiles(). Use reloadVisibleTiles() in TextureLayer::reload().

This patch does not only remove lots of unused and redundant code, but also seems more efficent, since tileUpdatesAvailable() is signalled only once rather than once for each cached tile in reloadCachedTile().

Commit by beschow :: r1226643 marble/trunk/KDE/kdeedu/marble/src/lib/StackedTileLoader.cpp: (link)

call StackedTile::initResultTile() only within StackedTileLoader::mergeDecorations()

Both methods were always called in a row, except for one occurrence, which seems to be a mistake.
At least I don't see a reason why StackedTileLoader::reloadTile() should deal with tile decorations differently than StackedTileLoader::loadTile().

Since StackedTileLoader::reloadTile() is only called for visible tiles in TextureLayer::reload(), d->m_tilesOnDisplay should contain every tile in question.
Therefore, the code path is never executed anyway.

Commit by beschow :: r1226642 marble/trunk/KDE/kdeedu/marble/src/lib/ (2 files): (link)

move StackedTileLoader::findRelevantTextureLayers() into private class

Commit by beschow :: r1226641 marble/trunk/KDE/kdeedu/marble/src/lib/ (4 files): (link)

remove download usage parameter from StackedTileLoader::loadTile, since it is always set to DownloadBrowse

• In general, stacked tiles can (at least currently) be considered to be used for browsing. Therefore, the parameter seems redundant.

Commit by beschow :: r1226644 /trunk/KDE/kdeedu/marble/src/lib/ (3 files):

StackedTileLoader: merge reloadTile(), tilesOnDisplay(), and reloadCachedTile() into reloadVisibleTiles(). Use reloadVisibleTiles() in TextureLayer::reload().

This patch does not only remove lots of unused and redundant code, but also seems more efficent, since tileUpdatesAvailable() is signalled only once rather than once for each cached tile in reloadCachedTile().

Commit by beschow :: r1226643 /trunk/KDE/kdeedu/marble/src/lib/StackedTileLoader.cpp:

call StackedTile::initResultTile() only within StackedTileLoader::mergeDecorations()

Both methods were always called in a row, except for one occurrence, which seems to be a mistake.
At least I don't see a reason why StackedTileLoader::reloadTile() should deal with tile decorations differently than StackedTileLoader::loadTile().

Since StackedTileLoader::reloadTile() is only called for visible tiles in TextureLayer::reload(), d->m_tilesOnDisplay should contain every tile in question.
Therefore, the code path is never executed anyway.

Commit by beschow :: r1226642 /trunk/KDE/kdeedu/marble/src/lib/ (2 files):

move StackedTileLoader::findRelevantTextureLayers() into private class

Commit by beschow :: r1226641 /trunk/KDE/kdeedu/marble/src/lib/ (4 files):

remove download usage parameter from StackedTileLoader::loadTile, since it is always set to DownloadBrowse

• In general, stacked tiles can (at least currently) be considered to be used for browsing. Therefore, the parameter seems redundant.

Commit by beschow :: r1226568 marble/trunk/KDE/kdeedu/marble/src/ (6 files in 2 dirs): (link)

make MapWizard modal

Commit by beschow :: r1226568 /trunk/KDE/kdeedu/marble/src/ (6 files in 2 dirs):

make MapWizard modal

Commit by beschow :: r1226566 marble/trunk/KDE/kdeedu/marble/src/lib/ (9 files): (link)

move all attributes of MarbledataFacade into MarbleModel

• forward in MarbledataFacade rather than in MarbleModel

Commit by beschow :: r1226567 /trunk/KDE/kdeedu/marble/ (42 files in 16 dirs):

remove MarbleDataFacade; use MarbleModel instead

MarbleDataFacade was a read-only wrapper for MarbleModel and was used in RenderPlugins. Since MarbleModel is exported and can be made const in the RenderPlugins, MarbleDataFacace is redundant.

REVIEW: 6624

Commit by beschow :: r1226566 /trunk/KDE/kdeedu/marble/src/lib/ (9 files):

move all attributes of MarbledataFacade into MarbleModel

• forward in MarbledataFacade rather than in MarbleModel

Commit by beschow :: r1226383 marble/trunk/KDE/kdeedu/marble/src/ (10 files in 6 dirs): (link)

unused variables-- (reported by GCC 4.6)

Commit by beschow :: r1226383 /trunk/KDE/kdeedu/marble/src/ (10 files in 6 dirs):

unused variables-- (reported by GCC 4.6)

Commit by beschow :: r1226292 /trunk/KDE/kdeedu/marble/ (8 files in 3 dirs):

provide data via MarbleModel only; do not forward in MarbleWidget

• Remove the following methods from MarbleWidget: void home( qreal &lon, qreal &lat, int& zoom ); void setHome( qreal lon, qreal lat, int zoom = 1050 ); void setHome( const GeoDataCoordinates& homePoint, int zoom = 1050 ); Use the respective methods of MarbleModel.

Commit by beschow :: r1226291 /trunk/KDE/kdeedu/marble/ (3 files in 2 dirs):

remove MarbleWidget::map()

• there should be forwarders in MarbleWidget for all relevant methods of MarbleMap