Roadmap to Calligra Mini

[Sebastian Sauer]

On 06/19/2013 03:39 AM, Jaroslaw Staniek wrote:
> On 17 June 2013 21:11, Sebastian Sauer <mail at dipe.org> wrote:
>
>> Yep, Calligra Active was even the starting point when I begun that. I
>> switched away when going full threaded cause that was requiring a complete
>> different architecture and design. In Coffice all of Calligra runs in
>> another thread then the UI/QML. That means all operations are asynchronous
>> in Coffice unlike in Active and Calligra will never be able to block the UI.
>> Also I bundle all plugins into one plugin, all filters into one filter and
>> delay loading in Coffice plus don't use KDE plugin-lookup (aka sycoca) cause
>> sycoca isn't present, I rewrote the kde factory/plugin/kpart stuff, etc. pp.
> Please correct me, arent all these features are not irrelevant to
> whether the app's UI is QWidget-based or QML-based?

hmmm... I am not sure if I understood the question or its context.

In the case of Coffice it does not make a difference since all of QML 
runs in the qApp-thread. So, it would work also fine with 
s/QML/QWidget/. The thing is that in Coffice Calligra itself is 
headless. Means it has no UI, neither QWidgets nor QML. It cannot have 
cause it runs in a thread != qApp-thread. Sure it would work with QML 
(with some limitations) but it wouldn't with QWidget (yes, could be 
hacked around too).

If the question goes into the direction of if same could be done with 
the existing QWidget (or QML based like Active for that matter) codebase 
then no, it cannot. It needs from the ground up architecture changes to 
access *anything* Calligra asynchronous.

>
>> Since all that happened Qt5 progressed and meanwhile (means not so long ago)
>> work on scenegraph-based QTextDocument/QTextEdit landed. So, for Qt5 there
>> may an option (with very likely lots of additional work needed for our
>> use-cases) to solve the no-go all-in-one-thread problem at another level. On
>> the other hand there would still be work needed to get potential
>> long-blocking operations like loading threaded which is all solved in
>> Coffice as of today already.... Well, we will see.
> All the features are beneficial for Active and would land there too
> eventually, right?

"All the features" refers to Qt5 QtQuick? I think that's to far away 
right now.

Or does it refer to the current Coffice threading? No, that needs 
architecture changes.

Or does it refer to the slim fake-lib? Yes, that's even on my TODO (like 
so many other things). I think it would be just 1-2 days of work to make 
that happen. Active is already very good in that it drags in very less 
dependencies. I think there may not much changes needed at all in Active 
itself to make that work.