Plasma/libplasma2/API Review/DataEngine


Status Action Method
DONE Remove explicit DataEngine(QObject *parent , KService::Ptr service);
DONE Add explicit DataEngine(QObject *parent, const KPluginInfo &info);
DONE Remove DataEngine(QObject *parent, const QVariantList &args);
DONE Keep ~DataEngine();
DONE Remove? virtual void init(); can be removed is there will be only one constructor
DONE Keep virtual QStringList sources() const;
DONE Keep virtual Service *serviceForSource(const QString &source);
DONE Add KPluginInfo pluginInfo() const;
DONE Remove QString name() const;
DONE Remove QString icon() const;
DONE Remove QString pluginName() const;
DONE Keep void connectSource(const QString &source, QObject *visualization, uint pollingInterval, Plasma::IntervalAlignment intervalAlignment ) const;
DONE Keep void connectAllSources(QObject *visualization, uint pollingInterval, Plasma::IntervalAlignment intervalAlignment) const;
DONE Keep void disconnectSource(const QString &source, QObject *visualization) const;
DONE Keep DataContainer *containerForSource(const QString &source);
DONE Remove DataEngine::Data query(const QString &source) const;
DONE Keep bool isValid() const;
DONE Keep bool isEmpty() const;
DONE Keep Package package() const;
DONE Remove Service* createDefaultService(QObject *parent );
DONE Move static QStringList listAllEngines(const QString &parentApp); -> in PluginLoader
DONE Move static KPluginInfo::List listEngineInfo(const QString &parentApp); -> in PluginLoader
DONE Move static KPluginInfo::List listEngineInfoByCategory(const QString &category, const QString &parentApp);
DONE Keep void sourceAdded(const QString &source);
DONE Keep void sourceRemoved(const QString &source);
DONE Keep virtual bool sourceRequestEvent(const QString &source);
DONE Keep virtual bool updateSourceEvent(const QString &source);
DONE Keep void setData(const QString &source, const QVariant &value);
DONE Keep void setData(const QString &source, const QString &key, const QVariant &value);
DONE Signature void setData(const QString &source, const Data ->QHash<QString, QVariant> &data); -> Data becomes QHash<QString, QVariant>
DONE Keep void removeAllData(const QString &source);
DONE Keep void removeData(const QString &source, const QString &key);
DONE Keep void addSource(DataContainer *source);
DONE Keep void setMinimumPollingInterval(int minimumMs);
DONE Keep int minimumPollingInterval() const;
DONE Keep void setPollingInterval(uint frequency);
DONE Keep void removeAllSources();
DONE Keep void setValid(bool valid);
DONE Signature SourceDict -> QHash<QString, DataContainer*> containerDict() const;
DONE Keep void timerEvent(QTimerEvent *event);
DONE Remove void setName(const QString &name);
DONE Remove void setIcon(const QString &icon);
DONE Remove void setDefaultService(const QString &serviceName);
DONE Keep void setStorageEnabled(const QString &source, bool store);
DONE Move slot void scheduleSourcesUpdated(); -> to private class
DONE Keep slot void removeSource(const QString &source);
DONE Keep slot void updateAllSources();
DONE Keep slot void forceImmediateUpdateOfAllVisualizations();

DataEngine functionality currently:

   * Timed updates
   * Ease of item creation and update
   * Item destruction when not used
   * Service integration

DataEngine functionality missing:

   * Introspection / self-documenting structures
   * Ability to represent as model internally

Open Questions

These questions have come up during review-review, and should be clarified to users of our API:

   * When to write a DataEngine, when to use an import? (In a world, where we have import security)
   * Add possibility to expose QObject*s in the API, much like QAIM*s
   * Why have QVariant(Map,Hash) *and* models, why not deprecate one?
   * Should we deprecate the QVariant*, now we have models?

QML Access

   * Can haz a model?
