Marble/Marble 2.0: Difference between revisions
< Marble
Earthwings (talk | contribs) No edit summary |
m Ochurlaud moved page Marble 2.0 to Marble/Marble 2.0 |
||
| (8 intermediate revisions by 2 users not shown) | |||
| Line 3: | Line 3: | ||
== Marble Library Split == | == Marble Library Split == | ||
Split libmarblewidget into several libraries: | Split libmarblewidget into several libraries: | ||
* libMarbleCore | * libMarbleCore (or libMarbleMap?) | ||
** Non-interactive classes, e.g. geodata, file parsing | ** Non-interactive classes, e.g. geodata, file parsing | ||
** Interactive, UI toolkit independent classes, e.g. layers, graphicsview | ** Interactive, UI toolkit independent classes, e.g. layers, graphicsview | ||
** No dependency to QWidgets or Qt Quick | ** No dependency to QWidgets or Qt Quick | ||
* libMarbleWidgets | * libMarbleWidgets | ||
** QWidget related interactive classes | ** QWidget related interactive classes | ||
** Dependency to QWidget | ** Dependency to QWidget, libMarbleCore | ||
* libMarbleQuick | * libMarbleQuick | ||
** Qt Quick 2.0 related interactive classes | ** Qt Quick 2.0 related interactive classes | ||
** Dependency to QtQuick, | ** Dependency to QtQuick, libMarbleCore | ||
* Further possible ones (see also plugins below): MarbleRouting, MarbleTours, MarbleMapEditor | |||
== Header | == 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. | * 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 | * Headers follow the directory structure marble/$module/$path, where $path is either a filename or a directory + filename, but not deeper nested | ||
== Qt | == 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/. | |||
* <s>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)</s> 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 at least Qt 5.0 to avoid a maintenance nightmare | ||
* Require KDE Frameworks 5 (optional, but kdelibs 4.x not supported) | * <s>Require KDE Frameworks 5 (optional, but kdelibs 4.x not supported)</s> Implemented since Applications/15.08 | ||
* Require Qt Quick 2.0 (optional, but Qt Quick 1.1 not supported) | * Require Qt Quick 2.0 (optional, but Qt Quick 1.1 not supported) | ||
* <s>Provide a long term support stable branch with Qt 4.x / KDE 4.x / Qt Quick 1.1 support</s> 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 | |||
Latest revision as of 08:06, 21 October 2016
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 supportPlease 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