1. 20 Oct, 2016 7 commits
  2. 19 Oct, 2016 3 commits
  3. 16 Oct, 2016 10 commits
  4. 15 Oct, 2016 1 commit
  5. 13 Oct, 2016 5 commits
  6. 12 Oct, 2016 1 commit
  7. 11 Oct, 2016 1 commit
  8. 10 Oct, 2016 3 commits
  9. 09 Oct, 2016 3 commits
  10. 07 Oct, 2016 3 commits
    • Friedrich W. H. Kossebau's avatar
      Introducing GeoSceneAbstractTileProjection for tile x/y <-> lonlat · 5c1022d1
      Friedrich W. H. Kossebau authored
      In the current code in some places hard assumptions are made about
      the projection used by the tile material. Also are calculations
      The new abstract class GeoSceneAbstractTileProjection and its currently
      two concrete subclasses GeoSceneEquirectTileProjection & GeoSceneMercatorTileProjection
      should allow to make most code agnostic of the tile projection details
      and also remove the code duplication, also makes unit testing of the projection easy.
      GeoSceneAbstractTileProjection follows the concepts of AbstractProjection
      and has conversion methods in the interface, with the output vars as
      non-const references at the end of the argument list (for consistency, I personally
      prefer yielded stuff as return parameter, or have output vars at least being
      first in the argument list and as pointers for improved markup in the calling code).
      As the current two implementations need to know about the variables
      levelZeroColumns and levelZeroRows, I made these properties of the classes
      themselves, to avoid having the classes depend on GeoSceneTileDataset.
      Comes at the cost of data duplication and thus more complicated setup,
      but also avoids an indirection in the class methods using these values.
      For simplicity I put these properties onto GeoSceneAbstractTileProjection
      itself, to avoid another intermediate abstract subclass for the concept of
      levelZeroColumns and levelZeroRows.
      The projection methods do not do any out-of-bounds handling, but expect
      the calling code to pass proper value. Which should be valid with the current
      Any methods tileProjection() have been renamed to tileProjectionType(),
      to make clear those just return the type, not a projection object.
      The patch also makes TileId more dump again and just a property container,
      especially no longer knowing about GeoSceneTileDataset.
      * Look into all remaining places which have "if tileProjectionType() == x" to see
        how they can be made tile projection type agnostic as well
      Reviewers: rahn, #marble
      Reviewed By: rahn, #marble
      Subscribers: rahn
      Differential Revision: https://phabricator.kde.org/D2780
    • Friedrich W. H. Kossebau's avatar
    • Friedrich W. H. Kossebau's avatar
      Qt'fy access to pimpl objects for MarbleGraphicsItem & subclasses · cafdd1e7
      Friedrich W. H. Kossebau authored
      Also remove separate pimpl objects and make subclasses of MarbleGraphicsItemPrivate:
      FrameGraphicsItemPrivate, LabelGraphicsItemPrivate, WidgetGraphicsItemPrivate
  11. 06 Oct, 2016 1 commit
  12. 05 Oct, 2016 2 commits