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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
