Calligra 2.9.7 released

[Jaroslaw Staniek]

Hi,
Today we have shipped Calligra 2.9.7 with many updates and a number of
new features:

https://www.calligra.org/news/calligra-2-9-7-released

Feel free to update!

-- 
regards, Jaroslaw Staniek

KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org
Calligra Suite:
: A graphic art and office suite - http://calligra.org
Kexi:
: A visual database apps builder - http://calligra.org/kexi
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: After 2.9.7

[Yue Liu]

On Aug 31, 2015 2:50 AM, "Dmitry Kazakov"  wrote:
>
>
>>> 1) I'm ok with forking Krita repository. We already depend from quite
few libraries from calligra libs. That is mostly, KoCanvasBase,
KoDocumentBase, flake and pigment.From all four only pigment looks
>>> reusable enough for me to have a separate repo. In our code we hack
quite a lot to adapt flake and document classes for our needs.
>>>
>>> 2) One more benefit of forking to another repository would be that the
size of the repo would become lower (correct me if I'm wrong). Since "Krita
for Cats" manual is still semi-official way of building
>>> Krita on some platforms this is really crucial for many users. Quite a
lot of people still have GPRS or limited internet, so downloading 700MiB
just to try Krita *is* a barrier. Another problem is
>>> translators. Basically, they need to have a full source tree around to
be able to check where the string comes from.
>>
>>
>> The repo size is one reason I'm actually considering to drop all
>> history. Create a fresh new repo with cleaned-up code only and start
>> again from commit 0. I know we check history a lot, but that history is
>> the history of Krita up to Krita 2.9.x, which is in the calligra repo.
>
>
> This will make our life really hard :(
>

For git there is a way to move files from one repo to another repo while
keeping history to only those files. You can do that for Krita split, first
create a branch to strip off office apps code, then create an empty krita
repo, then move all files and their history to the new repo.

This way you make repo smaller but still have krita history.

> --
> Dmitry Kazakov
>
> ___
> calligra-devel mailing list
> calligra-devel@kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
>
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: After 2.9.7

[Jaroslaw Staniek]

On 1 September 2015 at 02:14, Yue Liu  wrote:

>
> On Aug 31, 2015 2:50 AM, "Dmitry Kazakov"  wrote:
> >
> >
> >>> 1) I'm ok with forking Krita repository. We already depend from quite
> few libraries from calligra libs. That is mostly, KoCanvasBase,
> KoDocumentBase, flake and pigment.From all four only pigment looks
> >>> reusable enough for me to have a separate repo. In our code we hack
> quite a lot to adapt flake and document classes for our needs.
> >>>
> >>> 2) One more benefit of forking to another repository would be that the
> size of the repo would become lower (correct me if I'm wrong). Since "Krita
> for Cats" manual is still semi-official way of building
> >>> Krita on some platforms this is really crucial for many users. Quite a
> lot of people still have GPRS or limited internet, so downloading 700MiB
> just to try Krita *is* a barrier. Another problem is
> >>> translators. Basically, they need to have a full source tree around to
> be able to check where the string comes from.
> >>
> >>
> >> The repo size is one reason I'm actually considering to drop all
> >> history. Create a fresh new repo with cleaned-up code only and start
> >> again from commit 0. I know we check history a lot, but that history is
> >> the history of Krita up to Krita 2.9.x, which is in the calligra repo.
> >
> >
> > This will make our life really hard :(
> >
>
> For git there is a way to move files from one repo to another repo while
> keeping history to only those files. You can do that for Krita split, first
> create a branch to strip off office apps code, then create an empty krita
> repo, then move all files and their history to the new repo.
>
> This way you make repo smaller but still have krita history.
>

​Yes, please see for example:​
​https://community.kde.org/Kexi/Porting_to_Qt%26KF_5#Git_surgery​


​I did so with 3 repos splitted from calligra, 11 years of history.​ Every
file starts in src/*, even those from 2004. Even tags can be kept. Of
course prior revisions won't build; for buildable we have frameworks and
calligra/*.* branches of (current) calligra.git.

I am offering technical help here.

BTW, If we cut of, say, prior Krita history from calligra.git, it won't be
the original calligra.git anymore that people want to reference to see the
pre-september-2015 history.
We'd need a name for the original (large) calligra git repo with all the
apps.
calligra2-history.git? Simply calligra2.git sounds misleading.

> --
> > Dmitry Kazakov
> >
> > ___
> > calligra-devel mailing list
> > calligra-devel@kde.org
> > https://mail.kde.org/mailman/listinfo/calligra-devel
> >
>
> ___
> calligra-devel mailing list
> calligra-devel@kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
>
>


-- 
regards, Jaroslaw Staniek

KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org
Calligra Suite:
: A graphic art and office suite - http://calligra.org
Kexi:
: A visual database apps builder - http://calligra.org/kexi
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

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

[Cyrille Berger]

On Sunday 30 August 2015 17:30:22 Sven Langkamp wrote:
> 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.

To be honest, it was/is a problem for office application. The KOffice2 idea of 
one 
UI to fit them all, was a bad idea. We saw that in sheets that had a weird tool 
for editing cells, then words started to get a completely different UI. And I 
got unhappy with braindump because the tools didn't fit so well.

So in this end, a split between model and view in flake would be a good idea 
for office applications and krita. and would be needed for developing mobile 
UI. 
And would make it possible for me to provide the correct UI for braindump.

-- 
Cyrille Berger Skott
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

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

[Friedrich W. H. Kossebau]

Am Montag, 31. August 2015, 12:19:32 schrieb Cyrille Berger:
> On Sunday 30 August 2015 17:30:22 Sven Langkamp wrote:
> > 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.
> 
> To be honest, it was/is a problem for office application. The KOffice2 idea
> of one UI to fit them all, was a bad idea. We saw that in sheets that had a
> weird tool for editing cells, then words started to get a completely
> different UI. And I got unhappy with braindump because the tools didn't fit
> so well.
> 
> So in this end, a split between model and view in flake would be a good idea
> for office applications and krita. and would be needed for developing
> mobile UI. And would make it possible for me to provide the correct UI for
> braindump.

Yes, split between model and view in flake is one of the things I plan. Or 
rather a split between model, view and controller, given an idea of recursive 
MVC pattern as is being developed in my Kasten framework. (That one is 
currently stuck in a redesign, and waits for ideas being grown e.g. from 
Calligra design experience ;) ). 

Cheers
Friedrich
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: After 2.9.7

[Cyrille Berger]

On Monday 31 August 2015 12:50:12 Dmitry Kazakov wrote:
> > The repo size is one reason I'm actually considering to drop all
> > history. Create a fresh new repo with cleaned-up code only and start
> > again from commit 0. I know we check history a lot, but that history is
> > the history of Krita up to Krita 2.9.x, which is in the calligra repo.
> 
> This will make our life really hard

I agree, I don't think this is a really good idea. I think splitting out the 
test data in a different optional repository would help shrink the repository.

Also, we don't need to cutout the history, people who don't want the history 
can do:

git clone --depth 1 --branch master kde:krita

And they will get a fully functionnal tree, with only the master branch, that 
they can update with pull and provide patches. While leaving the rest of us 
with a full history.

If I do that with calligra, my .git goes from 789MB to 209MB.

-- 
Cyrille Berger Skott
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

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

[Dan Leinir Turthra Jensen]

On Monday 31 August 2015 03:46:23 Friedrich W. H. Kossebau wrote:
> Am Sonntag, 30. August 2015, 20:36:06 schrieb Boudewijn Rempt:
> > Long mail :-) Sven already said a lot of what I wanted to say. The thing
> > is, with KOffice 2.0, we actually got further along the road to making
> > fine-grained composite document possible. We got further than Apple,
> > IBM or Microsoft with projects like Taligent, Opendocs or OLE. Sure, we
> > made architectural mistakes, but to very large extent, the result works.
> 
> Which is what seems so great about Calligra for me :)
> 
> > With Calligra Gemini you can already combine hand-written annotations
> > with your document, for instance.
> 
> Oh, not noticed that, how can one do that? I saw voice and pre-made
> stickers, but pen input based option is at least not visible to me in the
> UI, also not on a touch device. Which code to look out for?

  The scribbling only works for on-canvas presentation things, not for 
documents in general - it is indeed only pre-made stickers (and stylised 
sticker type things with a small amount of text), not full blown scribble-
everywhere support.

> Then, Calligra Gemini seems rather dead, no commit since it was imported :/
> But I have hopes that I can sit together with leinir at Randa next week :)
> and revive this former beauty (rotten in master ATM) or at least see how to
> rescue the QtQuick bits for other usages.

  That is absolutely happening, yes - i use Gemini daily, and would be more 
than a little sad to see it go away :)

> > There are just two gotchas: the first is that for all of that, Krita's
> > specific strengths aren't needed, but on the other hand, a lot of
> > ballast. There are at least two image filter implementations in Calligra
> > next to Krita's, and those are more suited for compound documents,
> > for instance.
> 
> Not sure how things are ballast if they are done behind proper abstraction
> layers. What do you mean "filters" in "image filters"?
> 
> > The other is that the users aren't there. It was a grand vision, and
> > one that's really attractive to software developers, but users care
> > about one thing: getting the job done asap, so they can quit the word
> > processor and go back to doing their real work. And they're right.
> 
> IMHO the users are not here, because most of Calligra's apps were never
> ready as editors, due to being crashy as hell, losing data and having
> incomplete features, especially compared to their usecase rivals.
> The code was/is fine for loading and viewing documents. Both confirmed and
> reinforced by the commercial products made from Calligra code, as you said.
> And that is also why I picked up the Okular plugins of Calligra, to make
> this viewer power available to more players.
> But the code for document manipulation and storing seems to never have seen
> a similar care. Krita is the happy exception here.
> 
> The other problem is also that development of the core has stalled. Krita
> started to do workarounds to the existing core instead of seeing how to
> coevolve the core with the other apps, from what I saw. Surely also because
> of lack of interest of developers for other apps.
> 
> Then, my real work would rather be in the "word processor" or even something
> bigger. Because it's not just a few lines of text that I do. I am talking
> about rich content. That is why I am here in Calligra. See below.
> 
> So, I don't see at least this gotcha.
> 
> > That's another difference between Krita and office applications. Office
> > applications, unless you happen to be a novelist, support doing work, are
> > not tools to do the actual work. You use krita to produce the deliverable
> > you send to a customer, you use Words to create the accompanying invoice.
> 
> Perhaps that's where you miss my needs :)
> I am not interested in a software to just drop a few lines of text onto a
> sheet. And still I am not a novelist. No.
> I am interested in a software that allows me to create my long and content-
> rich reports, backed from database and other external sources, to create my
> leaflets, to create my hangout for the blackboard, invitation cards, content
> enriched letters to friends, tutorials, sheets with drafts for UI and
> architecture of software, drafts for garden design, costume drafts, etc.
> pp. With all kind of content types, wildly mixed on the same sheet.
> (He, I did the xfig import filter for a reason, like I started on the
> CorelDraw one)
> 
> Something where LO, Scribus or Inkscape do not cut it, for different
> reasons.
> 
> Having to write completely different software for reports, for leaflets, for
> hangouts, for invitation cards, for letters, for tutorials, for room
> concepts, for costume drafts, etc. seems insane to me. I still have the
> hope and many ideas, how reusable fine-grained components for the different
> kind of content types should allow to assemble working shells optimized for
> a certain main document type. Like one for doing long 

Re: After 2.9.7

[Boudewijn Rempt]

On Mon, 31 Aug 2015, Dmitry Kazakov wrote:


Hi, all!

Just my two cents:

1) I'm ok with forking Krita repository. We already depend from quite few 
libraries from calligra libs. That is mostly, KoCanvasBase, KoDocumentBase, 
flake and pigment.From all four only pigment looks
reusable enough for me to have a separate repo. In our code we hack quite a lot 
to adapt flake and document classes for our needs.

2) One more benefit of forking to another repository would be that the size of the repo 
would become lower (correct me if I'm wrong). Since "Krita for Cats" manual is 
still semi-official way of building
Krita on some platforms this is really crucial for many users. Quite a lot of 
people still have GPRS or limited internet, so downloading 700MiB just to try 
Krita *is* a barrier. Another problem is
translators. Basically, they need to have a full source tree around to be able 
to check where the string comes from.


The repo size is one reason I'm actually considering to drop all
history. Create a fresh new repo with cleaned-up code only and start
again from commit 0. I know we check history a lot, but that history is
the history of Krita up to Krita 2.9.x, which is in the calligra repo.


3) And if we decide to fork, I would really love to see a clear plan of 
"who-does-what" on each stage, since we have quite a lot of framework around 
this repo. Including KDE-CI, Launchpad builds, mails,
bugs, phabricator and etc.


Yes. I guess that would mostly be me. Mailing list and bugzilla are
repo-independent. If we create a new repo, that goes through sysadmin and
that incudes settig up ci, phabricator, reviewboard (well, I'd like to
drop that), translations, release system. Launchpad would be your task,
I'd say.

One big remaining problem is the animation/lod branch. Unless we say,
heck, 3.0 isn't stable anyway, let's merge that to master and work from
there, it's going to be tricky.


But I'll try to make a full list.

Boudewijn
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: 2.9.7

[Friedrich W. H. Kossebau]

Am Sonntag, 30. August 2015, 00:42:26 schrieb Jaroslaw Staniek:
> Thanks,
> @Maintainers
> Before end of Monday please send me changelogs for the release
> announcement. Thanks.

No changes in Plan, non-krita thumbnailers and Okular plugins for 2.9.7

Friedrich
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: After 2.9.7

[Boudewijn Rempt]

On Mon, 31 Aug 2015, Dmitry Kazakov wrote:



1) I'm ok with forking Krita repository. We already depend from 
quite few libraries from calligra libs. That is mostly, KoCanvasBase, 
KoDocumentBase, flake and pigment.From all four
only pigment looks
reusable enough for me to have a separate repo. In our code we hack 
quite a lot to adapt flake and document classes for our needs.

2) One more benefit of forking to another repository would be that the size 
of the repo would become lower (correct me if I'm wrong). Since "Krita for 
Cats" manual is still
semi-official way of building
Krita on some platforms this is really crucial for many users. 
Quite a lot of people still have GPRS or limited internet, so downloading 
700MiB just to try Krita *is* a barrier.
Another problem is
translators. Basically, they need to have a full source tree around 
to be able to check where the string comes from.


  The repo size is one reason I'm actually considering to drop all
  history. Create a fresh new repo with cleaned-up code only and start
  again from commit 0. I know we check history a lot, but that history is
  the history of Krita up to Krita 2.9.x, which is in the calligra repo.


This will make our life really hard :(


Well, it's something to consider if size of the final repo is important.

Boudewijn
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: 2.9.7

[Boudewijn Rempt]

Krita changelog:

Changes in Krita

Highlights:

* As is traditional, our September release has the first Google Summer of Code 
results. Wolthera's Tangent Normal Brush engine has already been merged and 
provides:
   * Tangent Normal Brush Engine
   * Phong Bumpmap now accepts normal map input.
   * Normalize filter.
   * Tilt Cursor.
* We've got all-new icons!
* You can configure the size of the icons used in the toolbox.
* Colorspacebrowser: if you want to know the nitty-gritty details about the 
colorspaces and profiles Krita offers, all information is now available in the 
new colorspace browser. Still under heavy polishing!
* You can pick colors and use the fill tool everwhere in wrap-around mode


Some more new features...

Implement ‘Scalable smoothness’ feature for Stabilizer smoother
update tooltips for toolbox icons
Right click to undo last path point.
Update tooltips to include keyboard shortcut.
Make the default size of the toolbox buttons dependent on screen resolution.
Added ability to merge down Selection Masks
Improve loading of PSDs of any colour space big time. 16bit CMYK psd files 
can now be loaded.
Add three shortcuts to fill with opacity
Implement loading for ZIP compressed PSD files
XCF: load group layers from XCF files v3 or higher
Allow ‘shift’-modifer after dragging an assistant handle to snap lines.
Add snap-single checkbox under assistant snapping.
Update brushes with optimised versions.(Basic_tip_default.kpp, 
Basic_tip_soft.kpp, Basic_wet.kpp, Block_basic.kpp, Block_bristles.kpp, 
Block_tilt.kpp, Ink_brush_25.kpp, Ink_gpen_10.kpp, Ink_gpen_25.kpp)
Mathematically robust normal map combination blending mode.
Slow down updates for randomized brushes.
added convert to shape for selections
Added Trim to Image Size action
Optimise dodge and burn filter.
Multiple layers merge with layer styles on Ctrl+E. (1) “Merge selected 
layers” is now deprecated and you can use usual Ctrl+E to merge multiple 
selection 2) Mass-merging of layers with layer styles works correctly now 3) 
Merging of clone layers together with their sources will not break Krita now.)
Make color to alpha work with 16f channel depths
Add new shortcuts (Scale Image to new size = CTRL+ALT+I, Resize Canvas = 
CTRL+ALT+C, Create Group, Layer = CTRL+G, Feather Selection = SHIFT+F6 )

And a host of bug fixes:

BUG: 351599 Fix abr brush loading
BUG:343615 Remember the toolbar visibility state
BUG:338839 Do not let the wheel zoom if there are modifiers pressed(Patch 
by var.spool.mail...@gmail.com. Thanks!)
BUG:347500 Fix active layer activation mask
Remove misleading error message after saving fails
BUG 350289 : Prevent Krita from loading incomplete assistant.
BUG:350960 Add ctrl-shift-s as default shortcut for save as
fix Bristle brush presets
Fix use normal map checkbox in phongbumpmap filter UI.
Fix loading the system-set monitorprofile
Make cs-convert UI attempt to automatically determine when to uncheck 
optimise
CCBUG:351488 Do not share textures when that’s not possible
Remove disabling of system profile checkbox
CCBUG:351488 Update the display profile when moving screens
Update the display profile after changing the settings
Fix crash due to calling a virtual method from c-tor of KisToolPaint
BUG:351664 Disable the layerbox if there’s no open image
BUG:345285 Correctly install the xcf import plugin on Windows
Fix Fill with … (Opacity) actions
BUG:351548 Make a transform tool work with Pass Through group layers
Fix parsing XML with MSVC 2012
Make all the lines of paintop options look the same
BUG:351560 Make sure a default KoColor is transparent
Lots of memory leak fixes (pointers that weren’t deleted are now deleted)
BUG:351497 Blacklist “photoshop”:DateCreated” when saving
Only add shortcuts for Krita…
Only ask for a profile for 16 bits png images, since there we assume linear 
by default, which is wrong for most png images.
Don’t build the thumb creator on Windows or OSX
Revert “Revert “Use the KisColorTransformationConfiguration””
BUG:350498 Work around encoding issues in kzip
BUG:348099 Better error message in PNG export
Don’t rename resources.
BUG:336693 Also change the color selector when selecting a vector layer
BUG:349554 Remove old compatibility code
BUG:349571 Disable the opacity setting for the shape brush
Initialize KoColor to black, as per apidox
CCBUG:351411 Add some explanation to the recovery dialog
BUG:321361 Load resources from subfolders
CCBUG:345619 Recreate a default bounds object on every KisMask::setImage() 
call
CCBUG:321361 Create subfolders for presets
BUG:349819 Fix a severe crash in Transformation Masks
BUG:349819 Add a barrier between sequentially undone commands with setIndex
Fixed API of KisPNGConverter to not acces the entire 

Re: 2.9.7

[Boudewijn Rempt]

I'm laid up with food poisoning right now, but we've already got a start
of a changelog, so that'll be possible.

On Sun, 30 Aug 2015, Jaroslaw Staniek wrote:


Thanks,
@Maintainers
Before end of Monday please send me changelogs for the release
announcement. Thanks.

On 26 August 2015 at 10:22, Cyrille Berger cber...@cberger.net wrote:

On 2015-08-25 14:10, Jaroslaw Staniek wrote:


So I am assuming this as OK.
@Cyrille are you available?
This is rather a deadline for me to push a fix for defective 2.9.5/6 Kexi.



Hopefully.

--
Cyrille Berger Skott




--
regards, Jaroslaw Staniek

KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org
Calligra Suite:
: A graphic art and office suite - http://calligra.org
Kexi:
: A visual database apps builder - http://calligra.org/kexi
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

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

[Boudewijn Rempt]

Long mail :-) Sven already said a lot of what I wanted to say. The thing
is, with KOffice 2.0, we actually got further along the road to making
fine-grained composite document possible. We got further than Apple,
IBM or Microsoft with projects like Taligent, Opendocs or OLE. Sure, we
made architectural mistakes, but to very large extent, the result works.

With Calligra Gemini you can already combine hand-written annotations
with your document, for instance.

There are just two gotchas: the first is that for all of that, Krita's
specific strengths aren't needed, but on the other hand, a lot of
ballast. There are at least two image filter implementations in Calligra
next to Krita's, and those are more suited for compound documents,
for instance.

The other is that the users aren't there. It was a grand vision, and
one that's really attractive to software developers, but users care
about one thing: getting the job done asap, so they can quit the word
processor and go back to doing their real work. And they're right.

That's another difference between Krita and office applications. Office
applications, unless you happen to be a novelist, support doing work, are
not tools to do the actual work. You use krita to produce the deliverable
you send to a customer, you use Words to create the accompanying invoice.

And that might just be the reason, not just for all the problems finding
contributors to the office software, but even for finding motivation
and time to actually make the projects big and well known.

Even now, even this year, reviews of Linux office software will say of
Calligra, promising, interesting, might become something with work,
which is exactly what they said in 2005.

Finally, Calligra has been a success, has been used in half a dozen
mobile products, with hundreds of thousands of users, but to continue 
being a success we need someone as crazy about Calligra as Michael Meeks

is crazy about Libre Office.

Boudewijn

Who still feels really bad :-(
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: 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 kosse...@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 

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

[Friedrich W. H. Kossebau]

Am Sonntag, 30. August 2015, 20:36:06 schrieb Boudewijn Rempt:
 Long mail :-) Sven already said a lot of what I wanted to say. The thing
 is, with KOffice 2.0, we actually got further along the road to making
 fine-grained composite document possible. We got further than Apple,
 IBM or Microsoft with projects like Taligent, Opendocs or OLE. Sure, we
 made architectural mistakes, but to very large extent, the result works.

Which is what seems so great about Calligra for me :)

 With Calligra Gemini you can already combine hand-written annotations
 with your document, for instance.

Oh, not noticed that, how can one do that? I saw voice and pre-made stickers, 
but pen input based option is at least not visible to me in the UI, also not 
on a touch device. Which code to look out for?

Then, Calligra Gemini seems rather dead, no commit since it was imported :/
But I have hopes that I can sit together with leinir at Randa next week :) and 
revive this former beauty (rotten in master ATM) or at least see how to rescue 
the QtQuick bits for other usages.

 There are just two gotchas: the first is that for all of that, Krita's
 specific strengths aren't needed, but on the other hand, a lot of
 ballast. There are at least two image filter implementations in Calligra
 next to Krita's, and those are more suited for compound documents,
 for instance.

Not sure how things are ballast if they are done behind proper abstraction 
layers. What do you mean filters in image filters?

 The other is that the users aren't there. It was a grand vision, and
 one that's really attractive to software developers, but users care
 about one thing: getting the job done asap, so they can quit the word
 processor and go back to doing their real work. And they're right.

IMHO the users are not here, because most of Calligra's apps were never ready 
as editors, due to being crashy as hell, losing data and having incomplete 
features, especially compared to their usecase rivals.
The code was/is fine for loading and viewing documents. Both confirmed and 
reinforced by the commercial products made from Calligra code, as you said.
And that is also why I picked up the Okular plugins of Calligra, to make this 
viewer power available to more players.
But the code for document manipulation and storing seems to never have seen a 
similar care. Krita is the happy exception here.

The other problem is also that development of the core has stalled. Krita 
started to do workarounds to the existing core instead of seeing how to 
coevolve the core with the other apps, from what I saw. Surely also because of 
lack of interest of developers for other apps.

Then, my real work would rather be in the word processor or even something 
bigger. Because it's not just a few lines of text that I do. I am talking 
about rich content. That is why I am here in Calligra. See below.

So, I don't see at least this gotcha.

 That's another difference between Krita and office applications. Office
 applications, unless you happen to be a novelist, support doing work, are
 not tools to do the actual work. You use krita to produce the deliverable
 you send to a customer, you use Words to create the accompanying invoice.

Perhaps that's where you miss my needs :)
I am not interested in a software to just drop a few lines of text onto a 
sheet. And still I am not a novelist. No.
I am interested in a software that allows me to create my long and content-
rich reports, backed from database and other external sources, to create my 
leaflets, to create my hangout for the blackboard, invitation cards, content 
enriched letters to friends, tutorials, sheets with drafts for UI and 
architecture of software, drafts for garden design, costume drafts, etc. pp.
With all kind of content types, wildly mixed on the same sheet.
(He, I did the xfig import filter for a reason, like I started on the 
CorelDraw one)

Something where LO, Scribus or Inkscape do not cut it, for different reasons.

Having to write completely different software for reports, for leaflets, for 
hangouts, for invitation cards, for letters, for tutorials, for room concepts, 
for costume drafts, etc. seems insane to me. I still have the hope and many 
ideas, how reusable fine-grained components for the different kind of content 
types should allow to assemble working shells optimized for a certain main 
document type. Like one for doing long reports. And another for doing 
invitation cards. And a third for costume drafts.
Like I can setup my real world desk or bench for different document types, by 
placing the usual content material and working tools in reach.

I did not clean up Calligra code and worked hard to push it together will all 
over the Qt5 hurdle for nothing, there would be lots of more enjoyable things 
in life to do ;) No. Hopefully I qualify not as mad, but I have a long TODO 
list for Calligra libs, and some code drafts. And now we are almost past 
intial Qt5/KF5 port, I so look forward to finally go 

Re: After 2.9.7

[Boudewijn Rempt]

On Sat, 29 Aug 2015, Cyrille Berger wrote:


On Friday 28 August 2015 15:43:12 Boudewijn Rempt wrote:

Well, we started the discussion with the idea that making separate repos
for the libraries and applications was going to be useful. That rather
soon turned into a discussion of the problems we have making our libraries
fit for purpose for all applications, and that turned into why should,
e.g., words and the libraries be in a separate repo, it's only a lot of
hassle.

And that's where the discussion stopped, so I wrote this mail to re-engage
the discussion.


I think the problems raised during that discussion were more:

1) How to keep the repositories in sync?
2) Who will fix breakage in applications?

I think Friedrich email from yesterday gives a reasonably good solution for 
1).


As for 2), the biggest problem is for unmaintained applications. But there, I 
think we have to take the hard decision of simply killing those applications, 
and keep the focus on applications that have people who care about them. And 
then, for small changes, it is up to maintainers to adjust their applications. 
Bigger changes should be more coordinated.


I am fine with either solution. If splitting off koofdf, kostore and
other libraries into frameworks means we can continue sharing them,
that would be good. If not, I can live with forking the libraries...

But before I come up with a proposal and start doing the split-off work,
I'd like a real go- ahead :-)

Boudewwijn
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: After 2.9.7

[Cyrille Berger]

On Friday 28 August 2015 15:43:12 Boudewijn Rempt wrote:
 Well, we started the discussion with the idea that making separate repos
 for the libraries and applications was going to be useful. That rather
 soon turned into a discussion of the problems we have making our libraries
 fit for purpose for all applications, and that turned into why should,
 e.g., words and the libraries be in a separate repo, it's only a lot of
 hassle.
 
 And that's where the discussion stopped, so I wrote this mail to re-engage
 the discussion.

I think the problems raised during that discussion were more:

1) How to keep the repositories in sync?
2) Who will fix breakage in applications?

I think Friedrich email from yesterday gives a reasonably good solution for 
1).

As for 2), the biggest problem is for unmaintained applications. But there, I 
think we have to take the hard decision of simply killing those applications, 
and keep the focus on applications that have people who care about them. And 
then, for small changes, it is up to maintainers to adjust their applications. 
Bigger changes should be more coordinated.

-- 
Cyrille Berger Skott
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

RE: After 2.9.7

[Camilla Boemann]

As much as I dislike forking I must admit it makes more sense than splitting 
the libraries.

1) there are conflicting or at list disjoint interests between krita and 
office. I am not complaining - it's just a fact. Forking will allow 
specialization - splitting will just produce arguing
2) by splitting it would fall on app maintainers to cleanup - uhm so I would 
have to spend hours to clean up for krita-needed-changes and vice versa, with 
no obligation from opposite part to make sure suc changes makes sense or are 
even possible to adapt to ?
3) the responsibility could possibly right now fall on the committer but let's 
not kid ourselves - that will change rapidly because it will mean that 
committers will still have to checkout all repos, making any benefit void.
4) the communities are already rather disjoint - few are present in both irc 
channels or help out in each other's code

On the other hand - the time together has been good or us all but I think the 
time has come to fork - I have no issue if krita wants to stay in the Calligra 
suite but even there their main pr and communication have already been split up 
years ago

So I suggest:
Krita.git
Calligra.git (without author, braindump, karbon, krita and kexi - so just 
words, stage, sheets and flow, libs , filters and plugins)
Kexi.git

Kexi are free to depend on Calligra.git, but even for kexi I have my doubts if 
it wouldn't be better to fork

Now I realize this might be the death of the office apps if we have no one left 
to do website maintainance, releases and general work. I  will do my part but I 
can't do everything. So if no one is prepared to stay and do releases etc then 
it still might be better to do the spltting ( but is that a guarantee things 
will be released or will krita/kexi eventually split up or do their own 
releases anyway. In which case Calligra will be split and no one to do the even 
larger release process.

If enough people are still interested in the office apps so that we can 
continue to release then I think forking is the best thing - if not I  can only 
hope splitting libs will not produce the same fate

Best regards
Camilla Boemann

-Original Message-
From: calligra-devel [mailto:calligra-devel-boun...@kde.org] On Behalf Of 
Boudewijn Rempt
Sent: 29. august 2015 09:38
To: Calligra Suite developers and users mailing list calligra-devel@kde.org
Subject: Re: After 2.9.7

On Sat, 29 Aug 2015, Cyrille Berger wrote:

 On Friday 28 August 2015 15:43:12 Boudewijn Rempt wrote:
 Well, we started the discussion with the idea that making separate 
 repos for the libraries and applications was going to be useful. That 
 rather soon turned into a discussion of the problems we have making 
 our libraries fit for purpose for all applications, and that turned 
 into why should, e.g., words and the libraries be in a separate 
 repo, it's only a lot of hassle.
 
 And that's where the discussion stopped, so I wrote this mail to 
 re-engage the discussion.

 I think the problems raised during that discussion were more:

 1) How to keep the repositories in sync?
 2) Who will fix breakage in applications?

 I think Friedrich email from yesterday gives a reasonably good 
 solution for 1).

 As for 2), the biggest problem is for unmaintained applications. But 
 there, I think we have to take the hard decision of simply killing 
 those applications, and keep the focus on applications that have 
 people who care about them. And then, for small changes, it is up to 
 maintainers to adjust their applications.
 Bigger changes should be more coordinated.

I am fine with either solution. If splitting off koofdf, kostore and other 
libraries into frameworks means we can continue sharing them, that would be 
good. If not, I can live with forking the libraries...

But before I come up with a proposal and start doing the split-off work, I'd 
like a real go- ahead :-)

Boudewwijn
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: After 2.9.7

[Tomas Mecir]

Heya,

no strong opinions on krita split either way, but while the libs stuff is
discussed, figured I'd send in the perspective of the
not-particularly-active Sheets maintainer :D

A problem that I have been running into with Sheets is that the shared libs
seem to contain more things than may be necessary. Can't really come up
with specific examples (though they would mostly involve flake/plugins),
but several times I've found that while fixing this or that bug/oddity, I
ended up having to crawl through quite a web of inter-dependencies between
Sheets code, libs code, then back into Sheets, bonus points if one more
libs detour was made.

That in itself isn't a concern, but when any change to libs could break
words or krita or whatever, it makes things a little bit tricky, as you can
imagine. So from the application maintainer perspective, I'd like to see
the libs as isolated as possible, so that I can essentially treat them as a
blackbox (same as Qt / KDE frameworks). I don't know how feasible that is,
as we rely on flake for embeddability, but improvements in this area would
be quite appreciated, if they are possible.

/ Tomas


2015-08-29 10:24 GMT+02:00 Camilla Boemann c...@boemann.dk:

 As much as I dislike forking I must admit it makes more sense than
 splitting the libraries.

 1) there are conflicting or at list disjoint interests between krita and
 office. I am not complaining - it's just a fact. Forking will allow
 specialization - splitting will just produce arguing
 2) by splitting it would fall on app maintainers to cleanup - uhm so I
 would have to spend hours to clean up for krita-needed-changes and vice
 versa, with no obligation from opposite part to make sure suc changes makes
 sense or are even possible to adapt to ?
 3) the responsibility could possibly right now fall on the committer but
 let's not kid ourselves - that will change rapidly because it will mean
 that committers will still have to checkout all repos, making any benefit
 void.
 4) the communities are already rather disjoint - few are present in both
 irc channels or help out in each other's code

 On the other hand - the time together has been good or us all but I think
 the time has come to fork - I have no issue if krita wants to stay in the
 Calligra suite but even there their main pr and communication have already
 been split up years ago

 So I suggest:
 Krita.git
 Calligra.git (without author, braindump, karbon, krita and kexi - so just
 words, stage, sheets and flow, libs , filters and plugins)
 Kexi.git

 Kexi are free to depend on Calligra.git, but even for kexi I have my
 doubts if it wouldn't be better to fork

 Now I realize this might be the death of the office apps if we have no one
 left to do website maintainance, releases and general work. I  will do my
 part but I can't do everything. So if no one is prepared to stay and do
 releases etc then it still might be better to do the spltting ( but is that
 a guarantee things will be released or will krita/kexi eventually split up
 or do their own releases anyway. In which case Calligra will be split and
 no one to do the even larger release process.

 If enough people are still interested in the office apps so that we can
 continue to release then I think forking is the best thing - if not I  can
 only hope splitting libs will not produce the same fate

 Best regards
 Camilla Boemann

 -Original Message-
 From: calligra-devel [mailto:calligra-devel-boun...@kde.org] On Behalf Of
 Boudewijn Rempt
 Sent: 29. august 2015 09:38
 To: Calligra Suite developers and users mailing list 
 calligra-devel@kde.org
 Subject: Re: After 2.9.7

 On Sat, 29 Aug 2015, Cyrille Berger wrote:

  On Friday 28 August 2015 15:43:12 Boudewijn Rempt wrote:
  Well, we started the discussion with the idea that making separate
  repos for the libraries and applications was going to be useful. That
  rather soon turned into a discussion of the problems we have making
  our libraries fit for purpose for all applications, and that turned
  into why should, e.g., words and the libraries be in a separate
  repo, it's only a lot of hassle.
 
  And that's where the discussion stopped, so I wrote this mail to
  re-engage the discussion.
 
  I think the problems raised during that discussion were more:
 
  1) How to keep the repositories in sync?
  2) Who will fix breakage in applications?
 
  I think Friedrich email from yesterday gives a reasonably good
  solution for 1).
 
  As for 2), the biggest problem is for unmaintained applications. But
  there, I think we have to take the hard decision of simply killing
  those applications, and keep the focus on applications that have
  people who care about them. And then, for small changes, it is up to
 maintainers to adjust their applications.
  Bigger changes should be more coordinated.

 I am fine with either solution. If splitting off koofdf, kostore and other
 libraries into frameworks means we can continue sharing them, that would
 be good

Re: After 2.9.7

[Jaroslaw Staniek]

 recommended). That's a kind of rule that we have for kf5
libs and calligralibs members.

Re releases: I hope for combined Calligra-branded releases, at least
as many as we can, containing as many stuff as we can have together.
Consistent versioning. This should not suddenly change just because
there are more repos. And if a repo foo.git is not
API/ABI/stability-ready for a stable release, mark it as such, but it
still can be separate, and it would be a release for our
work-in-progress. New release can potentially increase major numbers
quickly. Why? Because by the time of a new
API/ABI/feature-incompatible release someone might start to use
previous version of your lib.

PS (not quite on topic):
Re other apps. Boud explained the case with Karbon.
Let me look at Calligra Plan (disclaimer, I am not a user): I am sure
it's used in real world. I just was happy to hear some of Calligra
developers used it for some projects.
But I see a strategy problem here as a challenge. Sure, development of
Plan/KPlato started in almost pre-Internet times but let's state it --
now even we, KDE folks don't suggest to promote Plan as a PM tool for
our own work here.  Almost everything like that tool is web-based now
-- not just the UI but the workflow is less MS Project-like, that's
what I call web-based here. We never even had proposal of having a
native bug/task tracking app for KDE development, this says something
to me.

 2015-08-29 10:24 GMT+02:00 Camilla Boemann c...@boemann.dk:

 As much as I dislike forking I must admit it makes more sense than
 splitting the libraries.

 1) there are conflicting or at list disjoint interests between krita and
 office. I am not complaining - it's just a fact. Forking will allow
 specialization - splitting will just produce arguing
 2) by splitting it would fall on app maintainers to cleanup - uhm so I
 would have to spend hours to clean up for krita-needed-changes and vice
 versa, with no obligation from opposite part to make sure suc changes makes
 sense or are even possible to adapt to ?
 3) the responsibility could possibly right now fall on the committer but
 let's not kid ourselves - that will change rapidly because it will mean that
 committers will still have to checkout all repos, making any benefit void.
 4) the communities are already rather disjoint - few are present in both
 irc channels or help out in each other's code

 On the other hand - the time together has been good or us all but I think
 the time has come to fork - I have no issue if krita wants to stay in the
 Calligra suite but even there their main pr and communication have already
 been split up years ago

 So I suggest:
 Krita.git
 Calligra.git (without author, braindump, karbon, krita and kexi - so just
 words, stage, sheets and flow, libs , filters and plugins)
 Kexi.git

 Kexi are free to depend on Calligra.git, but even for kexi I have my
 doubts if it wouldn't be better to fork

 Now I realize this might be the death of the office apps if we have no one
 left to do website maintainance, releases and general work. I  will do my
 part but I can't do everything. So if no one is prepared to stay and do
 releases etc then it still might be better to do the spltting ( but is that
 a guarantee things will be released or will krita/kexi eventually split up
 or do their own releases anyway. In which case Calligra will be split and no
 one to do the even larger release process.

 If enough people are still interested in the office apps so that we can
 continue to release then I think forking is the best thing - if not I  can
 only hope splitting libs will not produce the same fate

 Best regards
 Camilla Boemann

 -Original Message-
 From: calligra-devel [mailto:calligra-devel-boun...@kde.org] On Behalf Of
 Boudewijn Rempt
 Sent: 29. august 2015 09:38
 To: Calligra Suite developers and users mailing list
 calligra-devel@kde.org
 Subject: Re: After 2.9.7

 On Sat, 29 Aug 2015, Cyrille Berger wrote:

  On Friday 28 August 2015 15:43:12 Boudewijn Rempt wrote:
  Well, we started the discussion with the idea that making separate
  repos for the libraries and applications was going to be useful. That
  rather soon turned into a discussion of the problems we have making
  our libraries fit for purpose for all applications, and that turned
  into why should, e.g., words and the libraries be in a separate
  repo, it's only a lot of hassle.
 
  And that's where the discussion stopped, so I wrote this mail to
  re-engage the discussion.
 
  I think the problems raised during that discussion were more:
 
  1) How to keep the repositories in sync?
  2) Who will fix breakage in applications?
 
  I think Friedrich email from yesterday gives a reasonably good
  solution for 1).
 
  As for 2), the biggest problem is for unmaintained applications. But
  there, I think we have to take the hard decision of simply killing
  those applications, and keep the focus on applications that have
  people who care about them

Re: Schedule to switch back to master for feature development (was: Re: After 2.9.7)

[Jaroslaw Staniek]

On 27 August 2015 at 16:27, Friedrich W. H. Kossebau kosse...@kde.org wrote:
 Am Donnerstag, 27. August 2015, 09:57:32 schrieb Boudewijn Rempt:
 I'm not really happy writing this mail... But anyway, back to practical
 issues. I'd like to start taking steps next week already.

 * split up our git repo whichever we we like
 * ask sysadmin to put our repos up
 * update all the build documentation on community.kde.org to talk
 about kf5 and the new repo locations
 * update the information on our websites (not forgetting kde.org)
 * ping David Revoy about updating his build guide
 * figure out the release process after the split?

 And then start hacking... Thoughts? Flames?

 I fear splitting git repos, unless done brutally, will take some time to be
 well prepared (and also needs an agreement who to do it of all involved). So
 hoping to do that already next week might be ambitious :)

 Unless you are talking here about the option of forking off Krita + shared
 libs into a repo of its own, then of course just that Krita subcommunity needs
 to agree.
 Still, not sure how wild the repo history is and how complicated it will be to
 find the correct filter-branch rules, I assume that needs more than a few
 hours, including all the test builds.
 Jarosław, what amount of work do you assume here based on your experience with
 forking out kdb, kreport and kproperty?

I cut off-things one by one. I was acting like a surgeon there :)
By the way I even cleaned up my commit names/emails :)
Final cleanup can be done once commits land in given destination repo,
especially because filters are slow on entire calligra.git.

One note is that renames are the biggest challenge. I personally
wanted entire history for kdb.git; existence of the
kexidb-calligradb-predicate-kdb history means that we had like 5
location of files.

 So we need some volunteers who dig into the needed filter-branch rules (guess
 for Krita Boud is already on that). Myself has no experience and is not really
 motivated yet for it. :(

I can help with that. Good that Kexi was in kexi/ all the time. Same for krita/.
Ping me.

 In the meantime for everyone I would propose to turn Boud's other proposal
 about turning frameworks into master and open it back for development in this
 schedule:

 * before Aug 29th/tagging of 2.9.7: merge frameworks into master
   (volunteers? I could do that, at least help,
   including updates to kde-build-metadata and requesting CI adaption)
 * Aug 29th/tagging of 2.9.7: last merge of 2.9 into master
 * after that:
   2.9 only bugfixes, no more features
   master unfrozen, so open for features and porting from kdelibs4support

 Does that work for everyone?

 Now, I would also love to see Kexi's framework branch finally finally merged
 back into master.

Green light? I hope to do so before Monday noon.

  Just, there is still the unsolved problem how to officially
 deal with the no longer by-repo-given atomicity of API changes in libs and
 libconsumers, given that kdb, kreport and kproperty are now external, but
 still developed in sync with their consumers.
 But separate email thread for that please (writing one next), orthogonal
 problem to this schedule IMHO.

Yes, we'd document best practices.

-- 
regards, Jaroslaw Staniek

KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org
Calligra Suite:
: A graphic art and office suite - http://calligra.org
Kexi:
: A visual database apps builder - http://calligra.org/kexi
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: 2.9.7

[Jaroslaw Staniek]

Thanks,
@Maintainers
Before end of Monday please send me changelogs for the release
announcement. Thanks.

On 26 August 2015 at 10:22, Cyrille Berger cber...@cberger.net wrote:
 On 2015-08-25 14:10, Jaroslaw Staniek wrote:

 So I am assuming this as OK.
 @Cyrille are you available?
 This is rather a deadline for me to push a fix for defective 2.9.5/6 Kexi.


 Hopefully.

 --
 Cyrille Berger Skott



-- 
regards, Jaroslaw Staniek

KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org
Calligra Suite:
: A graphic art and office suite - http://calligra.org
Kexi:
: A visual database apps builder - http://calligra.org/kexi
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Schedule to switch back to master for feature development (was: Re: After 2.9.7)

[Cyrille Berger]

On Thursday 27 August 2015 16:27:21 Friedrich W. H. Kossebau wrote:
 I fear splitting git repos, unless done brutally, will take some time to be 
 well prepared (and also needs an agreement who to do it of all involved).
 So hoping to do that already next week might be ambitious
Also, lets not forget to coordinate the split with translation teams.
-- 
Cyrille Berger Skott
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

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

[Friedrich W. H. Kossebau]

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 

Re: Schedule to switch back to master for feature development (was: Re: After 2.9.7)

[Boudewijn Rempt]

On Thu, 27 Aug 2015, Friedrich W. H. Kossebau wrote:

I fear splitting git repos, unless done brutally, will take some time to be 
well prepared (and also needs an agreement who to do it of all involved). So 
hoping to do that already next week might be ambitious :)


Well, sure. But postponing it until we get some sort of consensus might not
work either, because it's awfully quiet. What sort of future development plan
is there for words, sheets, stage, plan, kexi? Yue has said he wanted to redo
flow based on Karbon, which is always an option, of course, but that needs
activity. Well, everything needs activity to happen.

Unless you are talking here about the option of forking off Krita + shared 
libs into a repo of its own, then of course just that Krita subcommunity needs 
to agree.
Still, not sure how wild the repo history is and how complicated it will be to 
find the correct filter-branch rules, I assume that needs more than a few 
hours, including all the test builds.


That's something I wanted to start investigating next week.

Jarosław, what amount of work do you assume here based on your experience with 
forking out kdb, kreport and kproperty?


So we need some volunteers who dig into the needed filter-branch rules (guess 
for Krita Boud is already on that). Myself has no experience and is not really 
motivated yet for it. :(


In the meantime for everyone I would propose to turn Boud's other proposal 
about turning frameworks into master and open it back for development in this 
schedule:


* before Aug 29th/tagging of 2.9.7: merge frameworks into master
 (volunteers? I could do that, at least help,
 including updates to kde-build-metadata and requesting CI adaption)


That would be great.


* Aug 29th/tagging of 2.9.7: last merge of 2.9 into master


I can do that.


* after that:
 2.9 only bugfixes, no more features
 master unfrozen, so open for features and porting from kdelibs4support


I also would like to cleanup the coding style, still...


Does that work for everyone?

Now, I would also love to see Kexi's framework branch finally finally merged 
back into master. Just, there is still the unsolved problem how to officially 
deal with the no longer by-repo-given atomicity of API changes in libs and 
libconsumers, given that kdb, kreport and kproperty are now external, but 
still developed in sync with their consumers.
But separate email thread for that please (writing one next), orthogonal 
problem to this schedule IMHO.


Cheers
Friedrich
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: After 2.9.7

[Cyrille Berger]

On 2015-08-27 09:57, Boudewijn Rempt wrote:

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.


So basically, splitting up krita from calligra? Or did I misunderstood 
something?


--
Cyrille Berger Skott
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: After 2.9.7

[Boudewijn Rempt]

On Fri, 28 Aug 2015, Cyrille Berger wrote:


On 2015-08-27 09:57, Boudewijn Rempt wrote:

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.


So basically, splitting up krita from calligra? Or did I misunderstood 
something?




Well, we started the discussion with the idea that making separate repos
for the libraries and applications was going to be useful. That rather 
soon turned into a discussion of the problems we have making our libraries

fit for purpose for all applications, and that turned into why should,
e.g., words and the libraries be in a separate repo, it's only a lot of 
hassle.


And that's where the discussion stopped, so I wrote this mail to re-engage
the discussion.

Boudewijn
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Schedule to switch back to master for feature development (was: Re: After 2.9.7)

[Friedrich W. H. Kossebau]

Am Freitag, 28. August 2015, 15:48:39 schrieb Boudewijn Rempt:
 On Thu, 27 Aug 2015, Friedrich W. H. Kossebau wrote:
  In the meantime for everyone I would propose to turn Boud's other proposal
  about turning frameworks into master and open it back for development in
  this schedule:
  
  * before Aug 29th/tagging of 2.9.7: merge frameworks into master
  
   (volunteers? I could do that, at least help,
   including updates to kde-build-metadata and requesting CI adaption)
 
 That would be great.

Okay, will do that then. Already contacted Scarlett about that.
Expect the merge to happen on Saturday 29th, around early afternoon CET. Will 
send a separate warning email to all mailing lists, for people only reading 
email subjects due to too much traffic.
 
  * Aug 29th/tagging of 2.9.7: last merge of 2.9 into master
 
 I can do that.

Okay, task for you then :)

Cheers
Friedrich

___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Schedule to switch back to master for feature development (was: Re: After 2.9.7)

[Friedrich W. H. Kossebau]

Am Donnerstag, 27. August 2015, 09:57:32 schrieb Boudewijn Rempt:
 I'm not really happy writing this mail... But anyway, back to practical
 issues. I'd like to start taking steps next week already.
 
 * split up our git repo whichever we we like
 * ask sysadmin to put our repos up
 * update all the build documentation on community.kde.org to talk
 about kf5 and the new repo locations
 * update the information on our websites (not forgetting kde.org)
 * ping David Revoy about updating his build guide
 * figure out the release process after the split?
 
 And then start hacking... Thoughts? Flames?

I fear splitting git repos, unless done brutally, will take some time to be 
well prepared (and also needs an agreement who to do it of all involved). So 
hoping to do that already next week might be ambitious :)

Unless you are talking here about the option of forking off Krita + shared 
libs into a repo of its own, then of course just that Krita subcommunity needs 
to agree.
Still, not sure how wild the repo history is and how complicated it will be to 
find the correct filter-branch rules, I assume that needs more than a few 
hours, including all the test builds.
Jarosław, what amount of work do you assume here based on your experience with 
forking out kdb, kreport and kproperty?

So we need some volunteers who dig into the needed filter-branch rules (guess 
for Krita Boud is already on that). Myself has no experience and is not really 
motivated yet for it. :(

In the meantime for everyone I would propose to turn Boud's other proposal 
about turning frameworks into master and open it back for development in this 
schedule:

* before Aug 29th/tagging of 2.9.7: merge frameworks into master
  (volunteers? I could do that, at least help,
  including updates to kde-build-metadata and requesting CI adaption)
* Aug 29th/tagging of 2.9.7: last merge of 2.9 into master
* after that:
  2.9 only bugfixes, no more features
  master unfrozen, so open for features and porting from kdelibs4support

Does that work for everyone?

Now, I would also love to see Kexi's framework branch finally finally merged 
back into master. Just, there is still the unsolved problem how to officially 
deal with the no longer by-repo-given atomicity of API changes in libs and 
libconsumers, given that kdb, kreport and kproperty are now external, but 
still developed in sync with their consumers.
But separate email thread for that please (writing one next), orthogonal 
problem to this schedule IMHO.

Cheers
Friedrich
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Let's use 3.0 only for next real release (was: Re: After 2.9.7)

[Friedrich W. H. Kossebau]

Am Donnerstag, 27. August 2015, 14:27:17 schrieb Boudewijn Rempt:
 On Thu, 27 Aug 2015, Friedrich W. H. Kossebau wrote:
  Hi,
  
  Am Donnerstag, 27. August 2015, 09:57:32 schrieb Boudewijn Rempt:
  I think that the frameworks branch is now ready to be called 3.0. It's
  obviously not ready to release to end users, but we should make it the
  new master. But let's call it the frameworks branch for now.
  
  +1 for making frameworks master now :)
  
  Proposal:
  Let's change and not (ab)use the 3.0 version label for the current
  development milestone in the frameworks branch where initial port could be
  declared done-with-no-big-regressions, and thus also not do the first
  release as 3.1.
  Let's instead use the 3.0 version for the first release. And simply keep
  the current 3.0 Alpha tag on the frameworks branch.
  
  Not need to dump 3.0 in interface to public and waste time/space in the
  release notes, chats and interviews/articles on where 3.0 is and why 3.0
  was skipped, where instead features could and should be highlighted :)
  Unless anyone can tell if there could be a great promotion spin done out
  of that? ;)
  
  Internally we have been talking about 3.0 as
  switch-feature-development-to-
  frameworks milestone and 3.1 as first-qt5-based release, but well, we are
  smart contributors and can quickly adapt tag labels, right? :)
  
  Objections?
 
 Not for me, but though I was just using the terminology we'd decided on at
 the start of the porting, I don't switching away from it :-)

*mind I assume?

Yes, terminology made sense for the inital plans (which included release of 
3.0) and also was understood by everyone :)
But now that we decided to not release that milestone, IMHO we better adapt 
also the terminology (as it has semantics if used also for communication with 
public).

Cheers
Friedrich
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Let's use 3.0 only for next real release (was: Re: After 2.9.7)

[Boudewijn Rempt]

On Thu, 27 Aug 2015, Friedrich W. H. Kossebau wrote:


Hi,

Am Donnerstag, 27. August 2015, 09:57:32 schrieb Boudewijn Rempt:

I think that the frameworks branch is now ready to be called 3.0. It's
obviously not ready to release to end users, but we should make it the
new master. But let's call it the frameworks branch for now.


+1 for making frameworks master now :)

Proposal:
Let's change and not (ab)use the 3.0 version label for the current 
development milestone in the frameworks branch where initial port could be 
declared done-with-no-big-regressions, and thus also not do the first release 
as 3.1.
Let's instead use the 3.0 version for the first release. And simply keep the 
current 3.0 Alpha tag on the frameworks branch.


Not need to dump 3.0 in interface to public and waste time/space in the 
release notes, chats and interviews/articles on where 3.0 is and why 3.0 was 
skipped, where instead features could and should be highlighted :)
Unless anyone can tell if there could be a great promotion spin done out of 
that? ;)


Internally we have been talking about 3.0 as switch-feature-development-to-
frameworks milestone and 3.1 as first-qt5-based release, but well, we are 
smart contributors and can quickly adapt tag labels, right? :)


Objections?


Not for me, but though I was just using the terminology we'd decided on at the 
start of the porting, I don't switching away from it :-)


Boudewijn
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Let's use 3.0 only for next real release (was: Re: After 2.9.7)

[C. Boemann]

+ 1

On Thursday 27 August 2015 14:22:19 Friedrich W. H. Kossebau wrote:
 Hi,
 
 Am Donnerstag, 27. August 2015, 09:57:32 schrieb Boudewijn Rempt:
  I think that the frameworks branch is now ready to be called 3.0. It's
  obviously not ready to release to end users, but we should make it the
  new master. But let's call it the frameworks branch for now.
 
 +1 for making frameworks master now :)
 
 Proposal:
 Let's change and not (ab)use the 3.0 version label for the current
 development milestone in the frameworks branch where initial port could be
 declared done-with-no-big-regressions, and thus also not do the first
 release as 3.1.
 Let's instead use the 3.0 version for the first release. And simply keep
 the current 3.0 Alpha tag on the frameworks branch.
 
 Not need to dump 3.0 in interface to public and waste time/space in the
 release notes, chats and interviews/articles on where 3.0 is and why 3.0 was
 skipped, where instead features could and should be highlighted :) Unless
 anyone can tell if there could be a great promotion spin done out of that?
 ;)
 
 Internally we have been talking about 3.0 as switch-feature-development-to-
 frameworks milestone and 3.1 as first-qt5-based release, but well, we are
 smart contributors and can quickly adapt tag labels, right? :)
 
 Objections?
 
 Cheers
 Friedrich
 ___
 calligra-devel mailing list
 calligra-devel@kde.org
 https://mail.kde.org/mailman/listinfo/calligra-devel

___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

After 2.9.7

[Boudewijn Rempt]

Hi,

We had a long discussion on #calligra yesterday, but I don't know whether
we came to any conclusion... There are a bunch of things we have to
consider before moving on after 2.9.7.

I think that the frameworks branch is now ready to be called 3.0. It's
obviously not ready to release to end users, but we should make it the
new master. But let's call it the frameworks branch for now.

I propose that we move all feature development (magnetic selection
tool, animation, LOD) to the frameworks branch or a branch branched off
frameworks at this point. From that point on, only bug fixes should
go into 2.9, and each bug fix should be individually forward-ported
to frameworks

The bigger question is, what are we going to do with the frameworks
branch itself and with our git repo, and with our community?

This is really hard for me, personally, to formulate, but the truth is,
now that I am sponsored to work on Krita, I cannot afford to spend time
on the rest of calligra if that doesn't directly benefit Krita. I cannot
refactor something in the libraries and then port sheets, because I feel
that would be a misuse of the money the community has donated.

With the merging of the mvc branch, I already ran into that, and found 
that I just couldn't find the hours of the day to work on sheets, stage

and the rest. And apparently, nobody else could find the time.

For the frameworks branch, I do want to do a big cleanup. I want to make
building krita much easier, and that means cutting down on dependencies,
cutting down on code in libraries that krita doesn't need. On the other
hand, if I were the words maintainer, I would like to get rid of stuff
that words doesn't need, like pigment.

Originally, I envisaged our split up repo like:

calligra-libs 
calligra-apps

calligra-plugins
krita
kexi

Or even split up calligra-libs into a set of repos: that would help with
the dependency graph in Linux distributions, where they now make marble
and mysql dependencies of Krita...

But in the discussion yesterday, I think we came to a sort of tentative
conclusion that it doesn't make sense to push all our libraries into
separate repositories, and that it even doesn't make sense to create a
separate calligra-libs.git that could be used by the applications.

I am not sure how much of the calligra libs are used by Kexi, and whether
sharing the same libraries between Kexi and the office applications makes
sense. Should kexi go into its own repo?

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.

I'm not really happy writing this mail... But anyway, back to practical 
issues. I'd like to start taking steps next week already.


* split up our git repo whichever we we like
* ask sysadmin to put our repos up
* update all the build documentation on community.kde.org to talk
about kf5 and the new repo locations
* update the information on our websites (not forgetting kde.org)
* ping David Revoy about updating his build guide
* figure out the release process after the split?

And then start hacking... Thoughts? Flames?

Boudewijn
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Let's use 3.0 only for next real release (was: Re: After 2.9.7)

[Friedrich W. H. Kossebau]

Hi,

Am Donnerstag, 27. August 2015, 09:57:32 schrieb Boudewijn Rempt:
 I think that the frameworks branch is now ready to be called 3.0. It's
 obviously not ready to release to end users, but we should make it the
 new master. But let's call it the frameworks branch for now.

+1 for making frameworks master now :)

Proposal:
Let's change and not (ab)use the 3.0 version label for the current 
development milestone in the frameworks branch where initial port could be 
declared done-with-no-big-regressions, and thus also not do the first release 
as 3.1.
Let's instead use the 3.0 version for the first release. And simply keep the 
current 3.0 Alpha tag on the frameworks branch.

Not need to dump 3.0 in interface to public and waste time/space in the 
release notes, chats and interviews/articles on where 3.0 is and why 3.0 was 
skipped, where instead features could and should be highlighted :)
Unless anyone can tell if there could be a great promotion spin done out of 
that? ;)

Internally we have been talking about 3.0 as switch-feature-development-to-
frameworks milestone and 3.1 as first-qt5-based release, but well, we are 
smart contributors and can quickly adapt tag labels, right? :)

Objections?

Cheers
Friedrich
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: 2.9.7

[Cyrille Berger]

On 2015-08-25 14:10, Jaroslaw Staniek wrote:

So I am assuming this as OK.
@Cyrille are you available?
This is rather a deadline for me to push a fix for defective 2.9.5/6 
Kexi.


Hopefully.

--
Cyrille Berger Skott
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: 2.9.7

[Jaroslaw Staniek]

On 24 August 2015 at 09:59, Boudewijn Rempt b...@valdyas.org wrote:
 On Mon, 24 Aug 2015, Jaroslaw Staniek wrote:

 Hi,
 Reminder:

 Tagging August 29th
 Release September 2nd


 Are you ready?


 Still some days left to fix bugs!

So I am assuming this as OK.
@Cyrille are you available?
This is rather a deadline for me to push a fix for defective 2.9.5/6 Kexi.




-- 
regards, Jaroslaw Staniek

KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org
Calligra Suite:
: A graphic art and office suite - http://calligra.org
Kexi:
: A visual database apps builder - http://calligra.org/kexi
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: 2.9.7

[Jaroslaw Staniek]

Hi,
Reminder:

 Tagging August 29th
 Release September 2nd

Are you ready?

https://community.kde.org/Calligra/Schedules/2.9/Release_Plan#2.9.7


 https://community.kde.org/Calligra/Schedules/2.9/Release_Plan#2.9.7



 On 6 August 2015 at 16:04, Boudewijn Rempt b...@valdyas.org wrote:

 After some back and forth, I want to propose to to skip the august release, 
 and do 2.9.7 september 1st.


 On Thu, 6 Aug 2015, Boudewijn Rempt wrote:

 Hm... I'm back now from almost a month of non-coding because of Plasma 
 Phone, LA trip, broken arm, vacation, akademy... And I'm not really happy 
 to release a new 2.9 right now. For some reason, we've got a host of 
 regressions right now :-(

 Boudewijn

 On Tue, 4 Aug 2015, Jaroslaw Staniek wrote:

 On 4 August 2015 at 10:02, Dmitry Kazakov dimul...@gmail.com wrote:

 Hi, Jaroslaw!

 Boud is still on the vacation and should be back today/tomorrow, so Krita
 cannot do Windows builds atm. How about moving a release to the weekend?

 E.g.

 - Tagging August 7th
 - Release August 12th


 OK from me, can we have changelogs earlier?

 On Tue, Aug 4, 2015 at 10:23 AM, Jaroslaw Staniek stan...@kde.org wrote:


 Hi,
 Are you ready to tag 2.9.7 ? Any blockers? Do you have code to release?

 I have a fix for Kexi to release so from this POV releasing ASAP is
 preferred.

 @Cyrille are you available these days?

 The original plan was:

 - Tagging August 1st
 - Release August 5th

 --
 regards, Jaroslaw Staniek

 KDE:
 : A world-wide network of software engineers, artists, writers,
 translators
 : and facilitators committed to Free Software development -

 http://kde.org

 Calligra Suite:
 : A graphic art and office suite - http://calligra.org
 Kexi:
 : A visual database apps builder - http://calligra.org/kexi
 Qt Certified Specialist:
 : http://www.linkedin.com/in/jstaniek
 ___
 calligra-devel mailing list
 calligra-devel@kde.org
 https://mail.kde.org/mailman/listinfo/calligra-devel





 --
 Dmitry Kazakov

 ___
 calligra-devel mailing list
 calligra-devel@kde.org
 https://mail.kde.org/mailman/listinfo/calligra-devel




 --
 regards, Jaroslaw Staniek

 KDE:
 : A world-wide network of software engineers, artists, writers, translators
 : and facilitators committed to Free Software development - http://kde.org
 Calligra Suite:
 : A graphic art and office suite - http://calligra.org
 Kexi:
 : A visual database apps builder - http://calligra.org/kexi
 Qt Certified Specialist:
 : http://www.linkedin.com/in/jstaniek
 ___
 calligra-devel mailing list
 calligra-devel@kde.org
 https://mail.kde.org/mailman/listinfo/calligra-devel

 ___
 calligra-devel mailing list
 calligra-devel@kde.org
 https://mail.kde.org/mailman/listinfo/calligra-devel

 ___
 calligra-devel mailing list
 calligra-devel@kde.org
 https://mail.kde.org/mailman/listinfo/calligra-devel




 --
 regards, Jaroslaw Staniek

 KDE:
 : A world-wide network of software engineers, artists, writers, translators
 : and facilitators committed to Free Software development - http://kde.org
 Calligra Suite:
 : A graphic art and office suite - http://calligra.org
 Kexi:
 : A visual database apps builder - http://calligra.org/kexi
 Qt Certified Specialist:
 : http://www.linkedin.com/in/jstaniek




-- 
regards, Jaroslaw Staniek

KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org
Calligra Suite:
: A graphic art and office suite - http://calligra.org
Kexi:
: A visual database apps builder - http://calligra.org/kexi
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: 2.9.7

[Boudewijn Rempt]

On Mon, 24 Aug 2015, Jaroslaw Staniek wrote:


Hi,
Reminder:


Tagging August 29th
Release September 2nd


Are you ready?


Still some days left to fix bugs!

Boudewijn



https://community.kde.org/Calligra/Schedules/2.9/Release_Plan#2.9.7



https://community.kde.org/Calligra/Schedules/2.9/Release_Plan#2.9.7



On 6 August 2015 at 16:04, Boudewijn Rempt b...@valdyas.org wrote:


After some back and forth, I want to propose to to skip the august release, and 
do 2.9.7 september 1st.


On Thu, 6 Aug 2015, Boudewijn Rempt wrote:


Hm... I'm back now from almost a month of non-coding because of Plasma Phone, 
LA trip, broken arm, vacation, akademy... And I'm not really happy to release a 
new 2.9 right now. For some reason, we've got a host of regressions right now 
:-(

Boudewijn

On Tue, 4 Aug 2015, Jaroslaw Staniek wrote:


On 4 August 2015 at 10:02, Dmitry Kazakov dimul...@gmail.com wrote:


Hi, Jaroslaw!

Boud is still on the vacation and should be back today/tomorrow, so Krita
cannot do Windows builds atm. How about moving a release to the weekend?

E.g.

- Tagging August 7th
- Release August 12th



OK from me, can we have changelogs earlier?


On Tue, Aug 4, 2015 at 10:23 AM, Jaroslaw Staniek stan...@kde.org wrote:



Hi,
Are you ready to tag 2.9.7 ? Any blockers? Do you have code to release?

I have a fix for Kexi to release so from this POV releasing ASAP is
preferred.

@Cyrille are you available these days?

The original plan was:

- Tagging August 1st
- Release August 5th

--
regards, Jaroslaw Staniek

KDE:
: A world-wide network of software engineers, artists, writers,
translators
: and facilitators committed to Free Software development -


http://kde.org


Calligra Suite:
: A graphic art and office suite - http://calligra.org
Kexi:
: A visual database apps builder - http://calligra.org/kexi
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel






--
Dmitry Kazakov

___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel





--
regards, Jaroslaw Staniek

KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org
Calligra Suite:
: A graphic art and office suite - http://calligra.org
Kexi:
: A visual database apps builder - http://calligra.org/kexi
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel


___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel


___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel





--
regards, Jaroslaw Staniek

KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org
Calligra Suite:
: A graphic art and office suite - http://calligra.org
Kexi:
: A visual database apps builder - http://calligra.org/kexi
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek





--
regards, Jaroslaw Staniek

KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org
Calligra Suite:
: A graphic art and office suite - http://calligra.org
Kexi:
: A visual database apps builder - http://calligra.org/kexi
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: 2.9.7

[Boudewijn Rempt]

After some back and forth, I want to propose to to skip the august 
release, and do 2.9.7 september 1st.


On Thu, 6 Aug 2015, Boudewijn Rempt wrote:

Hm... I'm back now from almost a month of non-coding because of Plasma 
Phone, LA trip, broken arm, vacation, akademy... And I'm not really happy 
to release a new 2.9 right now. For some reason, we've got a host of 
regressions right now :-(


Boudewijn

On Tue, 4 Aug 2015, Jaroslaw Staniek wrote:


On 4 August 2015 at 10:02, Dmitry Kazakov dimul...@gmail.com wrote:

Hi, Jaroslaw!

Boud is still on the vacation and should be back today/tomorrow, so Krita
cannot do Windows builds atm. How about moving a release to the weekend?

E.g.

- Tagging August 7th
- Release August 12th


OK from me, can we have changelogs earlier?


On Tue, Aug 4, 2015 at 10:23 AM, Jaroslaw Staniek stan...@kde.org wrote:


Hi,
Are you ready to tag 2.9.7 ? Any blockers? Do you have code to release?

I have a fix for Kexi to release so from this POV releasing ASAP is
preferred.

@Cyrille are you available these days?

The original plan was:

- Tagging August 1st
- Release August 5th

--
regards, Jaroslaw Staniek

KDE:
: A world-wide network of software engineers, artists, writers,
translators
: and facilitators committed to Free Software development - 

http://kde.org

Calligra Suite:
: A graphic art and office suite - http://calligra.org
Kexi:
: A visual database apps builder - http://calligra.org/kexi
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel





--
Dmitry Kazakov

___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel





--
regards, Jaroslaw Staniek

KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org
Calligra Suite:
: A graphic art and office suite - http://calligra.org
Kexi:
: A visual database apps builder - http://calligra.org/kexi
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel


___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: 2.9.7

[Boudewijn Rempt]

Hm... I'm back now from almost a month of non-coding because of Plasma 
Phone, LA trip, broken arm, vacation, akademy... And I'm not really happy 
to release a new 2.9 right now. For some reason, we've got a host of 
regressions right now :-(


Boudewijn

On Tue, 4 Aug 2015, Jaroslaw Staniek wrote:


On 4 August 2015 at 10:02, Dmitry Kazakov dimul...@gmail.com wrote:

Hi, Jaroslaw!

Boud is still on the vacation and should be back today/tomorrow, so Krita
cannot do Windows builds atm. How about moving a release to the weekend?

E.g.

- Tagging August 7th
- Release August 12th


OK from me, can we have changelogs earlier?


On Tue, Aug 4, 2015 at 10:23 AM, Jaroslaw Staniek stan...@kde.org wrote:


Hi,
Are you ready to tag 2.9.7 ? Any blockers? Do you have code to release?

I have a fix for Kexi to release so from this POV releasing ASAP is
preferred.

@Cyrille are you available these days?

The original plan was:

- Tagging August 1st
- Release August 5th

--
regards, Jaroslaw Staniek

KDE:
: A world-wide network of software engineers, artists, writers,
translators
: and facilitators committed to Free Software development - http://kde.org
Calligra Suite:
: A graphic art and office suite - http://calligra.org
Kexi:
: A visual database apps builder - http://calligra.org/kexi
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel





--
Dmitry Kazakov

___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel





--
regards, Jaroslaw Staniek

KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org
Calligra Suite:
: A graphic art and office suite - http://calligra.org
Kexi:
: A visual database apps builder - http://calligra.org/kexi
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

2.9.7

[Jaroslaw Staniek]

Hi,
Are you ready to tag 2.9.7 ? Any blockers? Do you have code to release?

I have a fix for Kexi to release so from this POV releasing ASAP is preferred.

@Cyrille are you available these days?

The original plan was:

- Tagging August 1st
- Release August 5th

-- 
regards, Jaroslaw Staniek

KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org
Calligra Suite:
: A graphic art and office suite - http://calligra.org
Kexi:
: A visual database apps builder - http://calligra.org/kexi
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: 2.9.7

[Dmitry Kazakov]

Hi, Jaroslaw!

Boud is still on the vacation and should be back today/tomorrow, so Krita
cannot do Windows builds atm. How about moving a release to the weekend?

E.g.

- Tagging August 7th
- Release August 12th



On Tue, Aug 4, 2015 at 10:23 AM, Jaroslaw Staniek stan...@kde.org wrote:

 Hi,
 Are you ready to tag 2.9.7 ? Any blockers? Do you have code to release?

 I have a fix for Kexi to release so from this POV releasing ASAP is
 preferred.

 @Cyrille are you available these days?

 The original plan was:

 - Tagging August 1st
 - Release August 5th

 --
 regards, Jaroslaw Staniek

 KDE:
 : A world-wide network of software engineers, artists, writers, translators
 : and facilitators committed to Free Software development - http://kde.org
 Calligra Suite:
 : A graphic art and office suite - http://calligra.org
 Kexi:
 : A visual database apps builder - http://calligra.org/kexi
 Qt Certified Specialist:
 : http://www.linkedin.com/in/jstaniek
 ___
 calligra-devel mailing list
 calligra-devel@kde.org
 https://mail.kde.org/mailman/listinfo/calligra-devel




-- 
Dmitry Kazakov
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: 2.9.7

[Jaroslaw Staniek]

On 4 August 2015 at 10:02, Dmitry Kazakov dimul...@gmail.com wrote:
 Hi, Jaroslaw!

 Boud is still on the vacation and should be back today/tomorrow, so Krita
 cannot do Windows builds atm. How about moving a release to the weekend?

 E.g.

 - Tagging August 7th
 - Release August 12th

OK from me, can we have changelogs earlier?

 On Tue, Aug 4, 2015 at 10:23 AM, Jaroslaw Staniek stan...@kde.org wrote:

 Hi,
 Are you ready to tag 2.9.7 ? Any blockers? Do you have code to release?

 I have a fix for Kexi to release so from this POV releasing ASAP is
 preferred.

 @Cyrille are you available these days?

 The original plan was:

 - Tagging August 1st
 - Release August 5th

 --
 regards, Jaroslaw Staniek

 KDE:
 : A world-wide network of software engineers, artists, writers,
 translators
 : and facilitators committed to Free Software development - http://kde.org
 Calligra Suite:
 : A graphic art and office suite - http://calligra.org
 Kexi:
 : A visual database apps builder - http://calligra.org/kexi
 Qt Certified Specialist:
 : http://www.linkedin.com/in/jstaniek
 ___
 calligra-devel mailing list
 calligra-devel@kde.org
 https://mail.kde.org/mailman/listinfo/calligra-devel




 --
 Dmitry Kazakov

 ___
 calligra-devel mailing list
 calligra-devel@kde.org
 https://mail.kde.org/mailman/listinfo/calligra-devel




-- 
regards, Jaroslaw Staniek

KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org
Calligra Suite:
: A graphic art and office suite - http://calligra.org
Kexi:
: A visual database apps builder - http://calligra.org/kexi
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel