<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
On 02/07/2012 11:00 PM, Jaroslaw Staniek wrote:
<blockquote
cite="mid:CAOj7QQ2byX=_UgibakN9BHGqTvxQdBiDC_3FD-3sWE6h3LiMdQ@mail.gmail.com"
type="cite">
<pre wrap="">On 7 February 2012 22:31, Sebastian Sauer <a class="moz-txt-link-rfc2396E" href="mailto:mail@dipe.org"><mail@dipe.org></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On 02/07/2012 08:54 PM, Jaroslaw Staniek wrote:
</pre>
<blockquote type="cite">
<pre wrap="">
On 7 February 2012 20:34, Sebastian Sauer<a class="moz-txt-link-rfc2396E" href="mailto:mail@dipe.org"><mail@dipe.org></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">
On 02/07/2012 03:09 PM, Boudewijn Rempt wrote:
</pre>
<blockquote type="cite">
<pre wrap="">
On Tue, 7 Feb 2012, Jaroslaw Staniek wrote:
</pre>
<blockquote type="cite">
<pre wrap="">I am not sure about the plugin idea. Plugins are good if there are
alternative means implemented supporting the same interface - here the
generic local communication.
Is that the case here? How about complexity that would not pay off?
</pre>
</blockquote>
<pre wrap="">
Compile switches tend to bitrot -- suddenly a particular option no
longer
compiles or works because nobody is actually using that option anymore.
</pre>
</blockquote>
<pre wrap="">
We have at least Windows, OSX and Android as user. On those platforms
dbus
would be disabled per default. Also Linux-users may decide to disable
dbus
in Calligra per default too (I certainly would cause it's just not needed
for my use-cases). So, I do not think that option could bitrot.
</pre>
</blockquote>
<pre wrap="">
+1 and thanks for the extensive pro/cons list.
I would say this very decision belong to people that do the deployment
and/or integration work, not users.
Let's start to think this way: real users pray for sane defaults not
for the hell of choices then did not want. [1]
Integrators want control but then - they can typically make choices at
compile^wdeployment time.
MSTEAHTP (Make simple things easy, and hard things possible)
PS: I wish my response would be taken as more generic. I remember how
much work it took me to port most of the Calligra plugins
infrastructure to Qt4 from Qt3. The extra runtime layer/plugins
translates to extra error-prone area...
</pre>
</blockquote>
<pre wrap="">
Plugins and mimetypes would be the next steps.
The just in kde-frameworks introduced libqmimetypes solves our
mimetypes-problem so it seems :)
Plugins are certainly harder. Do we need a cache or would be an alternate
backend be enough that just reads the plugin-informations from desktop-files
on the fly without storing them in a cache (what would remove all the need
for sycoca)?
</pre>
</blockquote>
<pre wrap="">
I have one side note. Many plugins are consisted of business logic +
GUI. On targets where QML is the GUI part,</pre>
</blockquote>
<br>
Indeed a problem. Long-term we clearly like to move UI out so
someone is able to use either QtGui or QML without compiling against
both of them. Sounds like lot of work :-/<br>
<br>
<blockquote
cite="mid:CAOj7QQ2byX=_UgibakN9BHGqTvxQdBiDC_3FD-3sWE6h3LiMdQ@mail.gmail.com"
type="cite">
<pre wrap=""><big><big><big></big></big></big>I would say the business
logic is small enough to be merged into larger piece. The code is not
loaded in advance but in parts by any sane OS, and the GUI if
especially is QML, is loaded on demand like a web page. And maybe some
plugins make no sense on QML-based targets.
</pre>
</blockquote>
<br>
Sure. Also some plugins may only make sense with some UI's. E.g. for
a viewer you do not really need all the editing-logic... In an ideal
world you would not need to compile/link against editing-plugins in
such a case. But that sounds like lot of work too :-/<br>
<br>
<blockquote
cite="mid:CAOj7QQ2byX=_UgibakN9BHGqTvxQdBiDC_3FD-3sWE6h3LiMdQ@mail.gmail.com"
type="cite">
<pre wrap="">Also, not every platform has end-user means to distribute, install
plugins and distinguish them from the multitude of apps.
(I do remember the maemo packages naming/categorization hell that made
this OS too
geeky in my eyes).
So I propose to identify platforms where having the plugins deployed
separately (from the user's POV) makes sense and where it's not
needed. I guess for the latter: any handset/tablet and maybe netbook.
</pre>
</blockquote>
<br>
Would make sense. Also in some cases a static application that just
compiles in all the needed plugins make lot of sense. Ee.g. afaik
WinCE has a limit on number/mem of plugins/libs and plugins always
come at a certain cost (loading them) which may not needed in some
cases. We would bet all that more or less for free using a
QPluginLoader like concept where plugins can be transparently
compiled in. I indeed think that's something we like to have not
only in Calligra but KDE-wide.<br>
<br>
<blockquote
cite="mid:CAOj7QQ2byX=_UgibakN9BHGqTvxQdBiDC_3FD-3sWE6h3LiMdQ@mail.gmail.com"
type="cite">
<pre wrap="">E.g. have you seen apps extendable by extra-installed packages in appstore
of iOS, Android, Symbian or even Harmattan etc.? (I am skipping the
not-end-user case of apt-get-install on Harmattan)
</pre>
</blockquote>
<br>
An example would be the "Accounts" application shipped per default
with the N9 that is using Telepathy offers additional plugins via
the store. Imagine how great it could have been if the "Documents"
application (aka Calligra on the N9) would have offered a way to
write all kind of plugins to extend that application. But yes, in
some cases it#s maybe not even wanted to allow to hook into an
application and extend it or in some situations there is just no
need for it.<br>
<br>
<blockquote
cite="mid:CAOj7QQ2byX=_UgibakN9BHGqTvxQdBiDC_3FD-3sWE6h3LiMdQ@mail.gmail.com"
type="cite">
<pre wrap="">I mean all the above for our own plugins.
3rd-party plugins is slightly another story; but I have not seen them
too many in the wild
even on desktop, also because we've not achieved too much of API
stability (which is still a convenient state IMHO).
</pre>
</blockquote>
<br>
yes<br>
<br>
</body>
</html>