Calligra on Tizen and beyond

[Jaroslaw Staniek]

On 30 September 2011 18:37, Sebastian Sauer <mail at dipe.org> wrote:
> On 09/30/2011 05:34 PM, Jaroslaw Staniek wrote:
>>
>> On 30 September 2011 15:51, Sebastian Sauer<mail at dipe.org>  wrote:
>>>
>>> On 09/30/2011 10:45 AM, Boudewijn Rempt wrote:
>>>
>>> On Friday 30 September 2011 Sep, Sebastian Sauer wrote:
>>>
>>> 2) to get a HTML5 canvas backend done for Qt similar to what broadway
>>> does in GTK
>>>
>>> Actually, that already worked after a fashion in February or even
>>> earlier.
>>> I've seen Marijn demo Tables running in firefox
>>>
>>> Oh, great to know. Somebody shuld blog+showcase it cause that is a cool
>>> thing especially
>>> if it comes to making some fast PR-points :-)
>>
>> Dear All, let's step back and think what the broadway-like stuff
>> really is. This is not HTML5 app but client (viewer) for server
>> process that is still native GTK/Qt app that may be.
>
> Sure, HTML5 is about the client-side and *NOT* about the server. That
> is the point. Canvas as implemented by broadway *IS*
> HTML5 and it's a clear client-server separation. You can run both
> on the same machine

You can't: as I said the server cannot use Qt, maybe not even STL.

> or you can use thin-clients with only Browsers
> installed that are connected over a network with a central server.

This is different use case. You won't get functionality of Calligra
because you won't offer offline use (since you cannot move 'server' to
the client device).

> The point is that you have a client-server separation and
> the client-side needs nothing but a HTML5 browser.

true, but see above, it's not useful without core that you cannot
deploy under our assumptions.

>> HTML5 app is the
>> one that you can use without extra runtimes also, say, on Android and
>> iOS. This is what Zemlin
>> The native app does not benefit in any way from browser security,
>
> I think you are mixing client and server up here. The browser
> sandbox is *only* about the browser- aka client-side but not
> the "native app" aka server-side.

But this is not idea for Tizen. Also look at Win8's sandboxed apps:
according to reports they have to be HTML5.

>> just
>> like switching from x11 graphicsystem to -raster changes nothing is
>> this regard. I would also say more layers is a pain with not benefit.
>>
>> There is no Calligra for HTML5 and I think we do not even think about
>> it.
>
> Boudewijn just wrote that there is a HTML5 Canvas backend for
> Qt (or maybe I did understood that wrong? in any case I really
> would like to have a look at it :-) ).
> If that's the case then we
> already have Calligra for HTML5.

No, you confused this with "being able plug gfx backend directed to
HTML5 window".

> But yes, the solution is probably
> suboptional in terms of amount of data that need to be transfered
> between client and server. Even better would be a "QML client-side
> library" that doesn't need regular canvas-updates but has and runs
> most of the logic on the client-side.

This idea is entirely different than 'the HTML5 gfx backend' and I
proposed this for consideration (needs full Qt Quick stack on the
client).
No matter if plugged to browser in any way or executed as
qmlviewer-like full-screen window or widget. Very nice and themeable
for any machine from mobile to powerfull desktop, can give us the
'web' deployment experience. But again, this is for new apps with no
binary deps, Calligra has established codebase.

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