Latest revision as of 15:43, 20 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?
- new namespace "KDE", register as uncreatable object
- gets instantiated from kdeclarative on first access
- possible, but ugly: inject a bit of js which does: "function i18n(bla) { return kde.i18n(bla); }"
Can we do better than: PlasmaCore.Plasma.TopEdge? In QtQuick2, it seems we can't expose enums in our QtQuick import classes
- register it as PlasmaCore.Plasma.HorizontalFormFactor, Plasma is an uncreatable object (basically what's in plasma.h)

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) Result: While practically, kwin will be the only wayland compositor for some time that actually implements the Shell interface, we will discipline ourselves to adhering to well-defined and documented interfaces, so we can, when that time arrives, standardize these things (for example popup placements) across different compositors.

KWin stuff

Activities and KWin

Formalize how activities related to windows and virtual desktops. Currently there is often confusion and the KWin devs do not know how to properly implement and to recognize bugs. (see Bug 318153)

Plasma-Addons for KWin Addons

Should e.g. all non-default window switchers be moved to Plasma-Addons?

Themes in KWin

Plasma Theme showed problems for usage in KWin. Should we continue to use it or extend the theme to have specific elements for KWin's use cases (above all windows) - might overlap with "A Day At The Beauty Parlor".

Window Decoration for Plasma Active

Should we include a touch friendly decoration for not-maximized windows?

Full-Screen Applications in Plasma Active

A full-screen mode would be useful for many Active Apps, so we need to define a "standard" way for apps to go full-screen. We need to ensure that it's always possible to return to windowed mode without the need for a physical keyboard or right mouse button, and even if the application hangs.

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)

A Day At The Beauty Parlor

Visual identity for PW2 (aseigo) @ http://www.wax-in-the-city.com ?

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.
When to switch kde-workspace to Qt5?
Which apps need to be kicked from kde-workspace (e.g. KDM)
Split of git repo?

@@ Line 10: / Line 10: @@
 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 review===
+===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 [http://community.kde.org/Plasma/libplasma2#QtQuick2_porting 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?
+** new namespace "KDE", register as uncreatable object
+** gets instantiated from kdeclarative on first access
+** possible, but ugly: inject a bit of js which does: "function i18n(bla) { return kde.i18n(bla); }"
+* Can we do better than: PlasmaCore.Plasma.TopEdge? In QtQuick2, it seems we can't expose enums in our QtQuick import classes
+** register it as PlasmaCore.Plasma.HorizontalFormFactor, Plasma is an uncreatable object (basically what's in plasma.h)
+**
+* Why do the QAction bindings still suck? (QMenu handling needs proxy class, makes categorization unnecessarily hard)
 ===Frameworks 5: Plasma-KWin IPC===
@@ Line 19: / Line 30: @@
 * "mixed effects", such as blurring behind animated items in a translucent Plasma dialog,
 * libtaskmanager / window models
-w
 ===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)
@@ Line 25: / Line 36: @@
 ===Dependencies on KWin, Wayland-vs-X11===
 Should we require KWin as compositor for Plasma2, possibly dropping support for other window managers? (aseigo, mgraesslin)
+Result: While practically, kwin will be the only wayland compositor for some time that actually implements the Shell interface, we will discipline ourselves to adhering to well-defined and documented interfaces, so we can, when that time arrives, standardize these things (for example popup placements) across different compositors.
+=== KWin stuff===
+====Activities and KWin====
+Formalize how activities related to windows and virtual desktops. Currently there is often confusion and the KWin devs do not know how to properly implement and to recognize bugs. (see [https://bugs.kde.org/show_bug.cgi?id=318153 Bug 318153])
+====Plasma-Addons for KWin Addons====
+Should e.g. all non-default window switchers be moved to Plasma-Addons?
+====Themes in KWin====
+Plasma Theme showed problems for usage in KWin. Should we continue to use it or extend the theme to have specific elements for KWin's use cases (above all windows) - might overlap with "A Day At The Beauty Parlor".
+====Window Decoration for Plasma Active====
+Should we include a touch friendly decoration for not-maximized windows?
+====Full-Screen Applications in Plasma Active====
+A full-screen mode would be useful for many Active Apps, so we need to define a "standard" way for apps to go full-screen. We need to ensure that it's always possible to return to windowed mode without the need for a physical keyboard or right mouse button, and even if the application hangs.
 ===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)
+===A Day At The Beauty Parlor===
+Visual identity for PW2 (aseigo) @ http://www.wax-in-the-city.com ?
+==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.
+* When to switch kde-workspace to Qt5?
+* Which apps need to be kicked from kde-workspace (e.g. KDM)
+* Split of git repo?