< Marble(Redirected from Marble 2.0)

Marble/Marble 2.0

Refactoring goals towards a Marble 2.0 version.

Marble Library Split

Split libmarblewidget into several libraries:

  • libMarbleCore (or libMarbleMap?)
    • Non-interactive classes, e.g. geodata, file parsing
    • Interactive, UI toolkit independent classes, e.g. layers, graphicsview
    • No dependency to QWidgets or Qt Quick
  • libMarbleWidgets
    • QWidget related interactive classes
    • Dependency to QWidget, libMarbleCore
  • libMarbleQuick
    • Qt Quick 2.0 related interactive classes
    • Dependency to QtQuick, libMarbleCore
  • Further possible ones (see also plugins below): MarbleRouting, MarbleTours, MarbleMapEditor

Header Normalization

  • During compilation, the subdirectories of marble/ are not added to the compiler search path anymore, so #include statements need to use the full path marble/$module/$class.h for files outside their directory.
  • Headers follow the directory structure marble/$module/$path, where $path is either a filename or a directory + filename, but not deeper nested

Build System Improvements

  • The header structure in src/lib/ should match the exported headers in include/. No "flattening" as it happens currently where e.g. marble/geodata/* is copied to /marble/.
  • KDE as a dependency is only used in src/apps/marble-kde and KDE related things like plasmoids. No KDE usage in the library. As a side effect, QTONLY will go away (replaced by a less restrictive WITH_KDE) Implemented since Applications/15.08
  • Provide a sane FindMarble.cmake, possibly using COMPONENTS similar to Qt, Boost (each library would be a component)

Qt Version Dependency Bump

  • Require at least Qt 5.0 to avoid a maintenance nightmare
  • Require KDE Frameworks 5 (optional, but kdelibs 4.x not supported) Implemented since Applications/15.08
  • Require Qt Quick 2.0 (optional, but Qt Quick 1.1 not supported)
  • Provide a long term support stable branch with Qt 4.x / KDE 4.x / Qt Quick 1.1 support Please use Applications/15.04 for that

Plugin Sanitization

  • Clearly split between the loading mechanism and the interface (API) such that extensions can be realized both inside a library and via plugins without hassles (emphasis on without hassles)
  • Deleting plugins should be possible and remove the feature provided by it, but it should not be advertized as a feature
  • No mandatory plugins (e.g. KML parsing). Mandatory "plugins" must be part of a library
  • Decide on criteria what to realize as plugins and what as modules (libraries). E.g. only do plugins where a common API is easily identified and at least three plugins of that type are provided by Marble itself

This page was last edited on 21 October 2016, at 08:06. Content is available under Creative Commons License SA 4.0 unless otherwise noted.