Plasma/Active/Development/PA4PlanningMinutes

Meeting Minutes for Plasma Active 4 Planning Meeting

Date: Wednesday 24 October 2012, 19:00 CEST

Place: irc.freenode.net #active

Agenda

• Schedule for PA4
• Scope of PA4

Schedule

Always releasable master:

For plasma-mobile, we'll have

• One master branch (always in a releasable state)
• One integration branch
• Development happening in feature branches

Feature branches are merged into integration when they are deemed "ready for testing". An integrator merges features into master from integration after they have been successfully tested in the integration branch. Aaron Seigo volunteers to take the position of integrator.

For kde-runtime and kde-workspace we cannot influence the policy, but it is assumed that this will not be too much of a problem since workspace is currently developed in a similar way anyway.

Freeze:

• There will be a freeze at least one month before each scheduled release shortly before a beta/RC is branched out by the integrator.
• A testing image will be created from the branch
• Fixes go into the beta branch and are merged back to master when the are confirmed to work and cause no regressions

Release timing:

• Generally release every 6 months, 2 months after each KDE SC release
  • The switch to Frameworks 5 may need an exception from that rule
• February 25 2013: Beta tagging of PA4
• March 25th 2013: Release
• March 26th: Release announcement

Focus Sprints

• Development happens in sprints of 2-3 weeks each focussing on a specific component
• During the first days, areas of improvement are identified and solutions are designed
• For the rest of the sprint, solutions are implemented

Scope

• PA4 won't contain any new apps developed by the core team due to lack of manpower. We hope for other projects / developers to create new Active apps

Focus areas for PA4:

• Add-Ons
• Alarms
• Books + eReader
• Browser
• Files
• Keyboard
• News / MicroBlog
• Share Like Connect

Maliit

i18n

• Currently QML plugins are quite limited in maliit since the QML API is "very poor" which is why the keyboard layout has to be hard-coded in a QML file. However this will be improved with Maliit 1.0.
• Idea for the meantime: Automatically generate QML files for each layout from XML layout data and load a specific QML for each layout

Content-specific layouts (e.g. number, email address, URL, terminal, ...)

• Maliit-framework as well as Qt already allow it, but plugins have to implement it.
• In Qt4, input methods are not well implemented for QML/qt-components, that will improve with Qt5
• Input into a console/terminal could be treated as a specific content type which would bring up a console-optimized keyboard layout
  • rcg is currently working making the keyboard more konsole-friendly
    • we should coordinate with him

Adapting/scaling keyboard according to screen size/resolution

• One idea is to "query a style component that you feed with some key values, and it spits out the pixel values"
• Aseigo also has ideas for scaling

Blocked input

Maliit is currently shown in a partly transparent full-screen window which blocks any interaction with other window content until it's closed again

• Tough problem, will postpone for now

Bugs

There are still some minor problems/bugs that have to be reported and fixed

Keys to add

Tab as well as arrow keys would be useful in many circumstances (especially in a console, but not only)

Key sizes

Some key sizes should be improved (e.g. larger space key)

Maliit 1.0

• Maliit 1.0 will be based on Qt 5, work with Wayland out of the box and is scheduled for Q2/2013
• We focus on it for PA5

Suggestion for priority for PA4

• Fixing remaining bugs
• Implementing multiple layouts
• Implementing reaction to input method hints (Qt::InputMethodHint values)

Synchronization

Data to be synchronized

• Emails and other messages
• Contacts
• Calendar
• Bookmarks
• Files

Akonadi

• Akonadi offers caching, central storage and retrieval, but setup is very difficult for the user

ownCloud

• Sebas is working on an ownCloud client based on Mirall "which now mostly works", consisting of "a daemon that controls the syncing with the server, an active settings module and a plasmoid to enable / disable folders" (currently residing on Github)
• The syncing works based on folders, but PA stores everything in the uppermost level
  • Idea: Only switch syncin on/off in general, based on network (policies are currently possible)
• A quota would be useful as well so that not all data are downloaded to a mobile device
• sebas plans to have basic syncing use cases ready for PA4

Installing sync services via Add Ons

• No syncin method activated by default, users can install necessary software and preconfigurations for the service they use (e.g. ownCloud in a home network, ownCloud hosted externally, Dropbox, Google Drive, ...) from Add Ons

Accounts framework

• There is good progress on the meego accounts framework, we hope to use that and only add our UIs on top of it (afiestas works on that)
  • Once afiestas will be back from UDS, accounts are going to be his main project, so it will advance fast
• Idea is to have a "sit together" with all interested parties to implement basic features

Social networks

• Needs accounts framework and Klapetek's social feeds framework

Nepomuk data synchronization

• There are possibilities to synchronize metadata stored in Nepomuk, but it's a difficult task
  • postponed to PA5

Files

• There are some bugs and missing features in Files (e.g. file and tag renaming/deletion) which should be fixed/added in PA4
• The backend needs some refactoring
• Details will be figured out in a focus sprint

Books and Reader

• Books is currently Files with a filter for ebooks and PDFs
• Doesn't work so well for e.g. periodicals, so it would need to be more customized than just preselecting a filter

Screen rotation

• jpwhiting currently works on rotation on WeTab/ExoPC. There are difficulties with both Xorg and orientation sensors / QtMobility, but progress is made
• Applications mostly work okay when rotated (but probably still need to be optimized for portrait mode), the workspace still has some bugs when rotated but basically works okay

Android apps

• Getting Android apps to run in PA is basically possible using a Dalvik layer, but currently we have no resources to work on that
• Most Android apps are optimized for phones, not for tablets
• Android app integration currently has low priority

Browser

• Currently Browser has quite some problems which are caused by the bad integration of QtWebkit1 in QML. This situation will hopefully improve with QtWebkit2 in Qt5

Bonus: After-Meeting-Minutes

• Planned features for Calligra Active can be found at http://community.kde.org/Calligra_Active#Planned_features
• Calligra should be adapted to the Plasma Active HIGs in order to be more consistent with Reader and other apps