DataEngine {
	QAbstractItemModel *model() const;
DataSource {
	engine: “keystate”
	sources: “*Button”
	fields: {“Pressed”}

Example of source types of twitter engine

Twitter			tweets		posting 1		dents		posting 2 		dents		posting
avatars		model { name : picture }

TwitterModel *model = new TwitterModel(“twitter account foo”); setData(“twitter account foo”, model);

bool pressedState = false; setData(“key”, “pressed”, pressedState);

DataContainer -> model, or contains a model …

What do we want?

  • lifecycle management
  • ondemand creation
  • keep existing API (setData, service-related stuff)
  • make it easy to use “3rd party models” (e.g. some akonadi model)

Current dataengines

  • akonadi - Akonadi PIM data engine
  • applicationjobs - Application job updates (via kuiserver)
  • apps - Information and launching of all applications in * the app menu.
  • calendar - Calendar data engine
  • comic - Online comic strips
  • devicenotifications - Passive device notifications for the user.
  • dict - Look up word meanings
  • executable - Run Executable Data Engine
  • favicons - Data Engine for getting favicons of web sites
  • filebrowser - Information about files and directories.
  • geolocation - Geolocation Data Engine
  • hotplug - Tracks hot-pluggable devices as they appear and disappear.
  • kdeobservatory - A Data Engine for acquiring consolidated data about KDE projects
  • keystate - Keyboard modifier and mouse buttons states
  • kget - No description available
  • kimpanel - DataEngine for Kimpanel
  • kremotecontrol - Data engine for kremotecontrol
  • ktorrent - KTorrent data engine, for getting information from KTorrent
  • metadata - No description available
  • microblog - and twitter micro-blogging services
  • mixer - No description available
  • mouse - Mouse position and cursor
  • mpris2 - Provides information from and control over media players via MPRIS2
  • network - Network interface information
  • networkmanagement - Network Manager data engine
  • notifications - Passive visual notifications for the user.
  • nowplaying - Lists currently playing music
  • obsdataengine - DataEngine to make API Calls to the Open Build Service
  • ocs - No description available
  • openstreetmap - The OpenStreetMap data engine can be used to query things near the user.
  • - Information and launching of all applications in the app menu.
  • - Bookmarks from Nepomuk
  • - Provides information and services for device-specific aspects
  • - Provides metadata for custom searches in semantic resources
  • - Provides metadata for semantic resources
  • - Provides metadata for custom searches in semantic resources
  • org.kde.activities - Information on Plasma Activities
  • org.kde.alarms - List and set Akonadi Alarms
  • org.kde.devicecapabilities - Provides information and services for device-specific aspects
  • org.kde.examples.customDataContainers - A demonstration of how to subclass DataContainer
  • org.kde.examples.simpleEngine - A very basic DataEngine implementation
  • org.kde.examples.sourcesOnRequest - A DataEngine example showing how to respond to requests for source creation and updates
  • org.kde.konqprofiles - List and launch Konqueror profiles
  • org.kde.konsoleprofiles - List and launch Konsole profiles
  • org.kde.mobilenetworkengine - Mobile network engine
  • org.kde.mobileprofileengine - No description available
  • org.kde.plasma.dataengine.share - Engine to share content using different services
  • org.kde.preview - Shows previews for webpages
  • org.kde.printers - No description available
  • org.kde.printjobs - No description available
  • org.kde.runner - Query KRunner and execute the results
  • org.kde.sharelikeconnect - Provider of actions for sharing resources
  • parley - Vocabulary data for Plasmoids
  • places - Places, as seen in the file manager and in file dialogs.
  • potd - Data Engine for getting various online Pictures of The Day.
  • powermanagement - Battery, AC, sleep and PowerDevil information.
  • publictransport - Plasma data engine for public transport
  • rss - RSS News Data Engine
  • rtm - An engine to work with Remember the Milk.
  • searchlaunch - Engine to handle queries to SAL containment
  • soliddevice - Device data via Solid
  • statusnotifieritem - Engine for applications' status information, based on the Status Notifier protocol.
  • systemmonitor - System status information
  • tasks - Information and management services for all available windows.
  • time - Date and time by timezone
  • weather - Weather data from multiple online sources
  • workareas - Workareas Data Engine, as described in the WorkFlow Project

This page was last edited on 6 May 2013, at 14:15. Content is available under Creative Commons License SA 4.0 unless otherwise noted.