Meego Wiki
Views

Maliit/Viva la Revolution

From MeeGo wiki
(Difference between revisions)
Jump to: navigation, search
Line 21: Line 21:
* meegotouch-feedbackreactionmaps → maliit-reactionmaps
* meegotouch-feedbackreactionmaps → maliit-reactionmaps
* meegotouch-inputmethodbridges  → maliit (Will contain the application developer facing API and the support for different toolkits.)
* meegotouch-inputmethodbridges  → maliit (Will contain the application developer facing API and the support for different toolkits.)
 +
* Still need to move over code from other repos, currently only framework and plugins are live, but I will with other repos until main development really happens @ Maliit, simply to avoid sync mess.
|-
|-
| Have consistent package names based on the repository names. The package names will depend on different naming conventions of different platforms.  
| Have consistent package names based on the repository names. The package names will depend on different naming conventions of different platforms.  
Line 29: Line 30:
| Use consistent Maliit paths.
| Use consistent Maliit paths.
||
||
-
|| 0%
+
|| 100%
||
||
* /usr/include/meegoimframework          → /usr/include/maliit/framework
* /usr/include/meegoimframework          → /usr/include/maliit/framework
Line 39: Line 40:
|| Use Maliit based settings keys. (allow to use old ones through configure/runtime option)
|| Use Maliit based settings keys. (allow to use old ones through configure/runtime option)
||
||
-
|| 0%
+
|| 100%
||
||
* /meegotouch/inputmethods/plugins        → /maliit/plugins
* /meegotouch/inputmethods/plugins        → /maliit/plugins

Revision as of 22:23, 20 June 2011

Tasks

These are the remaining tasks to make Maliit an independent upstream project and to remove any trace/dependency to LMT in Maliit framework and its reference keyboard.

Task Assignee Status Details
Get an own repostiory (gitorious.org/maliit) instead of meego.gitorious.org/meegotouch. Maliit repo will be the new upstream project for Harmattan and MeeGo Input Methods. Michael 90%
  • meegotouch-inputmethodframework → maliit-framework
  • meegotouch-inputmethodengine → maliit-engine
  • meegotouch-inputmethodkeyboard → maliit-plugin
  • meegotouch-feedback → maliit-feedback
  • meegotouch-feedbackreactionmaps → maliit-reactionmaps
  • meegotouch-inputmethodbridges → maliit (Will contain the application developer facing API and the support for different toolkits.)
  • Still need to move over code from other repos, currently only framework and plugins are live, but I will with other repos until main development really happens @ Maliit, simply to avoid sync mess.
Have consistent package names based on the repository names. The package names will depend on different naming conventions of different platforms. 0%
Use consistent Maliit paths. 100%
  • /usr/include/meegoimframework → /usr/include/maliit/framework
  • /usr/include/meego/meegoimengine → /usr/include/maliit/engine
  • /usr/lib/meego-im-plugins → /usr/lib/maliit/plugins
  • /usr/lib/meego-imengines/drivers → /usr/lib/maliit/engines
  • /usr/share/meegotouch/virtual-keyboard → /usr/share/maliit/keyboard
Use Maliit based settings keys. (allow to use old ones through configure/runtime option) 100%
  • /meegotouch/inputmethods/plugins → /maliit/plugins
  • /meegotouch/inputmethods/onscreen → /maliit/onscreen
  • /meegotouch/inputmethods/virtualkeyboard → /malitt/keyboard

When switching to DConf we could just use /org/maliit/...

Provide prototype for styling through extended attributes. 0% Keep the idea of generated style container classes, as they provide nice type safety. But at the same time, allow controlling of those attributes through extended attributes API (domain "/style").
Analyse functional dependencies between key styles 0% Fight combinatorial state explosion in key styling, probably by defining functional dependencies ("A pressed key always uses Color#2 when highlighted") and by using a styling state machine for keys.
Personal tools