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

Plasmoids

Status	Name	Summary	Developer
TODO	ServiceJob is autostarted	ServiceJob is connected to a zero timer in Service::startOperationCall. If exec() is called on the job and it doesn't finish immediately, then the event loop will be start and the timer will fire causing start() to be called a second time.	<[email protected]>
TODO	Fewer friend classes	Look at all friend relationships and see how many can be removed now due to evolution of libplasma itself or clever new approaches to the old problem. Public API clarity and cleanliness must not be sacrificed, however. Internal ugliness is better than external ugliness.	<[email protected]>
TODO	Make DataEngine implicitly shared	We pass DataEngines around as pointers, which makes them vulnerable to all the usual pointer-related issues: crashes, accidental deletions, etc.	<[email protected]>
TODO	DataEngineConsumer public API	Right now it is a bit too easy to make mistakes with using DataEngines outside of the normal consumers (Applet, Wallpaper, etc.). This is because DataEngineManager exposes the reference counting details as public API.	<[email protected]>
TODO	Refactor Package* Classes	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.	<[email protected]>
TODO	PackageStructure::installPackage should be async	Package::installPackage is current synchronous, which prevents running it in another thread, doing user interaction (e.g. to confirm other dependencies to download) or taking additional actions such as downloads.	<[email protected]>
TODO	Out of process DataEngines	Out of process DataEngines	<[email protected]>
TODO	Improving remote widgets	Remote widgets work if the widget uses DataEngines and Services exclusively, polls the remote DataEngine excessively and only speaks one network backend.	<[email protected]>
TODO	Improving remote widgets	Remote widgets work if the widget uses DataEngines and Services exclusively, polls the remote DataEngine excessively and only speaks one network backend.	<[email protected]>
TODO	More model-like dataengines	Many dataengines return data as series of items: like rss, microblog and tasks, and they do in different ways, rss has a list of Data in a single key, microblog has an item per key, tasks has an item per source.	<[email protected]>
TODO	Lazy dataengine evaluation	The problem with the current DE implementation (QVariants) is that data is kept in memory even if the user didn't request it. (for example, some engine could keep a pixmap ready for a data item, although the applet only wants the title.	<[email protected]>

API Issues

API Issues

Status	Name	Summary	Developer
TODO	Remove unimplemented virtual methods	In various places there are virtual methods which were re-implemented, but then later had the implementation removed, but for binary compatibility reasons the method itself has to remain.	<[email protected]>
TODO	[mM]imetype -> [mM]imeType	Everywhere else in KDE/Qt API it is "MimeType"	<[email protected]>
TODO	Wallpaper drop handling	We now have two ways to note that a URL has been added to a wallpaper via external means: urlDropped(KUrl) and setUrls(KUrl::List).	<[email protected]>
TODO	Applet::appletDestroyed signal poorly named	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()	<[email protected]>
TODO	Svg::setImagePath is not virtual	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.	<[email protected]>
TODO	Merge ExtenderItem::setGroup methods	There are multiple setGroup methods in ExtenderItem, which could be merged into one method with suitable default parameters.	<[email protected]>
TODO	Dialog::graphicsWidget() is not const	As a simple getter, graphicsWidget() should be const.	<[email protected]>
TODO	Wallpaper has a protected data member	QList<QAction*> contextActions is not in the dptr.	<[email protected]>
TODO	Use virtuals instead of slots in AbstractToolBox	There are three slots in AbstractToolBox that really ought to be virtuals: restore, save and reposition. They are currently QMetaObject::invoke()'d instead.	<[email protected]>
TODO	Applet::geometryChanged() superfluous now	QGraphicsWidget has a geometryChanged() signal now, it is only kept in Applet to preserve binary compatibility.	<[email protected]>
TODO	Applet::messageButtonPressed should pass the fully qualified type	[email protected]	[mailto:Jhon Doe <Jhon Doe >]
TODO	AbstractRunner::mimeDataForMatch	mimeDataForMatch is a slot due to BC.	<[email protected]>
TODO	Add const setWallpaperPath	Add a function to Plasma::Wallpaper as virtual setWallpaperPath(const KUrl &url)	<[email protected]>
TODO	un/installPackage should be private	Both methods are static members of the public API, though all install/uninstall calls should be done through PackageStructure	<[email protected]>
TODO	Remove context info classes	The classes are unused, and are not working. All data they provide can be accessible via data engines	<[email protected]>
TODO	Remove contact info classes	The classes are unused, and are not working. All data they provide can be accessible via data engines	<[email protected]>

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:

A prototype of a Corona, Containment, Applet hierarchy in scene-graph can be found here: http://quickgit.kde.org/?p=scratch%2Fmart%2Fplasma2-proto.git&a=summary

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:	Change Corona from a QGraphicsScene to being a (singleton) 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.

Idea:	libplasma not depending on graphics backends
Summary:	The above issue suggests that libplasma could not depend anymore neither from QGraphicsView or SceneGraph.
Proposed solution:	All the rendering specific code will go into QML imports. Libplasma could still retain QPainter specific classes, such as Svg and FrameSvg, paintutils and so on