Homerun sources and Plasma runners

[Aaron J. Seigo]

On Friday, November 16, 2012 13:36:59 Luiz Romário Santana Rios wrote:
> Beyond that, I think it would be nice if runners were turned into a
> library (something like librunner) so that other applications can
> benefit from it.

rekonq (example you used) can't use libplasma? if not, please describe why 
not.

(spoiler: for apps like rekonq, suggesting there is something to be gained by 
splitting out the runner infrastructure into its own library is rubbish.)

the only place there would be benefit[1] is if there is a lowering of 
dependencies. so i ran this in kdelibs/plasma/:

	grep -h include private/*runner* *runner* *query* | sort | uniq

here are the results, grouped by source:

standard system stuff:
	#include <cmath>

from libplasma:
	#include "abstractrunner.h"
	#include "abstractrunner.moc"
	#include "config-plasma.h"
	#include "dataengineconsumer_p.h"
	#include <plasma/package.h>
	#include <plasma/plasma_export.h>
	#include <plasma/plasma.h>
	#include <plasma/querymatch.h>
	#include "plasma/querymatch.h"
	#include <plasma/runnercontext.h>
	#include <plasma/runnersyntax.h>
	#include <plasma/version.h>
	#include "pluginloader.h"
	#include "private/abstractrunner_p.h"
	#include "private/runnerjobs_p.h"
	#include "runnercontext.h"
	#include "runnercontext.moc"
	// #include "runnerjobs.moc"
	#include "runnerjobs_p.h"
	#include "runnermanager.h"
	#include "runnermanager.moc"
	#include "runnersyntax.h"
	#include "scripting/runnerscript.h"

from kdecore:
	#include <kconfiggroup.h>
	#include <kdebug.h>
	#include <klocalizedstring.h>
	#include <kmimetype.h>
	#include <kplugininfo.h>
	#include <kprotocolinfo.h>
	#include <kservice.h>
	#include <kservicetypetrader.h>
	#include <kshell.h>
	#include <kstandarddirs.h>
	#include <kurl.h>

from kdeui:
	#include <kcompletion.h>
	#include <kicon.h>

from QtCore:
	#include <QCoreApplication>
	#include <QDir>
	#include <QFile>
	#include <QFileInfo>
	#include <QHash>

from QtGUI:
	#include <QAction>
	#include <QIcon>
	#include <QMenu>
	#include <QMimeData>
	#include <QMutex>
	#include <QMutexLocker>
	#include <QReadWriteLock>
	#include <QSet>
	#include <QSharedData>
	#include <QStringList>
	#include <QtCore/QList>
	#include <QtCore/QMutex>
	#include <QtCore/QObject>
	#include <QtCore/QSharedDataPointer>
	#include <QtCore/QStringList>
	#include <QTimer>
	#include "querymatch.h"
	#include <QVariant>
	#include <QWeakPointer>

from Solid:
	#include <solid/device.h>
	#include <solid/deviceinterface.h>

from ThreadWeaver:
	#include <Weaver/DebuggingAids.h>
	#include <Weaver/Job.h>
	#include <Weaver/QueuePolicy.h>
	#include <Weaver/State.h>
	#include <Weaver/Thread.h>
	#include <Weaver/ThreadWeaver.h>

to move it to a low-dependency library it seems the following should happen:

* port from ThreadWeaver to plain Qt. perhaps QRunnable + QThreadPool would be 
enough

* remove libsolid usage and let QThreadPool figure out the number of threads to 
use

* determine if RunnerScriptEngine is only referenced by runner-related classes 
in libplasma; if not, make it so

* work out a structure for DataEngine and PluginLoader, since the runner 
classes require both. one possibility would be to put DataEngine, Service and 
the runner classes into one library that focuses on information/service 
retrieval and have whatever library PluginLoader ends up in link against that

so if someone wants a separate library for runner, please branch frameworks in 
kdelibs and do the above work. thanks ...

[1] other than to work around the inability for application developers to 
accurately determine cost of using a given library, such as libplasma. i 
really dislike designing with such placebo effects as requirements.

-- 
Aaron J. Seigo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20121117/ad7b0e06/attachment.sig>