Editing ModRana Roadmap

Warning: You are not logged in. Your IP address will be recorded in this page's edit history.

The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.

Learn more about Contributing to the wiki.

= Qt GUI =
A Qt base is currently the main item on the modRana roadmap, due to multiple reasons:
* it enables modRana to run properly on Harmattan
* it enables the use of kinetic scrolling, smooth animations and generally improves performance
* generally better suitable for touchscreen interfaces with Qt Quick (QML)
** unlike Clutter, that needs OpenGL, QML also supports software rendering
** development experience with Mieru generally shows it's much faster to work with than doing custom UI with Cairo
* removes the dependency on GTK
** it is currently not possible to submit applications with outside dependencies both to the Ovi store and to Apps for MeeGo (AFM seems to be working on dependency support though)

== What about the current Cairo + GTK based GUI ? ==
the new Qt based GUI should be just another alternative together with the GTK one. Also in the process more a clear core-GUI separation should be developed to enable other alternative GUIs (EFL,SDL/PyGame,Clutter/MX,etc.).

=== Uses for the current GTK GUI ===
* devices and environment with old versions of Qt
** Neo FreeRunner
** Open Pandora (not sure ?)
** Android chroot (not sure ?)

'''NOTE''': Qt/QML unlike Clutter has a software renderer so OpenGL is not needed to use it. Might be interesting to see the QML vs GTK software rendering performance.

=== Main drawbacks ===
* only basic acceleration provided by X
* no 3D acceleration, smooth scrolling, rotation animation acceleration
* as the classic GTK widgets are basically unusable on mobile devices, modRana has to basically build its own GUI toolkit with Cairo
** while flexible, this is '''very''' labor intensive
** most of new features and improvements are not blocked by extensive GUI improvements needed to make them usable, the backend work is quite easy in comparison
** examples:
*** on-map context menu - needs a new context menu widget
*** long list handling with search - kinetic scrolling (is it doable with Cairo) + interactive search box [built in in Qt Components]
*** clickable in text links [easy with QML]
*** multiline text editing for POI descriptions, etc. [very easy with QML]

=== Planed enhancements ===
* an option for forcing screen redraw interval (might improve Android chroot performance)
* more efficient centering
** just redraw the position cursor and only redraw the map once it nears the screen edge
** this should improve performance while moving at high speed on slow devices and in Android chroot

== What needs to be done to get the Qt GUI in a usable state ==
=== Separating the GUI logic to a GUI module - DONE ===
Most of the core GUI logic currently resides in the modRana "kernel" the ''modrana.py'' file. This logic needs to be transfered to a separate GUI module tat can be loaded by modRana at startup, either by providing a CLI parameter or automatically (once implemented).

There will be a platform independent API, implemented through and abstract parent class, that enables to interact with the current GUI module in platform independent way (toggle fullscreen, set window size, etc.).

This work will be partially based on Mieru, which already uses the concept of separate GUI modules & has advanced CLI argument support.

'''What needs to be done ?'''
* add pluggable GUI module support '''DONE'''
* move the current GTK logic to a GTK GUI module '''DONE'''
** make sure the modularized GTK GUI works with all the changes '''DONE'''
* add proper CLI argument handling '''DONE'''
** -d, --device - set device module '''DONE'''
** -u, --ui - set which GUI to use '''DONE'''
* optional
** --lat, --lon, --zoom, --layer - set a given map screen parameters at startup
** --no_gps - don't start GPS on startup
** --no_sound - disable sound on startup
** --options_path - path to an alternate options.bin file (might be useful for debugging)
** something else ?

=== Writing a Qt GUI module - DONE ===
The Qt GUI module needs to start the interface on startup - create the application window, fullscreen it and start displaying the modRana interface.

'''What needs to be done ?'''
* Qt GUI module
** create application window and fullscreen it '''DONE'''
** fullscreen toggle '''DONE'''
** automatic rotation '''DONE'''
** shutdown support '''DONE'''
* TODO
** rotation lock
** set window title (if applicable)

