Plasma/Tokamak6: Difference between revisions
| Line 32: | Line 32: | ||
===The Great RunnerManager Refactor Proposal=== | ===The Great RunnerManager Refactor Proposal=== | ||
In which direction are we going to develop KRunner's overall architecture? Threading change, match updates / lifetime management, scheduling of init, teardown and match, AbstractRunner API might benefit from updates. (aseigo) | In which direction are we going to develop KRunner's overall architecture? Threading change, match updates / lifetime management, scheduling of init, teardown and match, AbstractRunner API might benefit from updates. (aseigo) | ||
===One Shell To Rule Them All=== | |||
With plasma-shell, we are leaving behind the era of different binaries for different form factors and instead relying on runtime QML. Completing this experience with KWin, KRunner, etc. and defining how one switches between form factors needs to be laid down in detail. (aseigo) | |||
==Various Other Topics== | ==Various Other Topics== | ||
* Security model: What are the following steps for policy-based imports? Pretty complex topic, needs good coordination with and possibly upstream implementation in Qt. | * Security model: What are the following steps for policy-based imports? Pretty complex topic, needs good coordination with and possibly upstream implementation in Qt. | ||
* Repo structure: How are we going to split in Frameworks5. We might want to reconsider our split of add-ons into kde-workspace, kdeplasma-addons, plasma-mobile. | * Repo structure: How are we going to split in Frameworks5. We might want to reconsider our split of add-ons into kde-workspace, kdeplasma-addons, plasma-mobile. | ||
Revision as of 15:47, 9 April 2013
Tokamak 6 takes place in Nuremberg, Germany from 16th to 22nd April, 2013 at the SUSE offices.
Presentations
- tbd.
Topics
The following
Frameworks 5: Plugin implementation / EXPORT macros
We need to figure out how to implement C++ plugins and export them. This is needed for dataengines, runners and a bunch of other things. It manifests itself in
Frameworks 5: Plasma Quick 2 API
After having gone through the C++ libplasma2 API, we should also do a review of our QML imports. API changes are documented here. (sebas) There's a number of open questions regarding the Plasma Quick 2 API:
- i18n(): Can we expose a global function for this, or do we need to go plasmoid.i18n(), for example?
- Can we do better than: PlasmaCore.Plasma.TopEdge? In QtQuick2, it seems we can't expose enums in our QtQuick import classes
- Why do the QAction bindings still suck? (QMenu handling needs proxy class, makes categorization unnecessarily hard)
Frameworks 5: Plasma-KWin IPC
There are a number of open questions such as:
- dialogs and tooltips: positioning, sizing and transitions between
- sharing textures, for example window "thumbnails", models, etc.
- "mixed effects", such as blurring behind animated items in a translucent Plasma dialog,
- libtaskmanager / window models
Screen edge handling
Can we find a better solution for screen edge handling? How are we going to handle this in a Wayland world, where the compositor is the only thing which *can* know enough details for handling screen edge detection (for example for showing Plasma panels) correctly. (aseigo, mgraesslin)
Dependencies on KWin, Wayland-vs-X11
Should we require KWin as compositor for Plasma2, possibly dropping support for other window managers? (aseigo, mgraesslin)
The Great RunnerManager Refactor Proposal
In which direction are we going to develop KRunner's overall architecture? Threading change, match updates / lifetime management, scheduling of init, teardown and match, AbstractRunner API might benefit from updates. (aseigo)
One Shell To Rule Them All
With plasma-shell, we are leaving behind the era of different binaries for different form factors and instead relying on runtime QML. Completing this experience with KWin, KRunner, etc. and defining how one switches between form factors needs to be laid down in detail. (aseigo)
Various Other Topics
- Security model: What are the following steps for policy-based imports? Pretty complex topic, needs good coordination with and possibly upstream implementation in Qt.
- Repo structure: How are we going to split in Frameworks5. We might want to reconsider our split of add-ons into kde-workspace, kdeplasma-addons, plasma-mobile.