Plasma/libplasma2: Difference between revisions

From KDE Community Wiki
(update scriptengine tasks)
 
(62 intermediate revisions by 8 users not shown)
Line 3: Line 3:
This page is dedicated to planning of the libplasma2.
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.
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. Any changes that affect the source compatibility must be documented [[Plasma/PortingTolibplasma2|here]]


Enter the issues you wish fixed in the following form:
Enter the issues you wish fixed in the following form:
Line 23: Line 23:
|}
|}


= Design Issues =
= General TODOs =
 
{| class="sortable" border="1" cellpadding="4" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Name !! Summary !! Developer


{|
{{FeatureProjectDone
|-
| Fix plasmoidpackagetest
! Idea:
| plasmoidpackagetest currently does not build due to missing KIO, etc. API. Port away from KIO and friends to Qt equivalents and get it pass again.
! Fewer friend classes
|foo@kde.org|foodev
|-
}}
| Summary:
| There are a lot of friend classes and fondling of privates going on in libplasma. Usually this is done to make the public API smoother, and is a net win for the user of the library.
|-
| Proposed solution:
|
|-
| Discussion:
| The challenge will be in DataEngine subclasses which may have class members that are not copyable, let alone the bloat of the copying or the challenge of keeping that data in each copy in sync with the shared data in DataEnginePrivate. So to do this properly, we may need to break out DataEngine which consumers use from DataEngine that gets subclassed.
|-
|}


{{FeatureProjectTodo
| Signing
| Integrate Signing classes with Package; put Signing class in a thread, potentially make it private API. Current is in staging directory.
}}


{|
|-
! Idea:
! Make DataEngine implicitly shared
|-
| Summary:
| We pass DataEngines around as pointers, which makes them vulnerable to all the usual pointer-related issues: crashes, accidental deletions, etc.
|-
| Proposed solution:
| 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.
|-
| Discussion:
|
|-
|}
|}


= Design Issues =


