|
|
| (4 intermediate revisions by one other user not shown) |
| Line 1: |
Line 1: |
| Refactoring goals towards a Marble 2.0 version.
| | {{ Moved To Community }} |
| | |
| == Marble Library Split ==
| |
| Split libmarblewidget into several libraries:
| |
| * libMarbleCore
| |
| ** Non-interactive classes, e.g. geodata, file parsing
| |
| ** No dependency to QWidgets or Qt Quick
| |
| * libMarbleMap
| |
| ** Interactive, UI toolkit independent classes, e.g. layers, graphicsview
| |
| ** Dependency to MarbleCore
| |
| ** No dependency to QWidgets or Qt Quick
| |
| * libMarbleWidgets
| |
| ** QWidget related interactive classes
| |
| ** Dependency to QWidget, libMarbleMap, libMarbleCore
| |
| * libMarbleQuick
| |
| ** Qt Quick 2.0 related interactive classes
| |
| ** Dependency to QtQuick, libMarbleMap, libMarbleCore
| |
| * Further possible ones (see also plugins below): MarbleRouting, MarbleTours, MarbleMapEditor
| |
| | |
| == Header Normalization ==
| |
| * 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/.
| |
| * 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
| |
| | |
| == 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)
| |
| * 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
| |
| | |
| == 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
| |