=== Connecting the tile handling subsystem with QML - 50% DONE ===
ModRana currently uses tile based maps, individual map tiles need to be downloaded & stored so that they are downloaded only once.
* using the modRana tile handling subsystem in QML '''DONE'''
** modifying PinchMap to load tiles from local resources '''DONE'''
** implementing a localhost tileserver (yeah, really - it runs on port 9009 :D) '''DONE'''
** implementing a tile ImageProvider as a fallback for the unlikely possibility that the server won't start '''DONE'''
* create a batch-tile-download UI in QML

=== Getting data from modules to the Qt GUI ===
There are various methods for crossing the GML-native code(Python in this case) divide.  Data access is available from bot sides - QML can access (specially crafted) Python properties and Python can fetch QML objects by name from the current QDeclarativeView.

Which way is better ? IMHO using Python properties and accessing them from QML code is cleaner and makes the QML/Python divide easily visible, PySide also makes it possible to implement callbacks and value change notifications - Python code can notify QML that value of a property changed so that QML code depending on its value can handle the change.

Directly calling QML objects from Python is on the other hand not visible from the QML code (unless manually documented). For isolated cases that (eq calling the shutdown method of the QML root object) it is IMO OK, overusage might cause the QML code to be too tightly connected with Python making it more suspect to breaking by changes in Python or QML.

==== Global data provider vs per-module-property ====
ModRana consists from a number of more or less independent modules that communicate either by exchanging messages, directly calling methods of other modules or by proxy through the main modRana class. Each module has some task it is responsible for - mod_maptiles handles map tiles and mod_location handles location data.

There are basically two ways of providing the data from modules to the QML GUI - per module code exporting Python properties to the QML GUI or a central module (mod_QML_data) that grabs data from various modules and exports them through properties to QML.

For practical reasons, the second method seems to be the better one, at least at the moment:
* as there would be just one QML GUI data handling module and other modules just providing GUI independent data, this aids GUI/backend separation
* the data handling module can grab data from multiple modules and present them as a single property and even handle if a module is not loaded (might come handy once on demand module loading & unloading is implemented)
* one place to look at for QML-Python data forwarding

==== Simple data API ====
Another possibility for providing data to the QML gui is a simple interface, provided by the QML data module that accepts two arguments - module name and a key and returns a data value. The data module just passes the query to the given module and returns the result (it might also do some caching ?).

This might be implemented as an extension to the options api, something like:
<nowiki>
options.mGet(location, sateliteCount, 0)
</nowiki>
Would return the current satellite count or 0 if the location module did not return any data (it might not know the information or does not handle the sateliteCount key).

The options module just checks if a module with the given name exists, if it doesn't exist it returns the default value right away. If it exists it calls its getData method an provides the given key "sateliteCount" to the module. The module responds with a 2 item tupple. The first item represents if the module actually provides any data under this key - True=provides data, False=providing data for this key is not enabled. The second item is the result.

'''What needs to be done ?'''
* create a new ''mod_QMLData'' module
* provide the most important data & methods as Python properties to the QML code
** location info (lat,lon,speed, direction, elevation, etc.)
** layer ,zoomlevel
** tile handling
** POI handling
** routing
** text to speech
** notifications
** tracklogs

<del>* implement the ''simple data API''</del>
<del>** add the mGet method to the options module and export it to modules</del>
<del>** add the getData method to the base_module API</del>
* super-seeded by directly calling Python module methods
** currently only for methods that don't take any arguments and return a single string, boolean, integer or float
** exported through the[https://github.com/M4rtinK/modrana/blob/67f43044ded31472d04613fe5a402832c7f71b99/modules/gui_modules/gui_qml/gui_qml.py#L308 ''modules''] property to QML
** QML code just uses the respective call (''getS'', ''getB'', ''getI'', ''getF'') with two strings as arguments:
*** module name
*** function name
** example (get main forum URL from mod_info):
 modules.getS('info', 'getForumUrl')

=== Writing the various GUI views ===
The modRana GUI consists of a set of different views and the user navigates from one view to another depending on what data he (or she) needs at the moment.

The most important view is the '''map view''' which shows the map, this is normally the view shown at startup. Other important views: menu, options, POI, search, tracklogs.

==== Map view ====
Map view shows the map layer, map overlay layer and the screen overlay layer.

Fortunately, the [http://www.danielfett.de/privat,blog,agtl-n9-meego-alpha-2 recent AGTL release for Harmattan] has a nice QML map component that appears usable. In the future QGraphicsView based map widget is preferable, do to probable performance improvements and easier pseudo-3D handling.

Also a "navigation mode" with an opaque side/bottom bar might be needed while turn-by-turn navigation is in progress.

'''Tasks:'''
* port the AGTL QML map component to modRana
** make it work with QML 1.0 in non-CSSU Fremantle (no pinch area, etc.)
* get tiles from mod_tiles
* progressive tile loading display (like in AGTL)
* better zoom feedback
* map overlay support
* map rotation

==== Menu view ====
The current icon grid works quite nicely in both portrait and landscape and scales quite nicely to different (mobile) screen sizes. The big icons also help to easily navigate the icon grids. Generally all buttons should be fairly large so that it can be easily used while traveling/driving or in averse lighting conditions.

'''Tasks:'''
* icon grid menu
** should probably support kinetic scrolling with a small brightly colored "more" arrow near the border once there are more items displayed than visible
** where to place the "escape" button ?
* listable menu
** a bar at bottom with the escape button and various context button/menu triggers
*** item count, search, delete, etc.
** type-to-search on devices with keyboard
** on devices without keyboard the user needs to first press to search icon to trigger the VKB
** kinetic scrolling

==== Options view ====
It might not be a bad idea to reimplement the Options menu structure using Qt Components. The main benefit would be in presenting more options at the screen and more usable components (switches, sliders, entry boxes, selection dialogs, etc.). On the other hand - how to handle this in QML-only environments ? This might not be an issue as Qt Components are now also available on Fremantle.

'''Tasks:'''
* recreate the options menu structure using Qt Components

* optional: QML only fallback ?

==== POI view ====
The POI view serves for display & management of the stored POI information. The view basically just needs to use the API of the current store_POI module.

POI currently have a name,description,latitude&longitude and a category. It might be sensible to add more items to the POI database (also Mappero appears to be defunct and there are no other users of the POI database format):
* URL's, emails and phone numbers
* address string
* an icon
* tags (user generated ?)
* added timestamp

'''Tasks:'''
* list stored POI
* add/edit/delete a POI
* search POI (combine with the search menu ?)
* batch import (from OSM extracts and elsewhere)
* sharing

==== Search view ====
The search view provides search on online and offline resources. It might be good to provide a unified online & offline search interface that labels each result depending on source (online-nominatim, offline-POI database, offline OSM POI catalog, etc.). It should be also still possible to just search one online/offline category only.

Mostly the view just needs to use the already implemented module APIs. Some advanced features described in the previous paragraph might also need some backend work.

Also, routing might probably be rolled into search as it is just searching for a route from one place to another.

'''Tasks:'''
* online POI search
* online Address and Wikipedia search
* local POI database search
* unified search
* offline POI catalog search
** larger catalogs might need some indexing before use
* online and offline route search

==== Tracklogs view ====
The tracklgos view provides the track logging view and also a view for management of locally stored tracklogs.

'''Tasks:'''
* track logging view
* track management view
** edit/delete tracklogs
** show tracklog information and statistics
** also show route profile, where available

==== Module provided views ====
It might be a good idea to provide a way for modules to provided their own view in some standardized way. Eq. a new (possibly user provided/third party) module might just add its own view and register it in the main menu structure.

== Other GUI modules ==
There are other graphics toolkits with Python bindings than just Qt and GTK. While not all might be viable for mobile use or even not available on mobile Linux devices, a few can be still considered.

=== PyGame ===
The most interesting at the moment is PyGame, which basically provides Python bindings for SDL. I don't have any personal experience with SDL so far but I'd guess it might be a little more lowlevel than GTK or Qt. On the plus side PyGamse is [http://thp.io/2011/webos/ available for WebOS], being the only graphics toolkit with Python bindings on this platform so far. There is also a [https://market.android.com/details?id=org.renpy.pygame PyGame port for Android].

=== EFL ===
[http://www.enlightenment.org/p.php?p=about/efl EFL] seems to have [http://trac.enlightenment.org/e/wiki/Python some Python bindings] and looks to be the only non-HTML5 toolkit available on Tizen out of the box (provided that a device running Tizen is ever released). SHR also uses EFL.

= Non-GUI work =
This section should contain a roadmap for work not directly depending on the GUI.

The modRana project Trac has [http://modrana.org/trac/report/1 quite a large list] a feature requests and bugs already.

== Packaging ==
* create an automated packaging script '''DONE'''
** get source from Github '''DONE'''
** build on OBS '''DONE'''
** build packages locally without OBS

=== Fremantle @ N900 - DONE===
* create an installable package '''DONE'''
** package installs additional icon for the QML version '''DONE'''

* upload the package to Extras-devel once it's stabile enough '''DONE''' - since May 2012

=== Harmattan @ N9,N950 ===
Having a proper package is very important on Harmattan due to Aegis restrictions. If an application needs to use location and other ''priviledged'' services, it needs to be properly packaged with an aegis manifest.

* create an installable package with a working Aegis manifest '''DONE'''
* add portrait and landscape splash-screens

== Configuration file upgrade - DONE ==
ModRana installs configuration files to ~/.modrana, so that they are writable & can be easily edited by the user (the configuration files are extensively commented for this reason). But when something changes in the default configuration file (say - a map layer URL) modRana needs to replace the installed configuration file and backup the existing one (so that any user-provided modifications are not lost).

'''Tasks:'''
* only run upgrade check if modRana version changes '''DONE'''
* add "revision" field to the configuration files '''DONE'''
** stores current configuration file revision as an integer
** the lowest valid value is 1
* if an installed configuration file has a lower revision number than the default one, upgrade it '''DONE'''
** rename it
** copy default configuration file in its place

== Idle loop & timers - 50% DONE ==
MoDrana uses the idle loop to execute some workloads that are not time critical and uses timers to schedule actions that need to happen in the future. ModRana uses the cron module (it dosn't use the cron demon in any way) to provide an abstract API for this. The cron module currently uses GTK for the idle loop and timers.

=== Connecting to the Qt Idle loop ===
When the Qt GUI is used, the cron module needs to use Qt for the idle loop.

'''Tasks:'''
* use the Qt idle loop

=== Using Qt timers - DONE ===
When the Qt GUI is used, the cron module needs to use Qt for timers.

'''Tasks:'''
* use Qt timers '''DONE'''

== Improved hardware & platform support ==
While most parts of modRana are device independent and improvements translate to usage on most devices, modRana also needs to support hardware and features that are only available on a limited range of devices.

=== Harmattan @ Nokia N9/N950 ===
* zooming with volume keys

=== Maemo 5 Fremantle @ Nokia N900 ===
* app menu improvements
** map layer selection
** zoom slider
** more shortcuts

=== Nemo @ N900 ===
* check how modRana runs on [http://wiki.merproject.org/wiki/Nemo Nemo]
* since September 2012, PySide packages needed for the modRana QML GUI are available from the main Nemo repo
** there are also unofficial and untested PyGTK packages for Nemo in [https://build.pub.meego.com/project/show?project=home%3AMartinK%3Anemo this OBS repository]
* packaging

=== SHR @ OpenMoko Neo FreeRunner ===
* navigation board support
* OpenEmbeaded recipe

=== Android ===
* get modRana running on Android
** [http://thp.io/2011/pyside-android/ Qt + PySide] & [http://redmine.semperpax.com/projects/qt-components-android QtComponents ] should be available
* packaging

=== WebOs ===
* compile [http://www.webos-internals.org/wiki/HowtoQt Qt] & [http://thp.io/2011/webos/ Python]
* port PySide
* port QtComponents
* get modRana running
* packaging

[[Category:ModRana]]
[[Category:Development]]

Please note that all contributions to maemo.org wiki may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see maemo.org wiki:Copyrights for details). Do not submit copyrighted work without permission!

Summary:

Cancel | Editing help (opens in new window)

Retrieved from "https://wiki.maemo.org/ModRana_Roadmap"

Personal tools

Navigation

Views

Editing ModRana Roadmap

@@ Line 110: / Line 110: @@
 Would return the current satellite count or 0 if the location module did not return any data (it might not know the information or does not handle the sateliteCount key).
-The options module just checks if a module with the given name exists, if it doesn't exist it returns the default value right away. If it exists it calls its getData method an provides the given key "sateliteCount" to the module. The module responds with a 2 item tupple. The first item represents if the module actually provides any data under this key - True=provides data, False=providing data for this key is not implemented. The second item is the result.
+The options module just checks if a module with the given name exists, if it doesn't exist it returns the default value right away. If it exists it calls its getData method an provides the given key "sateliteCount" to the module. The module responds with a 2 item tupple. The first item represents if the module actually provides any data under this key - True=provides data, False=providing data for this key is not enabled. The second item is the result.
 '''What needs to be done ?'''