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