--===============5863538821224060601== Content-Type: multipart/alternative; boundary=94eb2c0876a2c21a60051e88fecc --94eb2c0876a2c21a60051e88fecc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, Aug 29, 2015 at 10:41 PM, Friedrich W. H. Kossebau 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. --94eb2c0876a2c21a60051e88fecc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= at, Aug 29, 2015 at 10:41 PM, Friedrich W. H. Kossebau &l= t;kossebau@kde.org> wrote:
Am Donnerstag, 27. Au= gust 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 t= he
> krita-specific stuff, and for Krita, we can strip out the stuff that o= nly
> makes sense for office applications.
>
> I also think that it makes sense for Krita to integrate the karbon plu= gins
> 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 d= rawing
> application without a dedicated maintainer, and Karbon has been offici= ally
> unmaintained since April 2013 already.

Oh dear, for quite some time I have feared this proposal to happen, to spli= t
off Krita + fork off shared libs into an own project and repo. Sadly I coul= d
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 peo= ple
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 fi= ne
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.
((Ideally those people should be made interested in the whole Calligra suit= e
:) But given the current state of most apps that's a mission to fail sa= dly
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<= br> 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 t= o
restart with a new sheet when some text line mistakenly hit the sheet borde= r
too early or had a typo or when some item was forgotten in the structure an= d
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 re= al
FLOSS replacement)

Writing reports during education and work I experienced additional challeng= es,
how to best do big structured documents and also automatically integrate things generated from data, like calculations, diagrams, graphs or tables.<= br> Doing this with the wordprocessors available to me was not easy, escaping t= o
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 shoul= d
end up with being able to have not only classic line & bar diagrams, bu= t e.g.
whole flow charts being generated, with custom shapes dynamically powered b= y
data from databases or cell ranges in sheets.
One would edit the database table in some UI made from Kexi components or s= ome
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. w= hen
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 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, whe= re
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 := )
). There are many applications which render/export content to documents, ju= st
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 penci= ls
(multiple kinds of) over the typewriter. And also often ignored the ruler f= or
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 sketch= es
with a pen, highlight stuff, add some stuff just for visual fun. Disregardi= ng
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 thi= s
could be done using Krita components.

I would like to have Calligra as a rich content creation suite/framework. F= or
static content. Perhaps also for animated content, actually Stage and soon<= br> 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 fro= m
Calligra components, with the different images as subdocuments, which could= be
edited in place if wanted or edited "zoomed" in in separate UI sh= ell 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=C3=A9alities, of changeable size (well, with glue and g= lue
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<= br> 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 low= er
a lot :(

Oh well. Travellers should not be stopped. If Krita wants to move on into a= n
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<= br> work on better support for text structure management, until Words works goo= d
enough for my daily real world text editing needs. Then I would go for fixi= ng
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 bo= th,
as this is my biggest pain that we have two different plugin-based-object-o= n-
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 KOffic= e 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 t= hat the applications have to work fundamentally different and there is no s= ystem that fits all.

We sta= rted out offering endless choise for the users and gave them everything. Bu= t 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 need= ed. So over time we dialed back the available shapes until we have only sim= ple geometry, paths and text.
The same happ= end with tools which felt often out of place and Krita, so we made tools th= at wrapped around flake tools. To this day users are confused by tools that= don't behave like the rest of Krita.
<= br>
If you look at target users and Krita a= nd the office applications there is almost no intersection. The usecase tha= t someone want to copy something from Words or Sheets to Krita is practical= ly non-existing. In this case the potential advantage doesn't justify t= he additional complexity and extra work that comes with it. The way Calligr= a is currently build leads to distributions that package everything and sud= denly Krita users wonder why they have to install Akonadi and a MySQL serve= r.

--94eb2c0876a2c21a60051e88fecc-- --===============5863538821224060601== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KY2FsbGlncmEt ZGV2ZWwgbWFpbGluZyBsaXN0CmNhbGxpZ3JhLWRldmVsQGtkZS5vcmcKaHR0cHM6Ly9tYWlsLmtk ZS5vcmcvbWFpbG1hbi9saXN0aW5mby9jYWxsaWdyYS1kZXZlbAo= --===============5863538821224060601==--