Why I love(d) Krita to be part of Calligra (was: Re: After 2.9.7)

[Sven Langkamp]

On Sat, Aug 29, 2015 at 10:41 PM, Friedrich W. H. Kossebau <kossebau at kde.org
> wrote:

> Am Donnerstag, 27. August 2015, 09:57:32 schrieb Boudewijn Rempt:
> > For Krita, and I hate to say this, it probably makes sense to fork our
> > shared libraries. The office-apps maintainers can then strip out all the
> > krita-specific stuff, and for Krita, we can strip out the stuff that only
> > makes sense for office applications.
> >
> > I also think that it makes sense for Krita to integrate the karbon
> plugins
> > and tools, and maybe the karbon filters. I honestly don't see any future
> > for karbon as a separate application. You cannot build a good vector
> drawing
> > application without a dedicated maintainer, and Karbon has been
> officially
> > unmaintained since April 2013 already.
>
> Oh dear, for quite some time I have feared this proposal to happen, to
> split
> off Krita + fork off shared libs into an own project and repo. Sadly I
> could
> not collect enough arguments why that would be an insane idea and only
> that.
> From a pragmatical point of view, I see more advantages than disadvantages
> as
> well for all parties, if I am honest, given the current interest of all
> people
> involved in contributions. There are more and more who only are interested
> in
> one app and not the whole Calligra suite, which is just reality and thus
> fine
> and nothing to blame someone for. And if one only has interest in one app,
> shared goods with other apps cannot be dealt with in the needed manner.
> ((Ideally those people should be made interested in the whole Calligra
> suite
> :) But given the current state of most apps that's a mission to fail sadly
> currently))
>
> But: such a split would conflict a lot with my motivation for why I have
> joined the Calligra project and spent quite some time on mainly cleaning up
> Calligra code so far :(
>
> I have been appealed by the vision of a component-based system, where one
> potentially could assemble a custom UI per usecase and create rich composed
> documents with all kind of content. Like I could when I was a kid and blank
> sheets of paper were what I had as canvas, and the working shell was by my
> real-world desktop setup. E.g. with pencils and stickers always in reach
> on my
> private desktop, depending on my mood of the day, to do whatever mix of
> content on the sheet of paper as I liked.
>
> When then I had my first computer, I was mainly attracted by the virtual
> sheets those enabled. Where things could be undone or reshuffled (no need
> to
> restart with a new sheet when some text line mistakenly hit the sheet
> border
> too early or had a typo or when some item was forgotten in the structure
> and
> no more space was available).
> I loved Geoworks, Amipro, and especially Corel Draw, as those gave me many
> of
> the composing freedoms one had with a real sheet and then all the amazing
> options coming with virtual objects. (And I miss them, so far I found no
> real
> FLOSS replacement)
>
> Writing reports during education and work I experienced additional
> challenges,
> how to best do big structured documents and also automatically integrate
> things generated from data, like calculations, diagrams, graphs or tables.
> Doing this with the wordprocessors available to me was not easy, escaping
> to
> TeX (or Lyx) only satisfied me to a certain degree.
>
> Which is the other aspect of Calligra that appealed me, having Kexi, Sheets
> and a report generation library as part. So I envisioned one day this
> should
> end up with being able to have not only classic line & bar diagrams, but
> e.g.
> whole flow charts being generated, with custom shapes dynamically powered
> by
> data from databases or cell ranges in sheets.
> One would edit the database table in some UI made from Kexi components or
> some
> cell ranges in a UI made from Sheets components and see the document
> update in
> realtime. Perhaps even be able to sync changes back from the shapes (e.g.
> when
> resizing some element interactively). (Actually I kept Plan alive for now
> mainly for the reporting stuff, to have another use case around).
>
> Connected with this, I also share Jarosław dream about document-wide
> theming/styling, where all components in the document are bound to the same
> styling system, and any custom component plugin could link into it. So e.g.
> colors and fonts in diagrams would be coupled to those of the complete
> document, for a consistent look.
>
> Next, when I wrote the print exporting functionality in Okteta, a hex
> editor, I would have liked instead to render into some document system,
> where
> one could edit the template (think footer/header/title/styles) or and more
> (actually I once did a hexeditor Shape plugin, that could at least render
> :)
> ). There are many applications which render/export content to documents,
> just
> think of all the science app in KDE Edu, like Labplot or Cantor. But
> usually with hardcoded templates. This seems poor to me, we could do better
> especially in the Free and Libre Software world, where collaboration
> should be
> easier than in that other buy-only-our-products lock-in world.
>
> Which brings me back to Krita. So, with real world sheets I preferred
> pencils
> (multiple kinds of) over the typewriter. And also often ignored the ruler
> for
> lines, unless needed for math stuff. Because of the unlimited expression
> flexibility and a little also because it gave the content a more personal
> sketch.
> So I want to be able to do the same with my virtual sheets. Do quick
> sketches
> with a pen, highlight stuff, add some stuff just for visual fun.
> Disregarding
> of the main type of content on the sheet. Especially now that pen-like
> hardware input devices are getting more common. So I envisioned one day
> this
> could be done using Krita components.
>
> I would like to have Calligra as a rich content creation suite/framework.
> For
> static content. Perhaps also for animated content, actually Stage and soon
> Krita partialy are about documents with a time dimension.
>
> E.g. something like a Pepper & Carrot webcomic should be possible to be
> done
> completely with an app composed from Calligra components one day:
> the web comic would be a metadocument, with a suiting UI shell composed
> from
> Calligra components, with the different images as subdocuments, which
> could be
> edited in place if wanted or edited "zoomed" in in separate UI shell made
> from
> Krita components, with the text in the bubbles being driven by a database
> controlled via Kexi components.
>
> In my mind there is no split between "office" and other documents. A sheet
> is
> a sheet. Multiple sheets are multiple sheets. They can be of fixed size,
> or,
> thanks to virtual réalities, of changeable size (well, with glue and glue
> strips one could also enlarge real sheets, but that never was perfect :) ).
> And one can put any type of content on a sheet (or canvas).
> I only see splits in workflows, depending on the main purpose of different
> type of document main types. That's a matter of the presentation and
> interaction layer.
> But the actual document I want to be able to fill with any type of content,
> always. In an integrated system, with no need to do lots of
> import/export/copy/paste between multiple apps with perhaps even
> data/precision loss.
> And pen-based content creation is my wet dream here.
>
> Darn. If Krita would split off, chances at least for some of my visions
> lower
> a lot :(
>
> Oh well. Travellers should not be stopped. If Krita wants to move on into
> an
> own house, with own stuff in basement and attic, their choice.
> There is only one way to get them back: make Calligra a palace with greater
> stuff in basement and attic. And in the sheds. And with a pool ;)
> Each summer and winter we will make a party and invite them. And show
> off...
> until they move back and together we then make our palace even greater :)
> (hm, suddenly not sure those mushrooms were all of the same kind...)
>
> For now I look forward to get the port of Calligra to Qt5/KF5 finally
> completed, so I could check off this as done and turn to continue all the
> refactoring branches I started for further cleanup of things in the libs I
> do
> not like too well (e.g. splitting kostore out of koodf, almost completed
> in a
> branch, and also rewriting kostore for more convenient use).
> Next on my plan then is joining the Words developers a little to fix up all
> the text features which are currently rather broken (e.g. variables), then
> work on better support for text structure management, until Words works
> good
> enough for my daily real world text editing needs. Then I would go for
> fixing
> SVG support, as I also need/want that.
> And in the meantime also play around more with a lib I started which should
> allow to merge KReport and Flake or at least serve as shared base lib to
> both,
> as this is my biggest pain that we have two different
> plugin-based-object-on-
> canvas systems here, with no reuse of code right now.
>
> So, I will be busy for some time with Calligra in any case :) Just, I would
> love if that involved Krita code as well.
>
> Cheers
> Friedrich
>

This was the vision of KOffice 2 where we just wanted to have independent
components (flakes) that could compose any form of document. A lot of work
was put into flake and making this come true. I really like the idea at
first and put a lot of work into integrating it in Krita. We got to the
point where KWord looked like Krita and Krita could embed spreadsheets. I
think what we ignored was the point that the applications have to work
fundamentally different and there is no system that fits all.

We started out offering endless choise for the users and gave them
everything. But at some point it became clear that in many cases it was
just overkill. We spend a huge amout of time to fix things like bugs that
showed up in Krita when a spreadsheet was insert. That's a feature that no
user ever needed. So over time we dialed back the available shapes until we
have only simple geometry, paths and text.
The same happend with tools which felt often out of place and Krita, so we
made tools that wrapped around flake tools. To this day users are confused
by tools that don't behave like the rest of Krita.

If you look at target users and Krita and the office applications there is
almost no intersection. The usecase that someone want to copy something
from Words or Sheets to Krita is practically non-existing. In this case the
potential advantage doesn't justify the additional complexity and extra
work that comes with it. The way Calligra is currently build leads to
distributions that package everything and suddenly Krita users wonder why
they have to install Akonadi and a MySQL server.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/calligra-devel/attachments/20150830/8f4cd1e7/attachment.htm>