Plasma/libplasma2
Summary
This page is dedicated to planning of the libplasma2.
libplasma2 will be binary and source incompatible with the current libplasma. This means that we can fix some issues that are currently present in plasma's design.
Enter the issues you wish fixed in the following form:
Idea: | Change libplasma2 |
---|---|
Summary: | We have a chance to change stuff now |
Proposed solution: | We change things |
Discussion: | http://mail.kde.org/pipermail/plasma-devel/2010-October |
Design Issues
Idea: | Refactor Package* Classes |
---|---|
Summary: | PackageMetaData is a relatively thin and inefficient wrapper around KDesktopFile. It's used rarely and doesn't serve a clear purpose. PackageStructure is a relatively static class that combines both a method for getting new packages as well as a description of the underlying package. |
Proposed solution: | Look at the use cases for Package and PackageStructure, and consider a refactor to clean up the API and make it easier to use. |
Discussion: |
API Issues
Idea: | Applet::appletDestroyed signal poorly named |
---|---|
Summary: | appletDestroyed is emitted in ~Applet, but this can happen even if it isn't "destroyed" but just deleted. Despite its name, appletDestroyed has nothing to do with Applet::destroy() and Applet::destroyed() |
Proposed solution: | Rename to appletDeleted. |
Idea: | Svg::setImagePath is not virtual |
---|---|
Summary: | FrameSvg (and potentially other subclasses of Svg) need to take action when the image path is changed. setImagePath is not virtual nor does it call any internal virtuals. This has resulted in a necessary but unfortunate hack in Svg::setImagePath specifically for FrameSvg. |
Proposed solution: | Make Svg::setImagePath virtual. |
Idea: | Merge Theme::findInCache methods |
---|---|
Summary: | There are multiple findInCache methods in Theme, which could be merged into one method with suitable default parameters. |
Proposed solution: | Merge methods. |
Idea: | Merge ExtenderItem::setGroup methods |
---|---|
Summary: | There are multiple setGroup methods in ExtenderItem, which could be merged into one method with suitable default parameters. |
Proposed solution: | Merge methods. |
Idea: | Dialog::graphicsWidget() is not const |
---|---|
Summary: | As a simple getter, graphicsWidget() should be const. |
Proposed solution: | Make Dialog::graphicsWidget() const. |
Idea: | Wallpaper has a protected data member |
---|---|
Summary: | QList<QAction*> contextActions is not in the dptr. |
Proposed solution: | Move QList<QAction*> contextActions; to WallpaperPrivate |
Idea: | Use virtuals instead of slots in AbstractToolBox |
---|---|
Summary: | There are three slots in AbstractToolBox that really ought to be virtuals: restore, save and reposition. They are currently QMetaObject::invoke()'d instead. |
Proposed solution: | Make them virtual. |
Idea: | isBusy Q_PROPERTY duplicate in Applet |
---|---|
Summary: | There are two "busy" Q_PROPERTY entries defined in Applet: isBusy and busy. The latter is the correct frm. |
Proposed solution: | Remove the isBusy Q_PROPERTY, leaving just busy. |
Idea: | Applet::geometryChanged() superfluous now |
---|---|
Summary: | QGraphicsWidget has a geometryChanged() signal now, it is only kept in Applet to preserve binary compatibility. |
Proposed solution: | Remove Applet::geometryChanged(). |
Idea: | Applet::messageButtonPressed() should pass the fully qualified type |
---|---|
Summary: | Applet has a signal void messageButtonPressed(const MessageButton button). Since moc does a string comparison in connect, trying to connect it to a slot that takes "Plasma::MessageButton" will not work because "MessageButton" != "Plasma::MessageButton" |
Proposed solution: | Change it to messageButtonPressed(const Plasma::MessageButton button); |
Idea: | QMimeData * AbstractRunner::mimeDataForMatch(...) |
---|---|
Summary: | mimeDataForMatch is a slot due to BC. |
Proposed solution: | Change it to a virtual method |
Idea: | Add a function to Plasma::Wallpaper as virtual setWallpaperPath(const KUrl &url) |
---|---|
Summary: | Right now it should be slot due to BC. |
Proposed solution: | Implement it as virtual in Plasma::Wallpaper so that we can set a path in the Wallpaper Plugin. |
Changes in Qt
With the introduction on the QML language in Qt 4.7 there is a new "official" way to create user interfaces in scene/view based environments. A replacement for QGraphicsView is in development under the name of Scene-graph. It will have an opengl accelerated scene accessible only trough QML (because deciding what to paint and when is actually a bottleneck). If the timing of releases will collimate, libplasma2 should migrate from QGraphicsView to Scene-graph, this presents a number of challenge/opportunities:
Idea: | Migrate widgets to QtComponents, drop current libplasma widgets |
---|---|
Summary: | QML allows faster UI creation compared to old widgets, Scene-graph doesn't support QGraphicsWidget |
Proposed solution: | Gradual change: along with the development of QtCompoents, a Plasma-themed component set should be done, will hopefully go into use before libplasma2, so plasmoids can migrate to them before libplasma2, easing the port. The whole QGraphicsWidget (and QGraphicsProxyWidget) based set currently in libplasma should be dropped (since won't work in Scene-graph) so the replacement has to be as complete as possible.
It should also significantly decrease the size of the library. |
Idea: | Corona from a cene becomes a scene bookeeper |
---|---|
Summary: | In Scene-graph there is an 1:1 association scene:view |
Proposed solution: | Corona becomes a manager of scene and views: every time there is something to show the needed items are either created or moved from a former scene and inserted in a new one, with a new view. Changing containments will mean changing scene as well. |
Idea: | Applet no more a GraphicsItem? |
---|---|
Summary: | Right now Applet is a QGraphicsWidget that can optionally include a QML root element (with its declarative engine), mixing QGraphicsWidgets and QDeclarativeItems, nd maybe creatng unneded items. |
Proposed solution: | Applet could become a simple QObject accessible from the root object in QML's javascript, will still have most of its api and would still send to the qml object things such as formfactor and location constaint events. |