Making dbus optional in Calligra

[Sebastian Sauer]

On 02/07/2012 11:00 PM, Jaroslaw Staniek wrote:
> On 7 February 2012 22:31, Sebastian Sauer<mail at dipe.org>  wrote:
>> On 02/07/2012 08:54 PM, Jaroslaw Staniek wrote:
>>> On 7 February 2012 20:34, Sebastian Sauer<mail at dipe.org>    wrote:
>>>> On 02/07/2012 03:09 PM, Boudewijn Rempt wrote:
>>>>> On Tue, 7 Feb 2012, Jaroslaw Staniek wrote:
>>>>>
>>>>>> 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?
>>>>>
>>>>> Compile switches tend to bitrot -- suddenly a particular option no
>>>>> longer
>>>>> compiles or works because nobody is actually using that option anymore.
>>>>
>>>> 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.
>>> +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...
>>
>> 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)?
>>
> I have one side note. Many plugins are consisted of business logic +
> GUI. On targets where QML is the GUI part,

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 :-/

> 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.

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 :-/

> 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.

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.

> 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)

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.

> 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).

yes

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/calligra-devel/attachments/20120208/a6caad61/attachment.htm>