Making dbus optional in Calligra

Jaroslaw Staniek staniek at kde.org
Tue Feb 7 22:00:58 GMT 2012


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

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)

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

-- 
regards / pozdrawiam, Jaroslaw Staniek
 http://www.linkedin.com/in/jstaniek
 Kexi & Calligra (kexi-project.org, identi.ca/kexi, calligra-suite.org)
 KDE Software Development Platform on MS Windows (windows.kde.org)



More information about the calligra-devel mailing list