{|
{| class="sortable" border="1" cellpadding="4" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|-
|- style="background: #ececec; white-space:nowrap;"
! Idea:
! Status !! Name !! Summary !! Developer
! Make DataEngineConsumer public API
|-
| Summary:
| 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.
|-
| Proposed solution:
| Instead of exposing the management details around DataEngine by making DataEngineManager public, make DataEngineConsumer a public class instead. DataEngineManager would become private API and DataEngineConsumer would use it behind the scenes.
|-
| Discussion:
|
|-
|}
 


{|
{{FeatureProjectDone
|-
| [[Plasma/libplasma2/servicejob |ServiceJob is autostarted]]
! Idea:
| 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.
! 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:
|
|-
|}


{{FeatureProjectTodo
| [[Plasma/libplasma2/friendclasses |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. 
}}


{|
{{FeatureProjectDone
|-
| [[Plasma/libplasma2/dataengineconsumerapi |DataEngineConsumer public API]]
! Idea:
| 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.  
! PackageStructure::installPackage should be async
|aseigo@kde.org|aseigo
|-
}}
| Summary:
| 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.
|-
| Proposed solution:
| Make Package::installPackage async and return a KJob* that represents the install process.
|-
| Discussion:
|
|-
|}


{{FeatureProjectDone
| [[Plasma/libplasma2/refactorpackageclasses |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.
}}


{{FeatureProjectDone
| [[Plasma/libplasma2/asyncstructureinstallpackage |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]|Sebastian Kügler
}}


{|
{{FeatureProjectTodo
|-
| [[Plasma/libplasma2/dataengineimplicitlyshared |Make DataEngine implicitly shared]]
! Idea:
| We pass DataEngines around as pointers, which makes them vulnerable to all the usual pointer-related issues: crashes, accidental deletions, etc.
! Out of process DataEngines
|foo@kde.org|Jhon Doe
|-
}}
|valign=top| Summary:
| Even if they try to be s async as possible, right now dataengines could become too heavy and slow down the main GUI event loop.
|-
|valign=top| Proposed solution:  
| Dataengines could run in a different process (and pass the actual data trough sockets) making the UI actually faster. However especially on devices a process more would bring more context switches and overall memory consumption (MeeGo certification policy even forbids applications to run any kind of daemon) So should be probably decided at compile time.
|-
|}


{{FeatureProjectTodo
| [[Plasma/libplasma2/outofprocessdataengines |Out of process DataEngines]]
| Out of process DataEngines
}}


{|
{{FeatureProjectDone
|-
| [[Plasma/libplasma2/modellikedataengines |More model-like dataengines]]
! Idea:
| 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.
! Improving remote widgets
|foo@kde.org|Jhon Doe
|-
}}
|valign=top| Summary:  
| Remote widgets work if the widget uses DataEngines and Services exclusively, polls the remote DataEngine excessively and only speaks one network backend.
|-
|valign=top| Proposed solution:
|
* Provide a remote-transparent data store and/or command/event proxy.
* Get rid of polling with push API
* Properly abstract network layer
* Possibility to sync over network the applet configuration too
* Possibility for a local widget to connect to a remote dataengine
|-
|}


{{FeatureProjectTodo
| [[Plasma/libplasma2/lazydataengineevaluation |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.
}}


{|
|-
! Idea:
! More model-like dataengines
|-
|valign=top| Summary:
| 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.
|-
|valign=top| Proposed solution:
|
* Provide an unified way to do item lists easily mappable to models for QML views
* A DataList type?
* directly passing a model?
|-
|}
|}


= API Issues =
= API Issues =
{| class="sortable" border="1" cellpadding="4" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Name !! Summary !! Developer
{{FeatureProjectDone
| [[Plasma/libplasma2/removeuninplementedvirtuals | 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.
}}


{|
{{FeatureProjectDone
|-
| [[Plasma/libplasma2/camelcaseimeType | [mM]imetype -> [mM]imeType]]
! Idea:
! [mM]imetype -> [mM]imeType
|-
|valign=top| Summary:
| Everywhere else in KDE/Qt API it is "MimeType"
| Everywhere else in KDE/Qt API it is "MimeType"
|-
|sebas@kde.org|Sebastian Kügler
|valign=top| Proposed solution:
}}
| Conform to the capitalization of "Type" in Plasma APIs.
|-
|}
 


{|
{{FeatureProjectDone
|-
| [[Plasma/libplasma2/wallpaperdrophandling | Wallpaper drop handling]]
! Idea:
! Wallpaper drop handling
|-
|valign=top| Summary:
| 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).
| 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).
|-
|foo@kde.org|Jhon Doe
|valign=top| Proposed solution:
}}
| Drop urlDropped in favor of setUrls; make setUrls virtual, drop the protected addUrls slot (was just a work-around for BC) and port Wallpaper plugins away from addUrls. In WallpaperScript, make setUrls virtual and drop urlDropped.
|-
|}


 
{{FeatureProjectDone
{|
| [[Plasma/libplasma2/appletdestroyed | Applet::appletDestroyed signal poorly named]]
|-
! Idea:
! Applet::appletDestroyed signal poorly named
|-
|valign=top| 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()
| 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()
|-
|kok3rs@kde.org|Antonis Tsiapaliokas
|valign=top| Proposed solution:
}}
| Rename to appletDeleted.
|-
|}


 
{{FeatureProjectDone
{|
| [[Plasma/libplasma2/svgsetimagepath | Svg::setImagePath is not virtual]]
|-
! Idea:
! Svg::setImagePath is not virtual
|-
|valign=top| 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.
| 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.
|-
|aseigo@kde.org|Aaron Seigo
|valign=top| Proposed solution:
}}
| Make Svg::setImagePath virtual.
|-
|}


{{FeatureProjectDone
| [[Plasma/libplasma2/mergeextendersetgroupmethods | Merge ExtenderItem::setGroup methods]]
| There are multiple setGroup methods in ExtenderItem, which could be merged into one method with suitable default parameters.
}}


{|
{{FeatureProjectDone
|-
| [[Plasma/libplasma2/findcachemethods | Merge Theme::findInCache methods]]
! Idea:
! Merge Theme::findInCache methods
|-
|valign=top| Summary:
| There are multiple findInCache methods in Theme, which could be merged into one method with suitable default parameters.
| There are multiple findInCache methods in Theme, which could be merged into one method with suitable default parameters.
|-
|foo@kde.org|Jhon Doe
|valign=top| Proposed solution:
}}
| Merge methods.
|-
|}
 


{|
{{FeatureProjectDone
|-
| [[Plasma/libplasma2/dialognotconstgraphicswidget | Dialog::graphicsWidget() is not const]]
! Idea:
! Merge ExtenderItem::setGroup methods
|-
|valign=top| Summary:
| There are multiple setGroup methods in ExtenderItem, which could be merged into one method with suitable default parameters.
|-
|valign=top| Proposed solution:
| Merge methods.
|-
|}
 
 
{|
|-
! Idea:
! Dialog::graphicsWidget() is not const
|-
|valign=top| Summary:
| As a simple getter, graphicsWidget() should be const.
| As a simple getter, graphicsWidget() should be const.
|-
|foo@kde.org|Jhon Doe
|valign=top| Proposed solution:
}}
| Make Dialog::graphicsWidget() const.
|-
|}
 


{|
{{FeatureProjectDone
|-
| [[Plasma/libplasma2/wallpaperprotecteddatamember |Wallpaper has a protected data member]]
! Idea:
! Wallpaper has a protected data member
|-
|valign=top| Summary:
| QList<QAction*> contextActions is not in the dptr.
| QList<QAction*> contextActions is not in the dptr.
|-
|[email protected]|Aaron Seigo
|valign=top| Proposed&nbsp;solution:
}}
| Move QList<QAction*> contextActions; to WallpaperPrivate
|-
|}


 
{{FeatureProjectDone
{|
| [[Plasma/libplasma2/abstracttoolusevirtuals |Use virtuals instead of slots in AbstractToolBox]]
|-
! Idea:
! Use virtuals instead of slots in AbstractToolBox
|-
|valign=top| Summary:
| There are three slots in AbstractToolBox that really ought to be virtuals: restore, save and reposition. They are currently QMetaObject::invoke()'d instead.
| There are three slots in AbstractToolBox that really ought to be virtuals: restore, save and reposition. They are currently QMetaObject::invoke()'d instead.
|-
|foo@kde.org|Jhon Doe
|valign=top| Proposed&nbsp;solution:
}}
| Make them virtual.
|-
|}


 
{{FeatureProjectDone
{|
| [[Plasma/libplasma2/duplicatedisbusy |isBusy Q_PROPERTY duplicate in Applet]]
|-
! Idea:
! isBusy Q_PROPERTY duplicate in Applet
|-
|valign=top| Summary:
| There are two "busy" Q_PROPERTY entries defined in Applet: isBusy and busy. The latter is the correct frm.
| There are two "busy" Q_PROPERTY entries defined in Applet: isBusy and busy. The latter is the correct frm.
|-
|foo@kde.org|Jhon Doe
|valign=top| Proposed&nbsp;solution:
}}
| Remove the isBusy Q_PROPERTY, leaving just busy.
|-
|}


{{FeatureProjectDone
| [[Plasma/libplasma2/superflousgeometrychanged |Applet::geometryChanged() superfluous now]]
|  QGraphicsWidget has a geometryChanged() signal now, it is only kept in Applet to preserve binary compatibility.
}}


{|
{{FeatureProjectDone
|-
| [[Plasma/libplasma2/fullyqualifiedtype |Applet::messageButtonPressed should pass the fully qualified type]]
! Idea:
| 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"  nq "Plasma::MessageButton"
! Applet::geometryChanged() superfluous now
|aseigo@kde.org|Aaron Seigo
|-
}}
|valign=top| Summary:
| QGraphicsWidget has a geometryChanged() signal now, it is only kept in Applet to preserve binary compatibility.
|-
|valign=top| Proposed&nbsp;solution:  
| Remove Applet::geometryChanged().
|-
|}
 


{|
{{FeatureProjectDone
|-
| [[Plasma/libplasma2/abstractrunnermimedata |AbstractRunner::mimeDataForMatch]]
! Idea:
| mimeDataForMatch is a slot due to BC.
! Applet::messageButtonPressed() should pass the fully qualified type
|-
}}
|valign=top| 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"
|-
|valign=top| Proposed&nbsp;solution:
| Change it to messageButtonPressed(const Plasma::MessageButton button);
|-
|}


{{FeatureProjectDone
| [[Plasma/libplasma2/setwallpaperpath |Add const setWallpaperPath]]
|  Add a function to Plasma::Wallpaper as virtual setWallpaperPath(const KUrl &url) 
|[email protected]|Giorgos Tsiapaliokas
}}


{|
{{FeatureProjectDone
|-
| [[Plasma/libplasma2/privateun-install |un/installPackage should be private]]
! Idea:
| Both methods are static members of the public API, though all install/uninstall calls should be done through PackageStructure
! QMimeData * AbstractRunner::mimeDataForMatch(...)
|sebas@kde.org|Sebastian Kügler
|-
}}
|valign=top| Summary:
| mimeDataForMatch is a slot due to BC.
|-
|valign=top| Proposed&nbsp;solution:
| Change it to a virtual method
|-
|}


{{FeatureProjectDone
| [[Plasma/libplasma2/removecontextinfo |Remove context info classes]]
|  The classes are unused, and are not working. All data they provide can be accessible via data engines
}}


{|
|-
! Idea:
! Add a function to Plasma::Wallpaper as virtual setWallpaperPath(const KUrl &url)
|-
|valign=top| Summary:
| Right now it should be slot due to BC.
|-
|valign=top| Proposed&nbsp;solution:
| Implement it as virtual in Plasma::Wallpaper so that we can set a path in the Wallpaper Plugin.
|-
|}
|}


{|
= QGraphicsView vs QML2 =
|-
! Idea:
! Package::installPackage and Package::uninstallPackage should be private
|-
|valign=top| Summary:
| Both methods are static members of the public API, though all install/uninstall calls should be done through PackageStructure
|-
|valign=top| Proposed&nbsp;solution:
| Move them into a private class for internally use only, perhaps private/packages.*
|-
|}


= Changes in Qt =
{| class="sortable" border="1" cellpadding="4" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
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.
|- style="background: #ececec; white-space:nowrap;"
A replacement for QGraphicsView is in development under the name of Scene-graph.
! Status !! Name !! Summary !! Developer
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:


{|
{{FeatureProjectDone
|-
| [[Plasma/libplasma2/migratetoqtcomponents | Migrate widgets to QtComponents, drop current libplasma widgets]]
! Idea:
! Migrate widgets to QtComponents, drop current libplasma widgets
|-
|valign=top| Summary:
| QML allows faster UI creation compared to old widgets, Scene-graph doesn't support QGraphicsWidget
| QML allows faster UI creation compared to old widgets, Scene-graph doesn't support QGraphicsWidget
|-
|[email protected]|Marco Martin
|valign=top| Proposed&nbsp;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.
{{FeatureProjectDone
|-
| [[Plasma/libplasma2/coronscenebookeeper | Port Corona away from QGV]]
|}
| Change Corona from a QGraphicsScene to being a (singleton) scene bookeeper, In Scene-graph there is an 1:1 association scene:view
|mart@kde.org|Marco Martin
}}


{{FeatureProjectDone
| [[Plasma/libplasma2/appletsansgraphicsitem|Applet no more a GraphicsItem]]
| 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.
|[email protected]|Marco Martin
}}


{|
{{FeatureProjectDone
|-
| A shell that is based on scene graph
! Idea:
| Write a single shell based on scene graph.
! Corona from a cene becomes a (singleton) scene bookeeper
|mart@kde.org|Marco Martin
|-
}}
|valign=top| Summary:
| In Scene-graph there is an 1:1 association scene:view
|-
|valign=top| Proposed&nbsp;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.
|-
|}


{{FeatureProjectDone
| Port QML scriptengine to qml2
| The QML scriptengine should create the QQuickItems corresponding to containments and applets, parsing the qml in their packages
|[email protected]|Marco Martin
}}


{|
{{FeatureProjectDone
|-
| Port QML scriptengine away from QScriptEngine
! Idea:
| QML2 doesn't have QScriptEngine. It must either use only the declarative engine (means everything is qobject) or use directly V8
! Applet no more a GraphicsItem
|mart@kde.org|Marco Martin
|-
}}
|valign=top| 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.
|-
|valign=top| Proposed&nbsp;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.
|-
|}


{|
{{FeatureProjectDone
|-
| [[Plasma/libplasma2/libplasmanographicsbakends|libplasma not depending on graphics backends]]
! Idea:
! libplasma not depending on graphics backends
|-
|valign=top| Summary:
| The above issue suggests that libplasma could not depend anymore neither from QGraphicsView or SceneGraph.
| The above issue suggests that libplasma could not depend anymore neither from QGraphicsView or SceneGraph.
|-
|valign=top| Proposed&nbsp;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
 
|-
|}
|}

Latest revision as of 23:36, 29 January 2014

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. Any changes that affect the source compatibility must be documented here

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

General TODOs

Status Name Summary Developer
DONE Fix plasmoidpackagetest plasmoidpackagetest currently does not build due to missing KIO, etc. API. Port away from KIO and friends to Qt equivalents and get it pass again. <[email protected]>


TODO Signing Integrate Signing classes with Package; put Signing class in a thread, potentially make it private API. Current is in staging directory. <[email protected]>


Design Issues

Status Name Summary Developer
DONE 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]>


DONE 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]>


DONE 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]>


DONE 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 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 Out of process DataEngines Out of process DataEngines <[email protected]>


DONE 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

Status Name Summary Developer
DONE 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]>


DONE [mM]imetype -> [mM]imeType Everywhere else in KDE/Qt API it is "MimeType" <[email protected]>


DONE 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]>


DONE 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]>


DONE 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]>


DONE Merge ExtenderItem::setGroup methods There are multiple setGroup methods in ExtenderItem, which could be merged into one method with suitable default parameters. <[email protected]>


DONE Merge Theme::findInCache methods There are multiple findInCache methods in Theme, which could be merged into one method with suitable default parameters. <[email protected]>


DONE Dialog::graphicsWidget() is not const As a simple getter, graphicsWidget() should be const. <[email protected]>


DONE Wallpaper has a protected data member QList<QAction*> contextActions is not in the dptr. <[email protected]>


DONE 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]>


DONE isBusy Q_PROPERTY duplicate in Applet There are two "busy" Q_PROPERTY entries defined in Applet: isBusy and busy. The latter is the correct frm. <[email protected]>


DONE Applet::geometryChanged() superfluous now QGraphicsWidget has a geometryChanged() signal now, it is only kept in Applet to preserve binary compatibility. <[email protected]>


DONE Applet::messageButtonPressed should pass the fully qualified type 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" nq "Plasma::MessageButton" <[email protected]>


DONE AbstractRunner::mimeDataForMatch mimeDataForMatch is a slot due to BC. <[email protected]>


DONE Add const setWallpaperPath Add a function to Plasma::Wallpaper as virtual setWallpaperPath(const KUrl &url) <[email protected]>


DONE 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]>


DONE Remove context info classes The classes are unused, and are not working. All data they provide can be accessible via data engines <[email protected]>


QGraphicsView vs QML2

Status Name Summary Developer
DONE Migrate widgets to QtComponents, drop current libplasma widgets QML allows faster UI creation compared to old widgets, Scene-graph doesn't support QGraphicsWidget <[email protected]>


DONE Port Corona away from QGV Change Corona from a QGraphicsScene to being a (singleton) scene bookeeper, In Scene-graph there is an 1:1 association scene:view <[email protected]>


DONE Applet no more a GraphicsItem 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. <[email protected]>


DONE A shell that is based on scene graph Write a single shell based on scene graph. <[email protected]>


DONE Port QML scriptengine to qml2 The QML scriptengine should create the QQuickItems corresponding to containments and applets, parsing the qml in their packages <[email protected]>


DONE Port QML scriptengine away from QScriptEngine QML2 doesn't have QScriptEngine. It must either use only the declarative engine (means everything is qobject) or use directly V8 <[email protected]>


DONE libplasma not depending on graphics backends The above issue suggests that libplasma could not depend anymore neither from QGraphicsView or SceneGraph. <[email protected]>


Retrieved from "https://community.kde.org/index.php?title=Plasma/libplasma2&oldid=36267"