T12815: Create Calligra Framework by separating out applications and libraries

[Boudewijn Rempt]

rempt added a comment.


  In T12815#223424 , @anthonyfieroni 
wrote:
  
  > @leinir Or you want Krita to returns back to Calligra framework?
  
  
  That's not going to happen... We're happy hacking out all the flexibility 
from the libraries that was only needed to support so many different 
applications.
  
  As an aside, I think splitting up kdepim into so many repositories was a huge 
mistake. Listening to David Faure at the onboarding sprint only confirmed that 
opinion. Having to work on half a dozen repos to add a single feature to kmail 
sounds like hell to me. I think it would be a mistake for Calligra, too, but 
don't pay attention to me :-)

TASK DETAIL
  https://phabricator.kde.org/T12815

To: rempt
Cc: rempt, anthonyfieroni, dcaliste, boemann, pino, rjvbb, ngraham, ognarb, 
Calligra-Devel-list, #calligra:_3.0, leinir, davidllewellynjones, cochise, 
vandenoever

Re: Karbon Color editor missing

[Boudewijn Rempt]

As I said, you need to select an object, then select the gradient. Make sure 
the tool options docker is enabled in Karbon's settings.

It might be better to use inkscape, though, since Karbon needs a lot of work 
done on it still.

On donderdag 5 maart 2020 21:28:37 CET JZA wrote:
> I found some screenshots there was an docker editor but cant pop it up
> again.
> https://i2.wp.com/herramientasgratis.com/wp-content/uploads/2018/11/Pantallazo-2.png?resize=768%2C576
> 
> On Thu, Mar 5, 2020 at 7:43 AM Boudewijn Rempt  wrote:
> 
> > Editing gradients in Karbon is rather fiddly. You first have to create an
> > object, select it and then select the on-canvas gradient tool. Then select
> > a gradient, select a stop on canvas, and then in the edit tab of the
> > gradient tool select a new color. I'm not sure myself, since it's ages that
> > I used Karbon, whether it is at all possible to add stops.
> >
> > On woensdag 4 maart 2020 14:36:29 CET JZA wrote:
> > > I wasnt able to edit a gradient, cant seem to find the color / gradient
> > > mixer. Did I miss something?
> > >
> > >
> >
> >
> > --
> > https://www.krita.org
> >
> >
> >
> 
> 


-- 
https://www.krita.org

Re: Karbon Color editor missing

[Boudewijn Rempt]

Editing gradients in Karbon is rather fiddly. You first have to create an 
object, select it and then select the on-canvas gradient tool. Then select a 
gradient, select a stop on canvas, and then in the edit tab of the gradient 
tool select a new color. I'm not sure myself, since it's ages that I used 
Karbon, whether it is at all possible to add stops.

On woensdag 4 maart 2020 14:36:29 CET JZA wrote:
> I wasnt able to edit a gradient, cant seem to find the color / gradient
> mixer. Did I miss something?
> 
> 


-- 
https://www.krita.org

Re: Qt version and new website

[Boudewijn Rempt]

On dinsdag 3 december 2019 15:54:53 CET Carl Schwan wrote:
> Hello,
> 
> I wanted to know if we could change the Qt dependency from Qt 5.3 to Qt 5.9 
> at least.
> 
> I think some parts already depends on Qt 5.7 at least. For example in 
> Calligra Gemini, there is
> a dependency to Kirigami, that depends on Qt Quick Control 2 introduced in Qt 
> 5.7.
> 
> I suppose there are two possible reasons, we still depend on Qt 5.3:
> 
> + Nobody bothered to change the CMakeLists.txt

I think it was because Jolla, which uses Calligra as the Sailfish documents 
application still is on Qt < 5.9: 

"We (Jolla) are looking reasonably into the summer or even 2nd half of 2019 for 
the Qt 5.9 roll-out. "

See https://together.jolla.com/question/194079/qt-512-and-sailfish-os-3/

> + Some parts of Calligra need a version of Qt <= 5.3
> 
> I hope this is the first reason.
> 
> In other news, I created a task for Season of KDE to rewrite the Calligra 
> website using
> KDE branding and a Jekyll theme 
> (https://invent.kde.org/websites/jekyll-kde-theme). So that
> we have a website looking like kontact.kde.org and cantor.kde.org.
> 
> Cheers,
> 
> Carl Schwan
> https://carlschwan.eu
> 
> 


-- 
Boudewijn Rempt | https://www.valdyas.org | https://www.krita.org

signature.asc
Description: This is a digitally signed message part.

Fwd: Top 15 Mailinglists with messages in moderation

[Boudewijn Rempt]

Is there still somebody here who can take care of the calligra-devel mailing 
list?

--  Forwarded Message  --

Subject: Fwd: Top 15 Mailinglists with messages in moderation
Date: donderdag 1 augustus 2019, 13:32:53 CEST
From: Ben Cooksley 
To: informing about and discussing non-technical community topics 

CC: sysadmin 

Hi all,

Please see the below lists of mailing lists which have a larger number
of messages in moderation.

If these lists are still active, we need to look into ensuring they
have an active moderator. For those lists which are no longer in use,
we should look at closing them (if necessary, aliasing them to another
list if there is sufficient crossover).

Cheers,
Ben

-- Forwarded message -
From: root 
Date: Thu, Aug 1, 2019 at 11:12 PM
Subject: Top 15 Mailinglists with messages in moderation
To: 

 70 kde-i18n-eo
 50 marble-devel
 45 kopete-devel
 39 kde-artists
 25 kget
 24 marble-bugs
 24 kde-linux
 23 kde-ev-marketing
 22 kde-l10n-en_gb
 21 calligra-devel
 19 kdevelop
 18 kde-look
 16 kde-ev-board
 15 kde-hardware-devel
 13 konq-bugs
 11 marble-commits
 10 koffice-devel
 10 kde-l10n-kn
  9 kde-el
  8 kexi
  8 kde-latam
  8 freenx-knx
  7 kstars-devel

-
-- 
Boudewijn Rempt | https://www.valdyas.org | https://www.krita.org

signature.asc
Description: This is a digitally signed message part.

Re: T10760: Calligra website unwanted blog content

[Boudewijn Rempt]

I think it might be time to take my blog and krita's news stream off, 
too :-)


On 2019-04-05 10:05, Boudewijn Rempt wrote:

I cannot check the task itself, but I did log in on calligra.org. I
cannot do anything except login in wordpress, but it doesn't look like
this is defined in wordpress itself. Maybe in a template? I cannot
access those.

On 2019-04-05 09:56, Jarosław Staniek wrote:

staniek added a comment.

Asking Cyrille and Boud...

F6754550: image.png [1]
TASK DETAIL
https://phabricator.kde.org/T10760
TO: staniek
CC: staniek, danders, Sysadmin, Calligra-Devel-list, Calligra: 3.0,
ongunkanat, sysadmin


Links:
--
[1] https://phabricator.kde.org/F6754550

Re: T10760: Calligra website unwanted blog content

[Boudewijn Rempt]

I cannot check the task itself, but I did log in on calligra.org. I 
cannot do anything except login in wordpress, but it doesn't look like 
this is defined in wordpress itself. Maybe in a template? I cannot 
access those.


On 2019-04-05 09:56, Jarosław Staniek wrote:

staniek added a comment.

Asking Cyrille and Boud...

F6754550: image.png [1]
TASK DETAIL
https://phabricator.kde.org/T10760
TO: staniek
CC: staniek, danders, Sysadmin, Calligra-Devel-list, Calligra: 3.0,
ongunkanat, sysadmin


Links:
--
[1] https://phabricator.kde.org/F6754550

Re: handshake and calligra?

[Boudewijn Rempt]

I had actually contacted handshake before to ask them for money for Krita, but 
they said they'd run out... I'll ping my contact about the name, as soon as I 
know whether they really have been in touch with anyone about this grant.

On maandag 6 augustus 2018 12:51:12 CEST Jaroslaw Staniek wrote:
> On 6 August 2018 at 11:44, Boudewijn Rempt  wrote:
> > Hi,
> > 
> > I just noticed that on https://handshake.org/ they mention "caligra" as a
> > recipient of their community grants. Despite the misspelling, the link
> > goes to
> > https://calligra.org. Does anyone know anything about that? If it's true,
> > we
> > probably should do a post about it, and what's going to be done with the
> > grant, but if not, we'd need to have that taken down...
> 
> Hi Boud
> If there's something it's donation to KDE e.V. for Calligra apps, as
> Calligra is not backed by separate organization. I can ask to fix the name
> though, thanks for pointing out.



signature.asc
Description: This is a digitally signed message part.

handshake and calligra?

[Boudewijn Rempt]

Hi,

I just noticed that on https://handshake.org/ they mention "caligra" as a 
recipient of their community grants. Despite the misspelling, the link goes to 
https://calligra.org. Does anyone know anything about that? If it's true, we 
probably should do a post about it, and what's going to be done with the 
grant, but if not, we'd need to have that taken down...

Boudewijn

signature.asc
Description: This is a digitally signed message part.

Re: Urgent: Is the domain koffice.net still needed?

[Boudewijn Rempt]

On woensdag 21 maart 2018 06:56:06 CET Ben Cooksley wrote:

> Unfortunately just about all those links will be long dead and broken as
> the content of koffice.org was lost at some point.

I do have a full backup of the old php site, even including history: 

https://github.com/boudewijnrempt/koffice-web

I uploaded it after I discovered that even the subversion module for koffice-
web had been deleted. The cms-based website is gone forever, of course.

-- 
Boudewijn Rempt | https://www.valdyas.org | https://www.krita.org

Re: Urgent: Is the domain koffice.net still needed?

[Boudewijn Rempt]

On dinsdag 20 maart 2018 15:12:18 CET Jaroslaw Staniek wrote:
> We had some discussion this month about preserving these links.
> Regardless technicalities and of availability volunteers to do that,
> this will not be possible if we loose the domain to hijackers so I
> would propose to keep it. And hope this will be not a disaster for the
> budget. :)

I've only got a historical interest in koffice.org, but yes, these are good 
points. We should keep it, probably.

-- 
Boudewijn Rempt | https://www.valdyas.org | https://www.krita.org

Re: Release announced on kde-announce-app

[Boudewijn Rempt]

On Wednesday, 31 January 2018 13:53:46 CET Dan Leinir Turthra Jensen wrote:
> On Wednesday, 31 January 2018 11:41:03 GMT Dag wrote:
> > See att file.
> > It would be swell if somebody with access could do likewise on
> > calligra.org, maybe add more about gemini.
> 
>   Sorry about not sending it on Monday as promised, a range of things ended
> up distracting me quite severely. But, i've updated the file with some
> Gemini notes and attached it here. I don't know who has access to
> calligra.org, but i'm thinking that spreading that access just slightly
> wider would perhaps be good...

Actually, both you and Dag have already access, and I've just made Dag admin, 
just like you are. He was editor before, which means he could already post 
news items, though.

(It took me a bit of effort to rediscover how to login to wordpress again, 
though)


-- 
Boudewijn Rempt | https://www.valdyas.org | https://www.krita.org

Re: Feature freeze

[Boudewijn Rempt]

On Tue, 19 Dec 2017, Dan Leinir Turthra Jensen wrote:

> https://binary-factory.kde.org/job/peruse-stable-win32/
> https://binary-factory.kde.org/job/peruse-stable-win64/

I guess s/peruse/calligra/g ?


-- 
Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org

Re: Moving calligra kostore and koodf

[Boudewijn Rempt]

On Wed, 1 Nov 2017, Dag wrote:

> Hi all,
> would there be any merit in moving those libs out of calligra into e.g.
> extragear/libs to make them available to external interested parties (krita
> atm).

I wouldn't be directly interested. kostore, maybe, but we're phasing out
support for ODG/ODT in Krita anyway.

> This will possibly make it easier to keep up to date on odf spec changes.
> 
> Any thoughts?
> 
> 

-- 
Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org

[krita] /: Make Krita build with KOXML_USE_QDOM defined

[Boudewijn Rempt]

Git commit 348a35915b923462604708a3db8aa305333ae8ee by Boudewijn Rempt.
Committed on 01/06/2017 at 09:01.
Pushed by rempt into branch 'master'.

Make Krita build with KOXML_USE_QDOM defined

This "fixes" all the places where KoXml::asQDomElement was used,
which was broken. It looks like nobody built like this since, oh,
2010 or so... It's a first step towards not using the KoXmlReader
code at all anymore.

There is no visible performance regression, but I didn't do real
benchmarking. But at least, with the ifdef working, we can do
benchmarking again.

In the text shape, some parts are just rudely ifdeffed out, mostly
to do with RDF, which krita doesn't need anyway, or changetracking,
which krita also doesn't need.

The really tricky bit is that in several places we used KoXmlDocument
with stripSpaces set to true, and I'm not sure what not being able
to set that flag will have.

KOXML_USE_QDOM is defined now, so Wolthera can continue with
the calligraphy tool; before merging to master, we should undefine
it again. Maybe we should make it a cmake option, if we're not just
going to remove KoXmlReader altogether.

CCMAIL:kimages...@kde.org

CC'ing the calligra developers since this might be of interest for
Calligra, too: either calligra should remove KOXmlReaderForward.h,
or make the ifdef work again -- which is likely much tricker than
it was for krita.

CCMAIL:calligra-devel@kde.org

M  +1-1libs/flake/KoFilterEffect.h
M  +1-1libs/flake/KoFilterEffectRegistry.h
M  +1-1libs/flake/KoFrameShape.h
M  +2-1libs/flake/KoMarker.h
M  +1-4libs/flake/KoMarkerCollection.cpp
M  +1-1libs/flake/KoMarkerCollection.h
M  +1-1libs/flake/KoOdfGradientBackground.h
M  +2-2libs/flake/KoOdfWorkaround.h
M  +1-1libs/flake/KoShapeAnchor.h
M  +1-1libs/flake/KoTextShapeDataBase.h
M  +7-6libs/flake/KoUnavailShape.cpp
M  +1-1libs/flake/svg/SvgCssHelper.h
M  +3-2libs/flake/svg/SvgParser.cpp
M  +1-1libs/flake/svg/SvgShape.h
M  +1-1libs/flake/svg/SvgStyleParser.h
M  +1-1libs/flake/svg/SvgUtil.h
M  +2-1libs/odf/KoColumns.h
M  +1-5libs/odf/KoOdfReadStore.cpp
M  +4-0libs/odf/tests/TestXmlReaderWithoutSpaces.cpp
M  +8-10   libs/store/KoXmlReader.cpp
M  +12   -10   libs/store/KoXmlReader.h
M  +1-1libs/store/KoXmlReaderForward.h
M  +1-3libs/ui/flake/kis_shape_layer.cc
M  +1-1plugins/flake/artistictextshape/ArtisticTextLoadingContext.h
M  +1-1plugins/flake/textshape/kotext/KoSection.h
M  +3-1plugins/flake/textshape/kotext/changetracker/KoChangeTracker.cpp
M  +6-1plugins/flake/textshape/kotext/opendocument/KoTextWriter_p.cpp
M  +19   -19   plugins/flake/textshape/kotext/styles/KoTableCellStyle.cpp
M  +8-0plugins/impex/kra/kra_converter.cpp
M  +1-1plugins/impex/libkra/kis_kra_loader.cpp

https://commits.kde.org/krita/348a35915b923462604708a3db8aa305333ae8ee

diff --git a/libs/flake/KoFilterEffect.h b/libs/flake/KoFilterEffect.h
index f0173f79c51..2817f2861ce 100644
--- a/libs/flake/KoFilterEffect.h
+++ b/libs/flake/KoFilterEffect.h
@@ -27,7 +27,7 @@ class QRectF;
 class KoXmlWriter;
 class KoFilterEffectRenderContext;
 class KoFilterEffectLoadingContext;
-class KoXmlElement;
+#include 
 
 #include "kritaflake_export.h"
 #include 
diff --git a/libs/flake/KoFilterEffectRegistry.h 
b/libs/flake/KoFilterEffectRegistry.h
index cd1cbb36439..594d3d2116d 100644
--- a/libs/flake/KoFilterEffectRegistry.h
+++ b/libs/flake/KoFilterEffectRegistry.h
@@ -25,7 +25,7 @@
 
 #include "kritaflake_export.h"
 
-class KoXmlElement;
+#include 
 class KoFilterEffectLoadingContext;
 class KoFilterEffect;
 
diff --git a/libs/flake/KoFrameShape.h b/libs/flake/KoFrameShape.h
index 062bfd2ffda..466a85e1e45 100644
--- a/libs/flake/KoFrameShape.h
+++ b/libs/flake/KoFrameShape.h
@@ -23,7 +23,7 @@
 #include "kritaflake_export.h"
 
 class KoShapeLoadingContext;
-class KoXmlElement;
+#include 
 class QString;
 
 /**
diff --git a/libs/flake/KoMarker.h b/libs/flake/KoMarker.h
index a50bc27b4fa..2413ced08b8 100644
--- a/libs/flake/KoMarker.h
+++ b/libs/flake/KoMarker.h
@@ -26,7 +26,8 @@
 #include "kritaflake_export.h"
 #include 
 
-class KoXmlElement;
+#include 
+
 class KoShapeLoadingContext;
 class KoShapeSavingContext;
 class QString;
diff --git a/libs/flake/KoMarkerCollection.cpp 
b/libs/flake/KoMarkerCollection.cpp
index 22c53dffca4..f723f34dee1 100644
--- a/libs/flake/KoMarkerCollection.cpp
+++ b/libs/flake/KoMarkerCollection.cpp
@@ -70,15 +70,12 @@ void KoMarkerCollection::loadMarkersFromFile(const QString 
)
 
 if (!file.open(QIODevice::ReadOnly)) return;
 
-QXmlStreamReader reader();
-reader.setNamespaceProcessing(false);
-
 QString errorMsg;
 int errorLine = 0;
 int errorColumn;
 
 KoXmlDocument doc;
-bool ok = doc.setContent(, , , );
+bool ok = doc.setContent(, false, , , 
);
 

[krita/wolthera/T5411-modernise-calligraphy-tool] /: Make Krita build with KOXML_USE_QDOM defined

[Boudewijn Rempt]

Git commit 514b87617ad9e2e06c17bd5bfe9db7c868df32b4 by Boudewijn Rempt.
Committed on 24/03/2017 at 10:07.
Pushed by rempt into branch 'wolthera/T5411-modernise-calligraphy-tool'.

Make Krita build with KOXML_USE_QDOM defined

This "fixes" all the places where KoXml::asQDomElement was used,
which was broken. It looks like nobody built like this since, oh,
2010 or so... It's a first step towards not using the KoXmlReader
code at all anymore.

There is no visible performance regression, but I didn't do real
benchmarking. But at least, with the ifdef working, we can do
benchmarking again.

In the text shape, some parts are just rudely ifdeffed out, mostly
to do with RDF, which krita doesn't need anyway, or changetracking,
which krita also doesn't need.

The really tricky bit is that in several places we used KoXmlDocument
with stripSpaces set to true, and I'm not sure what not being able
to set that flag will have.

KOXML_USE_QDOM is defined now, so Wolthera can continue with
the calligraphy tool; before merging to master, we should undefine
it again. Maybe we should make it a cmake option, if we're not just
going to remove KoXmlReader altogether.

CCMAIL:kimages...@kde.org

CC'ing the calligra developers since this might be of interest for
Calligra, too: either calligra should remove KOXmlReaderForward.h,
or make the ifdef work again -- which is likely much tricker than
it was for krita.

CCMAIL:calligra-devel@kde.org

M  +1-1libs/flake/KoFilterEffect.h
M  +1-1libs/flake/KoFilterEffectRegistry.h
M  +1-1libs/flake/KoFrameShape.h
M  +2-1libs/flake/KoMarker.h
M  +1-4libs/flake/KoMarkerCollection.cpp
M  +1-1libs/flake/KoMarkerCollection.h
M  +1-1libs/flake/KoOdfGradientBackground.h
M  +2-2libs/flake/KoOdfWorkaround.h
M  +1-1libs/flake/KoShapeAnchor.h
M  +1-1libs/flake/KoTextShapeDataBase.h
M  +7-6libs/flake/KoUnavailShape.cpp
M  +1-1libs/flake/svg/SvgCssHelper.h
M  +3-2libs/flake/svg/SvgParser.cpp
M  +1-1libs/flake/svg/SvgShape.h
M  +1-1libs/flake/svg/SvgStyleParser.h
M  +1-1libs/flake/svg/SvgUtil.h
M  +2-1libs/odf/KoColumns.h
M  +1-5libs/odf/KoOdfReadStore.cpp
M  +4-0libs/odf/tests/TestXmlReaderWithoutSpaces.cpp
M  +8-10   libs/store/KoXmlReader.cpp
M  +12   -10   libs/store/KoXmlReader.h
M  +1-1libs/store/KoXmlReaderForward.h
M  +1-3libs/ui/flake/kis_shape_layer.cc
M  +1-1plugins/flake/artistictextshape/ArtisticTextLoadingContext.h
M  +1-1plugins/flake/textshape/kotext/KoSection.h
M  +3-1plugins/flake/textshape/kotext/changetracker/KoChangeTracker.cpp
M  +6-1plugins/flake/textshape/kotext/opendocument/KoTextWriter_p.cpp
M  +19   -19   plugins/flake/textshape/kotext/styles/KoTableCellStyle.cpp
M  +8-0plugins/impex/kra/kra_converter.cpp
M  +1-1plugins/impex/libkra/kis_kra_loader.cpp

https://commits.kde.org/krita/514b87617ad9e2e06c17bd5bfe9db7c868df32b4

diff --git a/libs/flake/KoFilterEffect.h b/libs/flake/KoFilterEffect.h
index f0173f79c51..2817f2861ce 100644
--- a/libs/flake/KoFilterEffect.h
+++ b/libs/flake/KoFilterEffect.h
@@ -27,7 +27,7 @@ class QRectF;
 class KoXmlWriter;
 class KoFilterEffectRenderContext;
 class KoFilterEffectLoadingContext;
-class KoXmlElement;
+#include 
 
 #include "kritaflake_export.h"
 #include 
diff --git a/libs/flake/KoFilterEffectRegistry.h 
b/libs/flake/KoFilterEffectRegistry.h
index c79213c7451..1176385d2fb 100644
--- a/libs/flake/KoFilterEffectRegistry.h
+++ b/libs/flake/KoFilterEffectRegistry.h
@@ -25,7 +25,7 @@
 
 #include "kritaflake_export.h"
 
-class KoXmlElement;
+#include 
 class KoFilterEffectLoadingContext;
 class KoFilterEffect;
 
diff --git a/libs/flake/KoFrameShape.h b/libs/flake/KoFrameShape.h
index 062bfd2ffda..466a85e1e45 100644
--- a/libs/flake/KoFrameShape.h
+++ b/libs/flake/KoFrameShape.h
@@ -23,7 +23,7 @@
 #include "kritaflake_export.h"
 
 class KoShapeLoadingContext;
-class KoXmlElement;
+#include 
 class QString;
 
 /**
diff --git a/libs/flake/KoMarker.h b/libs/flake/KoMarker.h
index a50bc27b4fa..2413ced08b8 100644
--- a/libs/flake/KoMarker.h
+++ b/libs/flake/KoMarker.h
@@ -26,7 +26,8 @@
 #include "kritaflake_export.h"
 #include 
 
-class KoXmlElement;
+#include 
+
 class KoShapeLoadingContext;
 class KoShapeSavingContext;
 class QString;
diff --git a/libs/flake/KoMarkerCollection.cpp 
b/libs/flake/KoMarkerCollection.cpp
index 22c53dffca4..f723f34dee1 100644
--- a/libs/flake/KoMarkerCollection.cpp
+++ b/libs/flake/KoMarkerCollection.cpp
@@ -70,15 +70,12 @@ void KoMarkerCollection::loadMarkersFromFile(const QString 
)
 
 if (!file.open(QIODevice::ReadOnly)) return;
 
-QXmlStreamReader reader();
-reader.setNamespaceProcessing(false);
-
 QString errorMsg;
 int errorLine = 0;
 int errorColumn;
 
 KoXmlDocument doc;
-bool ok = doc.setContent(, , , );
+bool

Re: libpigmentcms.so - multiple definitions KoCompositeOp

[Boudewijn Rempt]

On Thu, 23 Mar 2017, Dag wrote:

> Treeve Jelbert skrev den 2017-03-22 18:13:
> > I just tried to build calligra from git-master, which I think is the
> > same as the release tarball.
> Yes.
> Works fine here, surprise, surprise ;)

I don't exactly remember the state of using Vc when krita separated from 
Calligra, but it would probably be best to remove it entirely. Nothing in 
Calligra is going to use any of this code at any point: it is used to blend 
layers together in Krita, and everything else in Calligra uses Qt for that.

It would be best to completely remove pigment, except for KoColorSet, but that 
also means replacing all use of KoColor with QColor. There used to be a 
compile-time switch for that, in the Nokia days.

(I know that there have been plans for over a decade to use pigment to have 
color managed images in Words, but pigment probably isn't the right solution 
for that anyway...)

-- 
Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org

isn't it time for...

[Boudewijn Rempt]

A release announcement?

-- 
Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org

Re: 3.0.0.1 tarball + signature

[Boudewijn Rempt]

On Thu, 5 Jan 2017, Jaroslaw Staniek wrote:

> On 5 January 2017 at 11:05, Boudewijn Rempt <b...@valdyas.org> wrote:
> 
> > On Thu, 5 Jan 2017, Jaroslaw Staniek wrote:
> >
> > > IMHO ​If it's not​ marked as a big thing, the media and users will
> > > definitely mark this as not important and move over. Inkscape just made a
> > > release that highlights a port to GTK+3 as an important news.
> >
> > Um... The version inkscape just released isn't the gtk3 port, it's still
> > gtk2 based.
> >
> > ​I referred to
> https://inkscape.org/en/news/2017/01/04/inkscape-version-092-released/
> and it ​
> 
> ​marks C++ upgrade and Gtk3 port as important.
> ​
> 

No: it says "(Future infrastructure changes include switching from bzr to git, 
shifting from Gtk2 to Gtk3, and moving to the C++11 standard.)" I.e., that's 
what they're going to do.

-- 
Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org

Re: 3.0.0.1 tarball + signature

[Boudewijn Rempt]

On Thu, 5 Jan 2017, Jaroslaw Staniek wrote:

> IMHO ​If it's not​ marked as a big thing, the media and users will
> definitely mark this as not important and move over. Inkscape just made a
> release that highlights a port to GTK+3 as an important news.

Um... The version inkscape just released isn't the gtk3 port, it's still
gtk2 based.


-- 
Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org

Re: Version stuff in CMakeLists.txt

[Boudewijn Rempt]

On Wed, 4 Jan 2017, Jaroslaw Staniek wrote:

> But I can't spot the calligra/3.0 branch which shall be set to 3.0.0
> version...

It was decided not to use release branches, but release from master.

-- 
Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org

Re: 3.0.0.1 tarball + signature

[Boudewijn Rempt]

On Tue, 3 Jan 2017, Dag wrote:

> Boudewijn Rempt skrev den 2017-01-03 11:57:
> > On Tue, 3 Jan 2017, Boudewijn Rempt wrote:
> > 
> > > On Tue, 3 Jan 2017, Dag wrote:
> > > 
> > > > Looks fine, it's a go from me!
> > > 
> > > Okay -- as soon as someone has done a release announcement, I'll
> > > upload and we can publish.
> 
> I was thinking like this:
> You upload, I notify packagers.

Done!

> If packagers don't find problems, we announce the release next Monday.
> 
> > 
> > Oh, and I've put the public key here:
> > 
> > https://share.kde.org/index.php/s/fJ99V5mZvuyD0z8
> > 
> > (If I did everything correctly)
> > 
> > > 
> > > >
> > > > Dag skrev den 2017-01-02 13:49:
> > > > > Boudewijn Rempt skrev den 2017-01-02 13:12:
> > > > > > I've updated the tarball and the sig -- the tarball is now 58M
> > > > > Yes, looks better, I'm running a clean build now to test.
> > > > >
> > > > > > On Mon, 2 Jan 2017, Boudewijn Rempt wrote:
> > > > > >
> > > > > > > On Mon, 2 Jan 2017, Boudewijn Rempt wrote:
> > > > > > >
> > > > > > > > Weird... I just let the script do its work, and then sign
> > > manually. So
> > > > > > > it
> > > > > > > > should compress the tarball. Even weirder, when I tried today,
> > > it
> > > > > > > suddenly
> > > > > > > > started asking for my key's passphrase for checking out the
> > > > > > > translations
> > > > > > > > a zillion times.
> > > > > > >
> > > > > > > Hm, looks like that was a glitch...
> > > > > > >
> > > > > > > >
> > > > > > > > On Mon, 2 Jan 2017, Dag wrote:
> > > > > > > >
> > > > > > > > > Hi, Boudewijn
> > > > > > > > > Happy new year.
> > > > > > > > >
> > > > > > > > > The tarball seems ok, except it is not compressed.
> > > > > > > > > The create_tarball script also uses the -a (or --armor) option
> > > to
> > > > > > > sign.
> > > > > > > > >
> > > > > > > > > Cheers,
> > > > > > > > > Dag
> > > > > > > > >
> > > > > > > > > Boudewijn Rempt skrev den 2016-12-28 15:05:
> > > > > > > > > > Hi,
> > > > > > > > > >
> > > > > > > > > > I've finally figured out how to fix gpg-agent, so next to
> > > > > > > > > >
> > > > > > > > > > http://valdyas.org/~boud/calligra-3.0.0.1.tar.xz
> > > > > > > > > >
> > > > > > > > > > there's now also
> > > > > > > > > >
> > > > > > > > > > http://valdyas.org/~boud/calligra-3.0.0.1.tar.xz.sig
> > > > > > > > > >
> > > > > > > > > > which you can use to check whether I've done everything
> > > > > > > correctly...
> > > > > > > > > >
> > > > > > > > > > This should be the corresponding public key:
> > > > > > > > > >
> > > > > > > > > > http://valdyas.org/~boud/0x58b9596c722ea3bd.asc
> > > > > > > > > >
> > > > > > > > > > (anyone know of a better place to put that? My webserver
> > > isn't
> > > > > > > > > > configured to use https yet...)
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > >
> > > 
> > > 
> 

-- 
Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org

Re: 3.0.0.1 tarball + signature

[Boudewijn Rempt]

On Tue, 3 Jan 2017, Dag wrote:

> Boudewijn Rempt skrev den 2017-01-03 11:57:
> > On Tue, 3 Jan 2017, Boudewijn Rempt wrote:
> > 
> > > On Tue, 3 Jan 2017, Dag wrote:
> > > 
> > > > Looks fine, it's a go from me!
> > > 
> > > Okay -- as soon as someone has done a release announcement, I'll
> > > upload and we can publish.
> 
> I was thinking like this:
> You upload, I notify packagers.

Okay! Will do now -- please also share the link to the key with the
packagers.

> If packagers don't find problems, we announce the release next Monday.
> 
> > 
> > Oh, and I've put the public key here:
> > 
> > https://share.kde.org/index.php/s/fJ99V5mZvuyD0z8
> > 
> > (If I did everything correctly)
> > 
> > > 
> > > >
> > > > Dag skrev den 2017-01-02 13:49:
> > > > > Boudewijn Rempt skrev den 2017-01-02 13:12:
> > > > > > I've updated the tarball and the sig -- the tarball is now 58M
> > > > > Yes, looks better, I'm running a clean build now to test.
> > > > >
> > > > > > On Mon, 2 Jan 2017, Boudewijn Rempt wrote:
> > > > > >
> > > > > > > On Mon, 2 Jan 2017, Boudewijn Rempt wrote:
> > > > > > >
> > > > > > > > Weird... I just let the script do its work, and then sign
> > > manually. So
> > > > > > > it
> > > > > > > > should compress the tarball. Even weirder, when I tried today,
> > > it
> > > > > > > suddenly
> > > > > > > > started asking for my key's passphrase for checking out the
> > > > > > > translations
> > > > > > > > a zillion times.
> > > > > > >
> > > > > > > Hm, looks like that was a glitch...
> > > > > > >
> > > > > > > >
> > > > > > > > On Mon, 2 Jan 2017, Dag wrote:
> > > > > > > >
> > > > > > > > > Hi, Boudewijn
> > > > > > > > > Happy new year.
> > > > > > > > >
> > > > > > > > > The tarball seems ok, except it is not compressed.
> > > > > > > > > The create_tarball script also uses the -a (or --armor) option
> > > to
> > > > > > > sign.
> > > > > > > > >
> > > > > > > > > Cheers,
> > > > > > > > > Dag
> > > > > > > > >
> > > > > > > > > Boudewijn Rempt skrev den 2016-12-28 15:05:
> > > > > > > > > > Hi,
> > > > > > > > > >
> > > > > > > > > > I've finally figured out how to fix gpg-agent, so next to
> > > > > > > > > >
> > > > > > > > > > http://valdyas.org/~boud/calligra-3.0.0.1.tar.xz
> > > > > > > > > >
> > > > > > > > > > there's now also
> > > > > > > > > >
> > > > > > > > > > http://valdyas.org/~boud/calligra-3.0.0.1.tar.xz.sig
> > > > > > > > > >
> > > > > > > > > > which you can use to check whether I've done everything
> > > > > > > correctly...
> > > > > > > > > >
> > > > > > > > > > This should be the corresponding public key:
> > > > > > > > > >
> > > > > > > > > > http://valdyas.org/~boud/0x58b9596c722ea3bd.asc
> > > > > > > > > >
> > > > > > > > > > (anyone know of a better place to put that? My webserver
> > > isn't
> > > > > > > > > > configured to use https yet...)
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > >
> > > 
> > > 
> 

-- 
Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org

Re: 3.0.0.1 tarball + signature

[Boudewijn Rempt]

On Tue, 3 Jan 2017, Boudewijn Rempt wrote:

> On Tue, 3 Jan 2017, Dag wrote:
> 
> > Looks fine, it's a go from me!
> 
> Okay -- as soon as someone has done a release announcment, I'll
> upload and we can publish.

Oh, and I've put the public key here:

https://share.kde.org/index.php/s/fJ99V5mZvuyD0z8

(If I did everything correctly)

> 
> > 
> > Dag skrev den 2017-01-02 13:49:
> > > Boudewijn Rempt skrev den 2017-01-02 13:12:
> > > > I've updated the tarball and the sig -- the tarball is now 58M
> > > Yes, looks better, I'm running a clean build now to test.
> > > 
> > > > On Mon, 2 Jan 2017, Boudewijn Rempt wrote:
> > > > 
> > > > > On Mon, 2 Jan 2017, Boudewijn Rempt wrote:
> > > > > 
> > > > > > Weird... I just let the script do its work, and then sign manually. 
> > > > > > So
> > > > > it
> > > > > > should compress the tarball. Even weirder, when I tried today, it
> > > > > suddenly
> > > > > > started asking for my key's passphrase for checking out the
> > > > > translations
> > > > > > a zillion times.
> > > > > 
> > > > > Hm, looks like that was a glitch...
> > > > > 
> > > > > >
> > > > > > On Mon, 2 Jan 2017, Dag wrote:
> > > > > >
> > > > > > > Hi, Boudewijn
> > > > > > > Happy new year.
> > > > > > >
> > > > > > > The tarball seems ok, except it is not compressed.
> > > > > > > The create_tarball script also uses the -a (or --armor) option to
> > > > > sign.
> > > > > > >
> > > > > > > Cheers,
> > > > > > > Dag
> > > > > > >
> > > > > > > Boudewijn Rempt skrev den 2016-12-28 15:05:
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > I've finally figured out how to fix gpg-agent, so next to
> > > > > > > >
> > > > > > > > http://valdyas.org/~boud/calligra-3.0.0.1.tar.xz
> > > > > > > >
> > > > > > > > there's now also
> > > > > > > >
> > > > > > > > http://valdyas.org/~boud/calligra-3.0.0.1.tar.xz.sig
> > > > > > > >
> > > > > > > > which you can use to check whether I've done everything
> > > > > correctly...
> > > > > > > >
> > > > > > > > This should be the corresponding public key:
> > > > > > > >
> > > > > > > > http://valdyas.org/~boud/0x58b9596c722ea3bd.asc
> > > > > > > >
> > > > > > > > (anyone know of a better place to put that? My webserver isn't
> > > > > > > > configured to use https yet...)
> > > > > > >
> > > > > >
> > > > > >
> > > > > 
> > > > > 
> > 
> 
> 

-- 
Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org

Re: 3.0.0.1 tarball + signature

[Boudewijn Rempt]

On Tue, 3 Jan 2017, Dag wrote:

> Looks fine, it's a go from me!

Okay -- as soon as someone has done a release announcment, I'll
upload and we can publish.

> 
> Dag skrev den 2017-01-02 13:49:
> > Boudewijn Rempt skrev den 2017-01-02 13:12:
> > > I've updated the tarball and the sig -- the tarball is now 58M
> > Yes, looks better, I'm running a clean build now to test.
> > 
> > > On Mon, 2 Jan 2017, Boudewijn Rempt wrote:
> > > 
> > > > On Mon, 2 Jan 2017, Boudewijn Rempt wrote:
> > > > 
> > > > > Weird... I just let the script do its work, and then sign manually. So
> > > > it
> > > > > should compress the tarball. Even weirder, when I tried today, it
> > > > suddenly
> > > > > started asking for my key's passphrase for checking out the
> > > > translations
> > > > > a zillion times.
> > > > 
> > > > Hm, looks like that was a glitch...
> > > > 
> > > > >
> > > > > On Mon, 2 Jan 2017, Dag wrote:
> > > > >
> > > > > > Hi, Boudewijn
> > > > > > Happy new year.
> > > > > >
> > > > > > The tarball seems ok, except it is not compressed.
> > > > > > The create_tarball script also uses the -a (or --armor) option to
> > > > sign.
> > > > > >
> > > > > > Cheers,
> > > > > > Dag
> > > > > >
> > > > > > Boudewijn Rempt skrev den 2016-12-28 15:05:
> > > > > > > Hi,
> > > > > > >
> > > > > > > I've finally figured out how to fix gpg-agent, so next to
> > > > > > >
> > > > > > > http://valdyas.org/~boud/calligra-3.0.0.1.tar.xz
> > > > > > >
> > > > > > > there's now also
> > > > > > >
> > > > > > > http://valdyas.org/~boud/calligra-3.0.0.1.tar.xz.sig
> > > > > > >
> > > > > > > which you can use to check whether I've done everything
> > > > correctly...
> > > > > > >
> > > > > > > This should be the corresponding public key:
> > > > > > >
> > > > > > > http://valdyas.org/~boud/0x58b9596c722ea3bd.asc
> > > > > > >
> > > > > > > (anyone know of a better place to put that? My webserver isn't
> > > > > > > configured to use https yet...)
> > > > > >
> > > > >
> > > > >
> > > > 
> > > > 
> 

-- 
Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org

Re: 3.0.0.1 tarball + signature

[Boudewijn Rempt]

I've updated the tarball and the sig -- the tarball is now 58M
On Mon, 2 Jan 2017, Boudewijn Rempt wrote:

> On Mon, 2 Jan 2017, Boudewijn Rempt wrote:
> 
> > Weird... I just let the script do its work, and then sign manually. So it
> > should compress the tarball. Even weirder, when I tried today, it suddenly
> > started asking for my key's passphrase for checking out the translations
> > a zillion times.
> 
> Hm, looks like that was a glitch...
> 
> > 
> > On Mon, 2 Jan 2017, Dag wrote:
> > 
> > > Hi, Boudewijn
> > > Happy new year.
> > > 
> > > The tarball seems ok, except it is not compressed.
> > > The create_tarball script also uses the -a (or --armor) option to sign.
> > > 
> > > Cheers,
> > > Dag
> > > 
> > > Boudewijn Rempt skrev den 2016-12-28 15:05:
> > > > Hi,
> > > > 
> > > > I've finally figured out how to fix gpg-agent, so next to
> > > > 
> > > > http://valdyas.org/~boud/calligra-3.0.0.1.tar.xz
> > > > 
> > > > there's now also
> > > > 
> > > > http://valdyas.org/~boud/calligra-3.0.0.1.tar.xz.sig
> > > > 
> > > > which you can use to check whether I've done everything correctly...
> > > > 
> > > > This should be the corresponding public key:
> > > > 
> > > > http://valdyas.org/~boud/0x58b9596c722ea3bd.asc
> > > > 
> > > > (anyone know of a better place to put that? My webserver isn't
> > > > configured to use https yet...)
> > > 
> > 
> > 
> 
> 

-- 
Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org

Re: 3.0.0.1 tarball + signature

[Boudewijn Rempt]

Weird... I just let the script do its work, and then sign manually. So it
should compress the tarball. Even weirder, when I tried today, it suddenly
started asking for my key's passphrase for checking out the translations
a zillion times.

On Mon, 2 Jan 2017, Dag wrote:

> Hi, Boudewijn
> Happy new year.
> 
> The tarball seems ok, except it is not compressed.
> The create_tarball script also uses the -a (or --armor) option to sign.
> 
> Cheers,
> Dag
> 
> Boudewijn Rempt skrev den 2016-12-28 15:05:
> > Hi,
> > 
> > I've finally figured out how to fix gpg-agent, so next to
> > 
> > http://valdyas.org/~boud/calligra-3.0.0.1.tar.xz
> > 
> > there's now also
> > 
> > http://valdyas.org/~boud/calligra-3.0.0.1.tar.xz.sig
> > 
> > which you can use to check whether I've done everything correctly...
> > 
> > This should be the corresponding public key:
> > 
> > http://valdyas.org/~boud/0x58b9596c722ea3bd.asc
> > 
> > (anyone know of a better place to put that? My webserver isn't
> > configured to use https yet...)
> 

-- 
Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org

Re: 3.0.0.1 tarball + signature

[Boudewijn Rempt]

On Thu, 29 Dec 2016, Jonathan Riddell wrote:

> Interestingly that gives a Bad gpg signature.  What did you use to
> make the signature?
> 
> The command I use is
> gpg2 --armor --detach-sign -o foo.tar.xz.sig foo.tar.xz

 gpg2 --output calligra-3.0.0.1.tar.xz.sig --detach-sig calligra-3.0.0.1.tar.xz

> 
> Jonathan
> 
> On 28 December 2016 at 14:05, Boudewijn Rempt <b...@valdyas.org> wrote:
> > Hi,
> >
> > I've finally figured out how to fix gpg-agent, so next to
> >
> > http://valdyas.org/~boud/calligra-3.0.0.1.tar.xz
> >
> > there's now also
> >
> > http://valdyas.org/~boud/calligra-3.0.0.1.tar.xz.sig
> >
> > which you can use to check whether I've done everything correctly...
> >
> > This should be the corresponding public key:
> >
> > http://valdyas.org/~boud/0x58b9596c722ea3bd.asc
> >
> > (anyone know of a better place to put that? My webserver isn't
> > configured to use https yet...)
> >
> > --
> > Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org
> 

-- 
Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org

Re: 3.0.0.1 tarball + signature

[Boudewijn Rempt]

On Thu, 29 Dec 2016, Jonathan Riddell wrote:

> On 28 December 2016 at 14:05, Boudewijn Rempt <b...@valdyas.org> wrote:
> > http://valdyas.org/~boud/0x58b9596c722ea3bd.asc
> 
> gpg --send-key 722ea3bd
> 
> should make it appear on keyservers and you can link to it
> 
> e.g. https://sks-keyservers.net/pks/lookup?op=vindex=0xEC94D18F7F05997E
> 

Well, yesterday I had someone complain that keys on keyservers cannot be 
trusted :-(

-- 
Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org

3.0.0.1 tarball + signature

[Boudewijn Rempt]

Hi, 

I've finally figured out how to fix gpg-agent, so next to 

http://valdyas.org/~boud/calligra-3.0.0.1.tar.xz

there's now also

http://valdyas.org/~boud/calligra-3.0.0.1.tar.xz.sig

which you can use to check whether I've done everything correctly...

This should be the corresponding public key:

http://valdyas.org/~boud/0x58b9596c722ea3bd.asc

(anyone know of a better place to put that? My webserver isn't
configured to use https yet...)

-- 
Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org

Re: Future releases

[Boudewijn Rempt]

I've made a new test tarball today, and put it on my own web server since I
didn't want to repeat the problems with the one I put on downloads.kde.org:

http://www.valdyas.org/~boud/calligra-3.0.0.1.tar.xz

Extra weirdness: last week, during the krita release, I could use gpg to sign,
this week, with no updates or whatever, and the same plasma 5 environment,
signing fails again:

boud@thinkstation:~/kde/src/createtarball> gpg2 --output 
calligra-3.0.0.1.tar.xz.sig --detach-sig calligra-3.0.0.1.tar.xz

You need a passphrase to unlock the secret key for
user: "Boudewijn Rempt <foundat...@krita.org>"
4096-bit RSA key, ID 722EA3BD, created 2016-09-06

gpg: problem with the agent: No pinentry
gpg: no default secret key: Operation cancelled
gpg: signing failed: Operation cancelled

And gpg-agent is running:

boud@thinkstation:~/kde/src/createtarball> ps ax | grep gpg-agent
 1806 ?S  0:00 /usr/bin/dbus-launch --sh-syntax --exit-with-session 
/usr/bin/ssh-agent /usr/bin/gpg-agent --sh --daemon --keep-display 
--write-env-file /home/boud/.gnupg/agent.info-thinkstation:0 
/etc/X11/xinit/xinitrc
 1808 ?Ss 0:00 /usr/bin/ssh-agent /usr/bin/gpg-agent --sh --daemon 
--keep-display --write-env-file /home/boud/.gnupg/agent.info-thinkstation:0 
/etc/X11/xinit/xinitrc
 1809 ?Ss 0:00 /usr/bin/gpg-agent --sh --daemon --keep-display 
--write-env-file /home/boud/.gnupg/agent.info-thinkstation:0 
/etc/X11/xinit/xinitrc
On Tue, 20 Dec 2016, Dag wrote:

> I'd like to discuss how to handle future releases, we don't want to continue
> to burden Boudewijn with it.
> 
> To summarize, I see two problem areas:
> - Who can generate the final release tarball. (pnt 4 below)
>   It must be someone with a trusted pgp key (I'm not trusted, so can't do it).
>   It should take <30 minutes, so is there somebody out there who could help?
> 
> - Somewhere to upload tarball for testing/checking before released to
> download.kde.org.
>   I thought about ftp://upload.kde.org/incoming but I don't think that is
> possible?
> 
> To ensure (as much as possible) that things will go smoothly I'm working on a
> release script
> and also plan to add more autotesting of the messages generation framework.
> We can't have another mess like this time.
> 
> So I propose a release cycle like this:
> 
> 1. ~2 weeks before release; string freeze and feature freeze
> 2. Closer to release some of us (I) create tarball, test and check if ok.
> 3. When ok, tag git
> 4. Create release tarball, upload for testing
> 5. Somebody (I) download tarball, build and test to verify it is ok
> 6. Publish tarball on download.kde.org (or possibly upload.kde.org)
> 7. Notify packagers and wait some time (a week?) for feedback
> 8. Announce to the world
> 
> What have I missed?
> Solutions (and comments) are welcome
> 
> Cheers,
> Dag
> 

-- 
Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org

Re: calligra 3.0.0 tarball

[Boudewijn Rempt]

I have no opinion on that part of the discussion, but I will dedicate tomorrow
afternoon to trying to build the correct tarballs with Dag's scripts -- and if 
that
works, I can make a Calligra 3.0.1 tarball  whenever I get the green light.

On Sat, 17 Dec 2016, Jonathan Riddell wrote:

> Debian packagers seem to think that using build type to build
> different products is wrong
> https://lists.alioth.debian.org/pipermail/pkg-kde-talk/2016-December/002451.html
> but it's hardly rare for packagers and coders to disagree.
> 
> What's the status of releasing Calligra?  It's been on download.kde
> for 10 days now
> 
> Jonathan
> 
> 
> On 12 December 2016 at 13:38, Jonathan Riddell <j...@jriddell.org> wrote:
> > On 12 December 2016 at 13:05, Boudewijn Rempt <b...@valdyas.org> wrote:
> >
> >> Debug or RelWithDebInfo? Because plain Debug makes things pretty slow
> >> and enables asserts, doesn't it?
> >
> > Possibly I'm wrong and worrying about nothing. We actually set cmake
> > build type to Debian which is a custom type we inherit from Debian and
> > I don't remember what's different or where that's set
> >
> > Jonathan
> 

-- 
Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org

Re: calligra 3.0.0 tarball

[Boudewijn Rempt]

On Mon, 12 Dec 2016, Jonathan Riddell wrote:

> On 7 December 2016 at 11:06, Dag <dand...@get2net.dk> wrote:
> > Jonathan Riddell skrev den 2016-12-07 11:33:
> >>
> >> Did I hear that Brainbump isn't built?  It does get built in my build
> >> from master
> >
> > Debug build yes, should not be built in release builds.
> > (Same with stage and flow)
> 
> I've changed Neon packaging to use Release builds. However this is an
> unusual way to use the build type flag.  Most distros will use Debug
> builds to get debug symbols (which are then extracted into a separate
> package). So I expect other distros will end up with Braindump being
> built in their packages.

Debug or RelWithDebInfo? Because plain Debug makes things pretty slow
and enables asserts, doesn't it?

> 
> Jonathan
> 

-- 
Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org

Re: calligra 3.0.0 tarball

[Boudewijn Rempt]

On Thu, 8 Dec 2016, Dag wrote:

> 
> 
> Boudewijn Rempt skrev den 2016-12-08 11:13:
> > On Thu, 8 Dec 2016, Dag wrote:
> > 
> > > Hmmm, well does this mean krita translations will be released/packaged
> > > with
> > > calligra release? If so, there is bound to be problems sooner or later. Or
> > > is/can this be taken care of in some way?
> > 
> > I guess I can add some code, if I remember a bit of ruby (it's years since
> > I last used it) to skip everything that sounds like krita or kexi.
> Yes well, when calligra is released, when krita is released skip
> calligra/kexi, and when kexi is released...
> Maybe the best solution, but doesn't sound great.
> 

Well, for Krita, we only have krita.po with everything in it -- so that works
out automatically. I'm not sure about kexi, though.

-- 
Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org

Re: calligra 3.0.0 tarball

[Boudewijn Rempt]

On Thu, 8 Dec 2016, Dag wrote:

> Ok, it seems good, a lot of po-files present, even too many I think.
> There are some krita and kexi stuff included, guess these should be deleted
> from po repository?

I'm not too sure about that -- there was some problem with creating a new 
top-level
mainmodule for krita, so krita's still somehow in the calligra hierarchy. 
That's why
the create-tarball config for krita is like this:

[krita]
gitModule   = yes
gitTag  = v3.0.94
mainmodule  = calligra
submodule   = krita
version = 3.0.94
translations= yes
docs= no
kde_release = no


-- 
Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org

Re: calligra 3.0.0 tarball

[Boudewijn Rempt]

On Wed, 7 Dec 2016, Jonathan Riddell wrote:

> On 7 December 2016 at 10:03, Boudewijn Rempt <b...@valdyas.org> wrote:
> > Yes, that worked. I've removed and re-uploaded a new tarball.
> 
> As I said this will confuse mirrors which often won't mirror a changed
> file on the server.  If you want to upload files before they are ready
> to publish you should set permissions 660 so they can't be ready by
> the web server.  Now that it is public you need to find a different
> file name (you can then remove the old one and make it a symlink to
> the new one).  You could move it to follow the more common directory
> pattern of calligra/3.0.0/calligra-3.0.0.tar.gz for example.

Sorry, I misunderstood you.

> 
> Always amazing how our top devs struggle with gpg.  If the gpg-agent
> isn't working then kill it, maybe remove it's files and remove any
> settings in ~/.gnupg/gpg.conf

Well, it's not just gpg. Signing stuff on Windows is horrible, too. And
I never really needed gpg before because I didn't make the calligra
releases. But why the heck doesn't it just work... 

But gpg is just so broken. If I do what you say, I still get:

boud@thinkstation:~> killall -9 gpg-agent
boud@thinkstation:~> mv .gnupg gnupg.bak
boud@thinkstation:~> gpg-agent 
gpg-agent[18150]: directory `/home/boud/.gnupg' created
gpg-agent[18150]: directory `/home/boud/.gnupg/private-keys-v1.d' created
gpg-agent: can't connect to the agent: IPC connect call failed

This is opensuse, but no matter the distribution, I _always_ run into 
trouble with gpg. Back in the kgpg days, it was a bit easier, but that's
also broken now. I just don't have the time to futz with something like
this.

> 
> I've got it building now from git master in KDE neon (dev stable branch for 
> now)
> http://build.neon.kde.org/job/xenial_stable_calligra_calligra_bin_amd64/1/console
> 
> Which of these missing build-deps do I need to care about?
> Phonon4Qt5Experimental (required version == 4.9.51)
> Vc (required version >= 1.1.0) , Portable, zero-overhead SIMD library
> for C++ , <https://github.com/VcDevel/Vc>

Nothing in Calligra really uses pigment, so Vc isn't necessary for Calligra. 

> PopplerXPDFHeaders , XPDF headers in the Poppler Qt5 interface library
> , <http://poppler.freedesktop.org>
> Libgit2
> Libqgit2
> Cauchy , Cauchy's M2MML, a Matlab/Octave to MathML compiler ,
> <https://bitbucket.org/cyrille/cauchy>
> 
> Jonathan
> 

-- 
Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org

Re: calligra 3.0.0 tarball

[Boudewijn Rempt]

On Wed, 7 Dec 2016, Boudewijn Rempt wrote:

> On Wed, 7 Dec 2016, Dag wrote:
> 
> > Had a look in the script. I'm not a ruby expert but seems you need
> > wholeModule=yes in the config.ini file to get all.
> 
> Cool, I'll do a new testspin today with that setting.
> 

Yes, that worked. I've removed and re-uploaded a new tarball.

-- 
Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org

Re: calligra 3.0.0 tarball

[Boudewijn Rempt]

On Wed, 7 Dec 2016, Dag wrote:

> Had a look in the script. I'm not a ruby expert but seems you need
> wholeModule=yes in the config.ini file to get all.

Cool, I'll do a new testspin today with that setting.

-- 
Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org

Re: calligra 3.0.0 tarball

[Boudewijn Rempt]

On Mon, 5 Dec 2016, Jonathan Riddell wrote:

> Also there's no PGP signature with the tar which isn't following
> current best practice.  Release scripts such as releaseme will do this
> for you

Yet another release script? I thought I was up to date by using 
createtarball.rb... In any case, for some reason, gpg stopped working and I 
have no idea how to fix it:

gpg: problem with the agent: No pinentry
gpg: no default secret key: Operation cancelled
gpg: signing failed: Operation cancelled


> 
> Jonathan
> 
> 
> On 5 December 2016 at 10:07, Dag <dand...@get2net.dk> wrote:
> > Thanks Boudewijn
> >
> > Boudewijn Rempt skrev den 2016-12-05 10:24:
> >>
> >> Hi,
> >>
> >> I've tagged v3.0.0 and created a tarball and uploaded it:
> >> http://download.kde.org/stable/calligra-3.0.0 .
> >>
> >> Please check if everything is okay, and if not, fix it; then I can
> >> move the tag and repack and re-upload.
> >
> > Yes there are problems. I sort of hoped you had picked up on the problems
> > with i18n which means we can't release yet.
> > I think I have fixed the problems, I'm still testing.
> >
> > That said, I see that there is no po files (except calligra.po) in your
> > tarball. I thought the po files available in trunk should have been
> > included?
> >
> 

-- 
Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org

Re: calligra 3.0.0 tarball

[Boudewijn Rempt]

On Mon, 5 Dec 2016, Dag wrote:

> Thanks Boudewijn
> 
> Boudewijn Rempt skrev den 2016-12-05 10:24:
> > Hi,
> > 
> > I've tagged v3.0.0 and created a tarball and uploaded it:
> > http://download.kde.org/stable/calligra-3.0.0 .
> > 
> > Please check if everything is okay, and if not, fix it; then I can
> > move the tag and repack and re-upload.
> Yes there are problems. I sort of hoped you had picked up on the problems with
> i18n which means we can't release yet.
> I think I have fixed the problems, I'm still testing.

I thought you had already fixed them...

> That said, I see that there is no po files (except calligra.po) in your
> tarball. I thought the po files available in trunk should have been included?

It looks like the script only check for one po file -- that's a bit of a bummer.

-- 
Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org

calligra 3.0.0 tarball

[Boudewijn Rempt]

Hi,

I've tagged v3.0.0 and created a tarball and uploaded it: 
http://download.kde.org/stable/calligra-3.0.0 .

Please check if everything is okay, and if not, fix it; then I can move the tag 
and repack and re-upload.

-- 
Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org

Re: Release, again

[Boudewijn Rempt]

On Fri, 25 Nov 2016, Friedrich W. H. Kossebau wrote:

> Hi Dag,
> 
> Am Freitag, 25. November 2016, 12:14:05 CET schrieb Dag:
> > Hi, everybody
> > We are closing in on release I don't think I know of more than getting
> > the migration stuff in.
> > Has anybody anything else they think has to be done before release?
> > 
> > Boudewijn, is there anything we need to prepare before we (you) start
> > creating tarballs.
> > I had a look at the release script and couldn't find anything about
> > calligra in the config file.
> 
> For a start you might perhaps also try the "old" Calligra-specific scripts 
> from Cyrille. See them linked in section "Tarball creation" of https://
> community.kde.org/Calligra/Release_Howto

No, don't even go there. The create_tarball_kf5.rb script in kde-dev-scripts
is good enough. All that's needed is to add a config section to the config
file, something like:

[calligra]
gitModule   = yes
gitTag  = v2.9.89
mainmodule  = calligra
submodule   = krita
version = 2.9.89
translations= yes
docs= no
kde_release = no

-- 
Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org

Re: state of release and release plan

[Boudewijn Rempt]

On Tue, 8 Nov 2016, Dag wrote:

> Ok, seems we have some sort of commitment from from Tomas, Camilla (separate
> mail) and me,
> which means Sheets, Words and Plan along with the shapes and filters we find
> is working.
> 
> But, I am totally blank on release work, so who will possibly step up to
> handle that?

With the createtarball.rb script in the kde-dev-scripts, it's so
easy-peasy to make a source release that I'm fine with doing that,
for old times' sake. I can also upload the source releases to the right
place in download.kde.org; I've got rights for that. I have no time to
make binary builds, but we never did that for Calligra anyway.

What I don't see myself doing is writing the announcement for
calligra.org. If there's someone who volunteers for that, all that is
needed is to tell me when to branch, tag, generate the tarball and upload
the result.

-- 
Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org

Re: "non standalone app bundle" builds on Mac

[Boudewijn Rempt]

On Sun, 6 Nov 2016, René J.V. Bertin wrote:

> Just how (un)sympathetic an attitude can I expect towards the idea of doing a 
> "linuxy" build on Mac? Would you consider patches that make this optional, 
> IOW, that uncouple the build type from CMake's platform token ("APPLE") but 
> put it under control of an option (e.g. "APPLE_STANDALONE_BUNDLE") which 
> could perfectly well be ON by default? Would there motivation to help me find 
> "obscure" locations in the source code where build type and install location 
> assumptions are being made?

I'm still here on this mailing list. To be frank, I don't really want a 
macports version of Krita: macports is fine and dandy for things that otherwise 
wouldn't be available, but in the case of Krita, it would only be yet another 
build with yet another set of bugs that I would need yet another system for to 
reproduce and try to fix. I don't want to support a macports version of Krita, 
and I wish I could be sure there wouldn't be one, so I don't have to ask every 
Apple user who accidentally uses the "macports" field instead of "app bundle" 
whether that's really what they're using.

> Concerning that last aspect, and re: Krita, I notice:
> - the code uses a legacy (but still working) Qt token (Q_OS_MAC) but also an 
> obsolete token (Q_WS_MAC) which I thought is no longer defined

Argh... Did they change that again? And, lovely, now that OSX is no longer 
called OSX, are they going to go back from Q_OS_OSX to Q_OS_MAC or Q_OS_MACOS?

> - seems to try to bypass QStandardPaths by setting up an XDG_DATA_DIRS env. 
> variable

That's needed to find the translations.

> After a few hours of work I'm now at a point where Krita builds and doesn't 
> immediately abort or exit with an error message (nb: qFatal() just provokes 
> what looks like a crash on Mac with stock Qt; the error message is never 
> shown). It crashes immediately though when I open the preferences (settings) 
> dialog - which starts DrKonqi just as you'd expect it to. I haven't yet had 
> the time to figure out the reason for this crash, but it's an example of the 
> sort of issue I might be asking for guidance about.
> 
> While I could work around the whole issue with a few patches to the build 
> system and symlinks in the app bundle to emulate a standalone bundle, I'd 
> prefer to do this properly. Once committed (in all senses of the term), that 
> should be easier to maintain and feel less like an uphill battle.
> 
> Thanks,
> René
> 

-- 
Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org

Release, pretty please?

[Boudewijn Rempt]

Hi...

I've seen that Ubuntu has updated Krita (and Calligra) for Zesty.
Sort of yay, but it's still only 2.9.11 and that's because there
has been no release of Calligra 3, and packaging Krita 3 would 
conflict with the packaging of calligra 2.9.11...

I would say that there should be either a Calligra 2.9.12 release
without Krita, or a Calligra 3.0 release. If the problem is that
there's nobody around to make tarballs and upload a Calligra 3.0
release, well, I can do that... 

But I really don't want distributions to go on providing Krita
2.9 instead of 3.0 only because they're stuck with Calligra 2.9.

-- 
Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org

[nemomobile-packages/calligra] [calligra] Build with Qt 5.6. Contributes to JB#35409 (#3) (fwd)

[Boudewijn Rempt]

Looks like Jolla is still keeping our first port to Qt5 up and running...

-- 
Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org

-- Forwarded message --
Date: Fri, 16 Sep 2016 22:36:41 -0700
From: martinjones <notificati...@github.com>
Reply-To: nemomobile-packages/calligra
<reply+00426c8a2c770a8836d449eeb75277441d7f51c151c2747592cf000113f498699
2a169ce0a955...@reply.github.com>
To: nemomobile-packages/calligra <calli...@noreply.github.com>
Subject: [nemomobile-packages/calligra] [calligra] Build with Qt 5.6.
Contributes to JB#35409 (#3)


You can view, comment on, or merge this pull request online at:

  https://github.com/nemomobile-packages/calligra/pull/3

-- Commit Summary --

  * [calligra] Build with Qt 5.6. Contributes to JB#35409

-- File Changes --

M calligra/devtools/rng2cpp/rng2cpp.cpp (4)
M calligra/fake/karchive.h (1)
M calligra/filters/libmsooxml/MsooXmlDiagramReader_p.cpp (24)
M calligra/libs/flake/KoPathPoint.cpp (2)
M calligra/libs/flake/KoPathShape.cpp (2)
M calligra/libs/main/KoFindText.h (2)
M calligra/libs/widgetutils/KoProperties.cpp (1)

-- Patch Links --

https://github.com/nemomobile-packages/calligra/pull/3.patch
https://github.com/nemomobile-packages/calligra/pull/3.diff

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/nemomobile-packages/calligra/pull/3

[krita] plugins/flake/textshape/kotext/styles: Fix memory leak

[Boudewijn Rempt]

Git commit fbd916d2af9cc025f505117fd1da13a29e6e3030 by Boudewijn Rempt.
Committed on 13/09/2016 at 07:22.
Pushed by rempt into branch 'master'.

Fix memory leak

==10207== 424 (24 direct, 400 indirect) bytes in 1 blocks are definitely lost 
in loss record 11,215 of 12,325
==10207==at 0x4C29670: operator new(unsigned long) (in 
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==10207==by 0x321A1982: KoStyleManager::KoStyleManager(QObject*) 
(KoStyleManager.cpp:152)
==10207==by 0x31B41D3F: 
TextShapeFactory::newDocumentResourceManager(KoDocumentResourceManager*) const 
(TextShapeFactory.cpp:158)
==10207==by 0x6D70D3F: KoShapeBasedDocumentBase::KoShapeBasedDocumentBase() 
(KoShapeBasedDocumentBase.cpp:40)
==10207==by 0x50FB291: KisShapeController::KisShapeController(KisDocument*, 
KisNameServer*) (kis_shape_controller.cpp:71)
==10207==by 0x5344AD8: KisDocument::init() (KisDocument.cpp:591)
==10207==by 0x534B5CC: KisDocument::KisDocument() (KisDocument.cpp:527)
==10207==by 0x538013A: KisPart::createDocument() const (KisPart.cpp:197)
==10207==by 0x5293D47: KisCustomImageWidget::createNewImage() 
(kis_custom_image_widget.cc:273)
==10207==by 0x529503E: KisCustomImageWidget::createImage() 
(kis_custom_image_widget.cc:232)
==10207==by 0xC344390: QMetaObject::activate(QObject*, int, int, void**) 
(in /home/boud/dev/deps/lib/libQt5Core.so.5.6.1)
==10207==by 0xB2A6551: QAbstractButton::clicked(bool) (in 
/home/boud/dev/deps/lib/libQt5Widgets.so.5.6.1)
==10207==
==10207== 430 (24 direct, 406 indirect) bytes in 1 blocks are definitely lost 
in loss record 11,216 of 12,325
==10207==at 0x4C29670: operator new(unsigned long) (in 
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==10207==by 0x321A1960: KoStyleManager::KoStyleManager(QObject*) 
(KoStyleManager.cpp:151)
==10207==by 0x31B41D3F: 
TextShapeFactory::newDocumentResourceManager(KoDocumentResourceManager*) const 
(TextShapeFactory.cpp:158)
==10207==by 0x6D70D3F: KoShapeBasedDocumentBase::KoShapeBasedDocumentBase() 
(KoShapeBasedDocumentBase.cpp:40)
==10207==by 0x50FB291: KisShapeController::KisShapeController(KisDocument*, 
KisNameServer*) (kis_shape_controller.cpp:71)
==10207==by 0x5344AD8: KisDocument::init() (KisDocument.cpp:591)
==10207==by 0x534B5CC: KisDocument::KisDocument() (KisDocument.cpp:527)
==10207==by 0x538013A: KisPart::createDocument() const (KisPart.cpp:197)
==10207==by 0x5293D47: KisCustomImageWidget::createNewImage() 
(kis_custom_image_widget.cc:273)
==10207==by 0x529503E: KisCustomImageWidget::createImage() 
(kis_custom_image_widget.cc:232)
==10207==by 0xC344390: QMetaObject::activate(QObject*, int, int, void**) 
(in /home/boud/dev/deps/lib/libQt5Core.so.5.6.1)
==10207==by 0xB2A6551: QAbstractButton::clicked(bool) (in 
/home/boud/dev/deps/lib/libQt5Widgets.so.5.6.1)
==10207==

Probably also present in Calligra

CCMAIL:calligra-devel@kde.org

M  +2-0plugins/flake/textshape/kotext/styles/KoStyleManager.cpp

http://commits.kde.org/krita/fbd916d2af9cc025f505117fd1da13a29e6e3030

diff --git a/plugins/flake/textshape/kotext/styles/KoStyleManager.cpp 
b/plugins/flake/textshape/kotext/styles/KoStyleManager.cpp
index 4dc0cbb..9544133 100644
--- a/plugins/flake/textshape/kotext/styles/KoStyleManager.cpp
+++ b/plugins/flake/textshape/kotext/styles/KoStyleManager.cpp
@@ -187,6 +187,8 @@ KoStyleManager::KoStyleManager(QObject *parent)
 
 KoStyleManager::~KoStyleManager()
 {
+delete d->footNotesConfiguration;
+delete d->endNotesConfiguration;
 delete d;
 }
 

[krita] libs: Fix a memory leak: the popup action should "own" the image collection

[Boudewijn Rempt]

Git commit deff966ee3041104f0e2bda587c94d58403670af by Boudewijn Rempt.
Committed on 12/09/2016 at 13:37.
Pushed by rempt into branch 'master'.

Fix a memory leak: the popup action should "own" the image collection

And the pattern background should check whether the popup still
exists. This bug probably is also in Calligra.

CCMAIL:calligra-devel@kde.org

M  +15   -6libs/flake/KoPatternBackground.cpp
M  +4-3libs/widgets/KoResourcePopupAction.cpp

http://commits.kde.org/krita/deff966ee3041104f0e2bda587c94d58403670af

diff --git a/libs/flake/KoPatternBackground.cpp 
b/libs/flake/KoPatternBackground.cpp
index a2289b7..9f0a170 100644
--- a/libs/flake/KoPatternBackground.cpp
+++ b/libs/flake/KoPatternBackground.cpp
@@ -37,6 +37,7 @@
 
 #include 
 #include 
+#include 
 
 class KoPatternBackgroundPrivate : public KoShapeBackgroundPrivate
 {
@@ -123,7 +124,7 @@ public:
 QSizeF targetImageSizePercent;
 QPointF refPointOffsetPercent;
 QPointF tileRepeatOffsetPercent;
-KoImageCollection * imageCollection;
+QPointer imageCollection;
 KoImageData * imageData;
 };
 
@@ -131,7 +132,7 @@ public:
 // 
 
 
-KoPatternBackground::KoPatternBackground(KoImageCollection * imageCollection)
+KoPatternBackground::KoPatternBackground(KoImageCollection *imageCollection)
 : KoShapeBackground(*(new KoPatternBackgroundPrivate()))
 {
 Q_D(KoPatternBackground);
@@ -160,7 +161,9 @@ void KoPatternBackground::setPattern(const QImage )
 {
 Q_D(KoPatternBackground);
 delete d->imageData;
-d->imageData = d->imageCollection->createImageData(pattern);
+if (d->imageCollection) {
+d->imageData = d->imageCollection->createImageData(pattern);
+}
 }
 
 void KoPatternBackground::setPattern(KoImageData *imageData)
@@ -358,7 +361,9 @@ void KoPatternBackground::fillStyle(KoGenStyle , 
KoShapeSavingContext 
 style.addProperty("draw:fill", "bitmap");
 style.addProperty("draw:fill-image-name", patternStyleName);
 
-context.addDataCenter(d->imageCollection);
+if (d->imageCollection) {
+context.addDataCenter(d->imageCollection);
+}
 }
 
 bool KoPatternBackground::loadStyle(KoOdfLoadingContext , const QSizeF 
&)
@@ -383,9 +388,13 @@ bool KoPatternBackground::loadStyle(KoOdfLoadingContext 
, const QSizeF &
 return false;
 
 delete d->imageData;
-d->imageData = d->imageCollection->createImageData(href, context.store());
-if (! d->imageData)
+d->imageData = 0;
+if (d->imageCollection) {
+d->imageData = d->imageCollection->createImageData(href, 
context.store());
+}
+if (! d->imageData) {
 return false;
+}
 
 // read the pattern repeat style
 QString style = styleStack.property(KoXmlNS::style, "repeat");
diff --git a/libs/widgets/KoResourcePopupAction.cpp 
b/libs/widgets/KoResourcePopupAction.cpp
index 95f0192..1c27b0c 100644
--- a/libs/widgets/KoResourcePopupAction.cpp
+++ b/libs/widgets/KoResourcePopupAction.cpp
@@ -50,6 +50,7 @@ public:
 QMenu *menu;
 KoResourceItemView *resourceList;
 QSharedPointer background;
+KoImageCollection *imageCollection;
 KoCheckerBoardPainter checkerPainter;
 };
 
@@ -83,8 +84,8 @@ 
KoResourcePopupAction::KoResourcePopupAction(QSharedPointersetCoordinateMode(QGradient::ObjectBoundingMode);
 d->background = QSharedPointer(new 
KoGradientBackground(qg));
 } else if (pattern) {
-KoImageCollection *collection = new KoImageCollection();
-d->background = QSharedPointer(new 
KoPatternBackground(collection));
+d->imageCollection = new KoImageCollection();
+d->background = QSharedPointer(new 
KoPatternBackground(d->imageCollection));
 
static_cast<KoPatternBackground*>(d->background.data())->setPattern(pattern->pattern());
 }
 
@@ -116,7 +117,7 @@ KoResourcePopupAction::~KoResourcePopupAction()
 }
 
 delete d->menu;
-
+delete d->imageCollection;
 delete d;
 }
 

Re: What to do with the Krita & Calligra?

[Boudewijn Rempt]

I also mailed the debian packages list a week ago.

On Mon, 30 May 2016, Friedrich W. H. Kossebau wrote:


Am Montag, 30. Mai 2016, 17:20:58 CEST schrieb Boudewijn Rempt:

On Mon, 30 May 2016, Friedrich W. H. Kossebau wrote:
> So this is about being able to install Krita3 next to e.g. Calligra
> Words2.9 or Karbon2.9, right?
> So where do you expect problems here, where would/could things installed
> clash, assuming at least the krita app program has been put into a
> separate
> package?

Yes -- I haven't tested it, but I expect problems there. Because, well
Murphy.


The ones to test it would/should be the distri packagers IMHO :)

Problem here is, we do not have much feedback by them, as they, unless 
following closely Krita development, might not know about the upcoming Krita 3 
release and thus also have not yet started packaging or giving things some 
more testing.
At least I only saw the email by Cyrille to	kde-distro-packag...@kde.org for 
Krita 3.0 Beta in April, but nothing else. Is there another list?


Just emailed to release-team & kde-distro-packagers mailinglists to get an 
idea where self-release-managed apps like Krita should do mass announcement of 
upcoming releases to packagers, so we (Krita, Calligra, Kexi & Co) do know 
where to ping them once their is something new to distribute.


Let's wait for the packagers' feedback. And say "No" to premature package 
optimizations ;) 


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


--
Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: What to do with the Krita & Calligra?

[Boudewijn Rempt]

On Mon, 30 May 2016, Jaroslaw Staniek wrote:



Hi Boud,
Is the situation different in this regard than it was in KOffice 1 -> Calligra 
2 time?
Co-installation was not there and is not here in case of Calligra 2/3 apps. 
Maybe package(s) of Krita 3 can be marked as obsoleting calligra-krita (2),
whatever the package name is in given distro.


_If_ distributions can do that without obsoleting also calligralibs -- I'm not 
sure about that.



Perhaps we can afford to have proper update for README.PACKAGERS.

Somewhat apparent change is lack of krita -> calligralibs dependency but it's 
kind of transparent for users.


On 30 May 2016 at 16:39,
​​Friedrich W. H. Kossebau <kosse...@kde.org> wrote:
  Hi,

  Am Montag, 30. Mai 2016, 16:14:32 CEST schrieb Boudewijn Rempt:
  > Hi,
  >
  > Tomorrow we'll release Krita 3.0.

  So awesome to have reached that point :)

  > At that point, the stable version
  > of Krita is no longer part of Calligra. On the other hand, Krita is
  > still part of the last stable release of Calligra, which makes it
  > hard for distributions to package both and make them coinstallable.

  Does it? Did anyone report problems?

  > When we split up Krita and Calligra I had expected both projects to
  > release more or less at the same moment, especially because the port
  > seemed to have posed much fewer problems for Calligra than for Krita.
  >
  > The question is: what do we do now? I guess there are three options:
  >
  > * Also release Calligra 3.0 Really Soon Now

  Sadly not possible, given the lack of dev resources at the moment.

  > * Make a Calligra 2.9 release without Krita

  Would that be really needed? Unless some distri packages all of Calligra 
into
  one package (which would be aweful and IMHO not supported by us), 
packagers
  should be able to create packages of new Krita next to packages from the 
old
  calligra, no?

  > * Accept the problem and do nothing

  Packagers could be told to use the cmake flag "-DBUILD_krita=off" with the
  existing calligra 2.9 tarball, that should in theory work to skip krita. 
But
  well, I am not sure what the problem is.

  > There is a simular problem with the calligra.org website: when will
  > we remove Krita from the website? When there's a new Calligta
  > release, now that there's a new Krita release, or...

  IMHO as soon as Krita 3 is out. The old landing page on calligra.org/krita
  would tell about Krita now grown up to be a project of its own.


@Cyrille: Would you be able to update the site with at putting least proper 
links to krita.org? Or hand over to someone else.

A short list:
- ​I have no access here:
​update the menu by removing Krita​ (2 places)
-Editing possible, I can try: remove the 
https://www.calligra.org/tour/calligra-suite/graphics-applications/​ and unlink 
it from
https://www.calligra.org/tour/calligra-suite/
-Editing possible, Boud: would you try? calligra.org/krita page stays (as it's 
target from elsewhere in the internet) but needs update - mentioning the
change
-calligra.org artwork - I am volunteering to cut off one app :)
-places such as wikipedia would need updates, please consider changed for your 
language :)
​ 
  ___
  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




--
Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

What to do with the Krita & Calligra?

[Boudewijn Rempt]

Hi,

Tomorrow we'll release Krita 3.0. At that point, the stable version
of Krita is no longer part of Calligra. On the other hand, Krita is
still part of the last stable release of Calligra, which makes it 
hard for distributions to package both and make them coinstallable.


When we split up Krita and Calligra I had expected both projects to
release more or less at the same moment, especially because the port
seemed to have posed much fewer problems for Calligra than for Krita.

The question is: what do we do now? I guess there are three options:

* Also release Calligra 3.0 Really Soon Now
* Make a Calligra 2.9 release without Krita
* Accept the problem and do nothing

There is a simular problem with the calligra.org website: when will
we remove Krita from the website? When there's a new Calligta
release, now that there's a new Krita release, or...

--
Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Calligra - FTBFS - due to VC?

[Boudewijn Rempt]

For Krita, and so I guess for Calligra as well, the right version is 0.7. 
Thorsten Zachmann is working on the port to 1.2, but he hasn't pushed anything 
yet.

On Mon, 28 Mar 2016, Scarlett Clark wrote:


Hi all, VC version has not changed since initial setup. If it was/is suppose to 
I have not been made aware, what version should it be?
Thanks,
Scarlett

On Mon, Mar 28, 2016 at 3:49 PM, Ben Cooksley <bcooks...@kde.org> wrote:
  On Tue, Mar 29, 2016 at 11:46 AM, Friedrich W. H. Kossebau
  <kosse...@kde.org> wrote:
  > Am Dienstag, 29. März 2016, 11:36:18 CEST schrieb Ben Cooksley:
  >> Hi Calligra Developers,
  >>
  >> It appears Calligra currently fails to build on the CI system, due to
  >> ifdef's which are dependent on VC variables. This is despite VC being
  >> found (depending on a too new / too old version / missing an include?)
  >>
  >> Please see
  >> 
https://build.kde.org/view/branchGroup%20kf5-qt5/job/calligra%20master%20kf
  >> 5-qt5/5/PLATFORM=Linux,compiler=gcc/consoleFull
  >>
  >> Could someone take a look and fix it please?
  >
  > Seems CI uses Vc 1.2 for qt5/kf5 stable builds and even Vc master for 
master
  > kf5-qt5.
  > Was that done by requests of Krita devs? Which would be fine, just needs
  > Calligra to follow any changes needed then.

  Not sure who would have requested it unfortunately. Scarlett might
  know more there.
  Is this an issue for Calligra? (the versions in use that is)

  >
  > Though current Krita builds seems to be done without Vc being installed 
as
  > dep, so cannot tell by that:
  > https://build.kde.org/job/krita%20master%20kf5-qt5/3/
  > PLATFORM=Linux,Variation=All,compiler=gcc/consoleText

  Probably needs an update to the build metadata - which I suspect may
  not have been done since Krita moved to it's own repo.

  >
  > Cheers
  > Friedrich

  Thanks,
  Ben






--
Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: State of Proposal to improving KDE Software Repository Organization?

[Boudewijn Rempt]

On Mon, 18 Jan 2016, Friedrich W. H. Kossebau wrote:

Reason that I ask is that due to the split of Calligra into several repos (see 
background^) the layout in the repo structure does no longer properly reflect 
the project organisation. Right now there are three active repos in the 
calligra/ repo substructure:

"calligra" at "calligra/"
"krita"at "calligra/krita"
"kexi" at "calligra/kexi"


What I'm wondering is, where is this "structure" actually visible? Not in

https://quickgit.kde.org/

or

https://phabricator.kde.org/diffusion/

I see it reflected in the old, to be discarded

https://projects.kde.org/projects

But where else? And what is it actually needed for?



(("calligra" at "calligra/" confuses at least kdesrc-build, sent an email to 
mpyne about if moving it to "calligra/calligra" should fix it.))


Things that are not properly matching organization:
* Krita starting with 3.* no longer is part of Calligra project
 (screws e.g. api.kde.org/bundled-apps-api/calligra-apidocs/ and also
 what people think to which project Krita belongs)
* Calligra & Krita are nowhere different to KDevelop, Digikam & Co,
 so no reason to be in a complete own toplevel structure,
 rather should be in the same sub structure, i.e. "Extragear",
 like extragear/calligra/* and extragear/graphics/krita

More, not only Calligra & Krita related:
* "Extragear" is an awful grouping name for apps with individual
 release plans, a legacy term that no longer fits most of the apps
 in that substructure


It's ghastly -- almost insulting. It's perpetuating the fallacy that
there are core KDE projects and peripheral projects.


* "KDE Applications" is a misleading grouping name for apps with a
 central release plan, as if those with individual release plans
 are not "KDE" applications (as in, not done in the KDE community)


Horrible as well.


* a single category per app as needed by the current tree structure layout
 of the repos, like "office", "graphics", "utils", is rather awkward,
 many apps do not match exactly one or would match multiple categories


Honestly, the need to group repositories is, to me, so weird that I think 
it would be best to adopt the following scheme:


a/amarok
a/...
...
c/calligra
g/gcompris
k/krita

And so on. It's meaningless as it is; it would be better to make that clear,
if grouping is really needed.

So IMHO some update of the repository organisation would be good, to reflect 
how things are these days.
Renaming of "Extragear" and "KDE Applications" is surely something which needs 
care from promo/marketing/VDG people first to find if that makes sense at all 
and what a good solution would be.


That again begs the question: where is the "organization" which apparently has
purely technical reasons visible to contributors and users?


(Being both maintainer of Okteta, which is in "KDE Applications", and meta-co-
maintainer of Calligra, which is not, but still done in the very same KDE 
community, that current naming seems so wrong to me).


But the actual names and grouping aside, for the pure technical renewing 
(which also involves all infrastructure like translation system, 
documentation, phabricator, etc), who is currently planning or working on 
what?
So does it makes sense to wait some more, or should we assume the current 
organization stays for longer, and Calligra & Krita repos should be moved 
inside that organization for now?



^Some background about Calligra repo split, as things are slightly 
complicated:


KRITA)  The "krita" repo was split off, because Krita has finally become a 
full project of its own, separate from Calligra. A logical place for the krita 
repo in the KDE repo structure would perhaps have been somewhere in extragear, 
but at least due to the translators preferring to keep the string catalogs of 
Krita in the "calligra" module as before, for less work, the krita repo was 
for now put as submodule of "calligra/".


KEXI)  Kexi continues to be part of the Calligra project/subcommunity, but the 
Kexi developers preferred a small simple repo "kexi" of their own (for build 
time and size). So the placement at "calligra/kexi" makes perfect sense.


OTHERAPPS)  As the other Calligra apps (Braindump, Karbon, Sheets, Words, 
Stage, etc.) are more tightly coupled and the binary interfaces between libs, 
plugins & apps can still change every other week, for now no further repo 
splitting is planned (to ensure atomic commits on API changes), and they all 
stay in the existing "calligra" repo.



Cheers
Friedrich
___
Krita mailing list
kimages...@kde.org
https://mail.kde.org/mailman/listinfo/kimageshop


--
Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Releasing 2.9.11

[Boudewijn Rempt]

Yes, I will definitely have bug fixes, and also updated French translations 
that should coincide with the publication of the first Krita book in French.

On Fri, 8 Jan 2016, Jaroslaw Staniek wrote:


On 5 January 2016 at 07:30, Boudewijn Rempt <b...@valdyas.org> wrote:

On Mon, 4 Jan 2016, Jaroslaw Staniek wrote:


On 4 January 2016 at 12:15, Boudewijn Rempt <b...@valdyas.org> wrote:


On Mon, 4 Jan 2016, Jaroslaw Staniek wrote:


Hi All,
Are we ready to release 2.9.11?



How about tagging near 16 or 23 or 30 Jan?
Do you expect any fixes by then?
Kexi will have 2 fixes at least.

Next date that fits to my availability would be Feb 13th.



Right now, I cannot promise anything -- I first need to finish working
packages of 3.0 alpha!


Noted, you have full 3 weeks for that :)


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


--
Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Consistent naming of folders in libs/ & renaming kundo2 -> koundo

[Boudewijn Rempt]

On Sat, 9 Jan 2016, Jaroslaw Staniek wrote:


And regarding kundo2 - wasn't it supposed to be a clone of the qt5 so we could 
get rid of our own version ?


I am interested in this too since kexi.git forked kundo2 to reduce
deps. I'd like to know if Qt 5 has all we need or if kundo stays, if
we can have it in a separate repo. It's 1.5K SLOC. If so I am
volunteering for making it a repo.



kundo2 started out as a fork of qt5's qundo stuff, but over the years extra 
functionality was added, but it might be that that was only used in Krita's 
history docker.

--
Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Releasing 2.9.11

[Boudewijn Rempt]

On Mon, 4 Jan 2016, Jaroslaw Staniek wrote:


Hi All,
Are we ready to release 2.9.11?

Original proposal:

Tagging Sat, Jan 2nd
Release Wed, Jan 6th


For Krita, it's probably okay to skip this release since we haven't got any bug 
fixes since the last release.

--
Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Releasing 2.9.11

[Boudewijn Rempt]

On Mon, 4 Jan 2016, Jaroslaw Staniek wrote:


On 4 January 2016 at 12:15, Boudewijn Rempt <b...@valdyas.org> wrote:

On Mon, 4 Jan 2016, Jaroslaw Staniek wrote:


Hi All,
Are we ready to release 2.9.11?



How about tagging near 16 or 23 or 30 Jan?
Do you expect any fixes by then?
Kexi will have 2 fixes at least.

Next date that fits to my availability would be Feb 13th.



Right now, I cannot promise anything -- I first need to finish working packages 
of 3.0 alpha!

--
Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Review Request 126553: Fix GHNS build.

[Boudewijn Rempt]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126553/#review90324
---

Ship it!


I'm sure the change is fine, though I recommend everyone to build with GHNS 
disabled because it's too broken to be useful. Can you push the change yourself?

- Boudewijn Rempt


On Dec. 28, 2015, 9:58 p.m., Matthew Dawson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126553/
> ---
> 
> (Updated Dec. 28, 2015, 9:58 p.m.)
> 
> 
> Review request for Calligra.
> 
> 
> Repository: calligra
> 
> 
> Description
> ---
> 
> This allows calligra to build when GHNS is enabled.
> 
> 
> Diffs
> -
> 
>   krita/ui/widgets/kis_advanced_color_space_selector.cc 4d40b1f 
>   libs/widgets/CMakeLists.txt c9a84e7 
> 
> Diff: https://git.reviewboard.kde.org/r/126553/diff/
> 
> 
> Testing
> ---
> 
> Code now compiles.
> 
> 
> Thanks,
> 
> Matthew Dawson
> 
>

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

Krita 2.9.10 changelog

[Boudewijn Rempt]

* Do no longer allow users to save 16 bit/channel linear gamma sRGB files to PNG without a profile. 
* BUG:356156. Do not crash when scaling down an image if the scaling factor gets too close to 0

* Add a basic storyboard template
* BUG:355884. Fix generating the .kra and .ora thumbnail
* BUG:355110. Fix loading some PSD files by Photoshop after saving from Krita
* Add an option to disable the vectorization speedup. This is for broken AMD 
processors.
* Add an option to log OpenGL calls for debugging purposes
* Remember the last-used profile when importing an untagged 16 bit/channel PNG 
image
* Fix a number of import/export filters that reported the wrong error code 
after the user pressed cancel. Patch by Nicholas LaPointe, thanks!
* BUG:352918. Fix a rare crash that could happen during slow operations
* BUG:353043. Fix an even rarer crash that could happen when recalculating the 
image under some circumstances.
* BUG:355205. Fix a crash when switching subwindows after removing a layer
* Improve memory usage when saving images by now creating a big image then 
scaling it down for the thumbnail
* BUG:353505. Make the small color selector consistent in color layout with 
other color selectors
* BUG:354975. Fix a crash that occasionally happened when working with multiple 
images.
* BUG:353152. Fix a crash when using painting assistants
* BUG:353638. Fix a race condition that could happen during complex operations
* BUG:345562. Fix a crash in the shortcut system.
* BUG:352018. Restore the window correctly after going to canvas-only and back

--
Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Reminder: Calligra 2.9.9

[Boudewijn Rempt]

For Krita:

* Fix typing in the artistic text tool. A regression in 2.9.8 made it 
impossible to type letters that were also used as global shortcuts. This is now 
fixed.
* Don't crash when opening an ODG file created in inkscape. The files are not 
displayed correctly, though, inkscape does something pretty weird when saving 
to ODG.
* Fix the gaussian blur filter: another 2.9.8 regression where applying a 
gaussian blur filter would cause the right and bottom edge to become 
semi-transparent.
* Show a message when trying to use the freehand brush tool on a vector layer
* Fix calculating available memory on OSX. Thanks to René J.V. Bertin for the 
patch!
* When duplicating layers, duplicate the channel flags so the new layers are 
alpha locked if the original layers were alpha locked.
* Add a ctrl-m shortcut for calling up the Color Curves filter dialog. Patch by 
Raghavendra Kamath. Thanks!
* Fix a number of hard to find crashes in the undo system and the compositions 
docker.
* Another exiv2-related jpeg saving fix.
* Improve performance by not updating the image when adding empty layers and 
masks.
* Add a new dark pass-through icon.

--
Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org

On Fri, 30 Oct 2015, Jaroslaw Staniek wrote:


Hi,
Dear Maintainers, it would help if you prepare your change logs very soon.

According to our plan we have:

   Tagging Sat, October 31st
   Release Wed, November 4th

Everyone: blogging about your 2.x and 3.x status/plans/impressions
will be appreciated too.

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

CMake error in 2.9

[Boudewijn Rempt]

Since upgrading to Kubuntu 15.10, I'm getting an error in the code that checks 
for marble, and I'm not sure how to fix that.

CMake Error at cmake/modules/FindCalligraMarble.cmake:70 (file):
  file STRINGS file "/usr/include/marble/MarbleGlobal.h" cannot be read.
Call Stack (most recent call first):
  /usr/share/kde4/apps/cmake/modules/MacroOptionalFindPackage.cmake:32 
(find_package)
  CMakeLists.txt:346 (macro_optional_find_package)


CMake Error at cmake/modules/FindCalligraMarble.cmake:78 (list):
  list GET given empty list
Call Stack (most recent call first):
  /usr/share/kde4/apps/cmake/modules/MacroOptionalFindPackage.cmake:32 
(find_package)
  CMakeLists.txt:346 (macro_optional_find_package)


CMake Error at cmake/modules/FindCalligraMarble.cmake:81 (list):
  list GET given empty list
Call Stack (most recent call first):
  /usr/share/kde4/apps/cmake/modules/MacroOptionalFindPackage.cmake:32 
(find_package)
  CMakeLists.txt:346 (macro_optional_find_package)


CMake Error at cmake/modules/FindCalligraMarble.cmake:84 (list):
  list GET given empty list
Call Stack (most recent call first):
  /usr/share/kde4/apps/cmake/modules/MacroOptionalFindPackage.cmake:32 
(find_package)
  CMakeLists.txt:346 (macro_optional_find_package)


CMake Error at CMakeLists.txt:359 (file):
  file failed to open for reading (No such file or directory):

/usr/include/marble/MarbleControlBox.h


CMake Error at CMakeLists.txt:360 (string):
  string sub-command REGEX, mode MATCH needs at least 5 arguments total to
  command.



--
Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Reminder: 2.9.8

[Boudewijn Rempt]

Yes, please go ahead. Travel took more time than I thought...

--
Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org

On Thu, 8 Oct 2015, Jaroslaw Staniek wrote:




On 29 September 2015 at 22:30, Boudewijn Rempt <b...@valdyas.org> wrote:
  I'll be at the QtWs that wednesday, but I'll prepare changelogs.


​OK please let me know if you accept that we publish today
​ ​and the Krita section contains "Details soon on krita.org".


  ​On Tue, 29 Sep 2015, Jaroslaw Staniek wrote:

  Hi,
  According to our previous agreement we have:

  * 2.9.8 Tagging Sat, October 3rd
  * 2.9.8 Release Wed, October 7th

  Dear Maintainers, it would help if you prepare your change logs.

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




--
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: Review Request 125487: Color set dialog: make combo non-editable, since typing a random name serves no purpose there.

[Boudewijn Rempt]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125487/#review86368
---

Ship it!


Ship It!

- Boudewijn Rempt


On Oct. 2, 2015, 9:01 p.m., David Faure wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125487/
> ---
> 
> (Updated Oct. 2, 2015, 9:01 p.m.)
> 
> 
> Review request for Calligra and Thorsten Zachmann.
> 
> 
> Repository: calligra
> 
> 
> Description
> ---
> 
> Color set dialog: make combo non-editable, since typing a random name serves 
> no purpose there.
> 
> 
> Diffs
> -
> 
>   libs/widgets/KoEditColorSet.ui c57d2d5478a84336c8a01e206d7a90ee4de6a721 
> 
> Diff: https://git.reviewboard.kde.org/r/125487/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> David Faure
> 
>

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

Re: Review Request 125493: PictureShapeConfigWidget: add error handling to KIO::Job.

[Boudewijn Rempt]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125493/#review86367
---

Ship it!


Sorry, was waiting for Zagge. Please push, I'll forward to master. There might 
actually be exactly the same issue in the VectorShape and in the VideoShape...

- Boudewijn Rempt


On Oct. 5, 2015, 10:22 a.m., David Faure wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125493/
> ---
> 
> (Updated Oct. 5, 2015, 10:22 a.m.)
> 
> 
> Review request for Calligra, Boudewijn Rempt and Thorsten Zachmann.
> 
> 
> Repository: calligra
> 
> 
> Description
> ---
> 
> Mistyping a filename in the file widget would lead to the job failing silently
> and the rest of the code trying to load an empty bytearray as the image data.
> 
> Better show a msgbox on error and delete the shape.
> 
> But this is last resort (e.g. remote URL and lost internet during transfer),
> see next commit.
> 
> 
> Diffs
> -
> 
>   plugins/pictureshape/PictureShapeConfigWidget.h 
> 14b59aaf749b335a3f69b075a8422732664f0ecb 
>   plugins/pictureshape/PictureShapeConfigWidget.cpp 
> e8cf8ccff228aa7a50a6ec58a2a1df7ede1a2ee0 
> 
> Diff: https://git.reviewboard.kde.org/r/125493/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> David Faure
> 
>

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

Re: Need help delete branch

[Boudewijn Rempt]

Sure, done.

On Sun, 20 Sep 2015, Yue Liu wrote:


Hi,

Anyone has permission to delete a branch and its history? I pushed a
personal development branch "formula" to origin, thought I could
delete it later, but found I don't have permission. Can anyone help me
delete it?

Thanks,
Yue
___
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: Copying doc strings into app strings

[Boudewijn Rempt]

Hi,

We're trying to edit these strings a bit more. They are shown in the gui, in the
colorspace browser, in response to users asking for guidance when choosing color
spaces and profiles. They are a bit chatty, that's true...

Boudewijn


On Sat, 19 Sep 2015, Yuri Chornoivan wrote:


19 вересня 2015, 07:57:01, від "Łukasz Wojniłowicz" 
:


  Hallo all,

I translate Krita and encountered such string.

> Hewlett-Packard and Microsoft designed sRGB to match the color gamut of
> consumer-grade CRTs from the 1990s. sRGB is the standard color space for the
> world wide web and is still the best choice for exporting images to the
> internet.


The sRGB color gamut was a good match to calibrated

> decent quality CRTs. But sRGB is not a good match to many consumer-grade LCD
> monitors, which often can't display the more saturated sRGB blues and
> magentas (the good news: as technology progresses, wider gamuts are
> trickling down to consumer grade monitors).


Printer color gamuts

> can easily exceed the sRGB color gamut in cyans, greens, and yellow-greens.
> Colors from interpolated camera raw files also often exceed the sRGB color
> gamut.


As a very relevant aside, using perceptual intent when

> converting to sRGB does not magically makes otherwise out of gamut colors
> fit inside the sRGB color gamut! The standard sRGB color space (along with
> all the other the RGB profiles provided in my profile pack) is a matrix
> profile, and matrix profiles don't have perceptual intent tables.

It looks like lengthy text copy-pasted from Wikipedia and in my opinion should 
be put in documentation for Krita. There are many more of such strings e.g.


> To avoid possible copyright infringement issues, I used 'WideRGB' as the
> base name for these profiles.


WideGamutRGB was designed by Adobe to

> be a wide gamut color space that uses spectral colors as its primaries.
> Pascale's primary values produce a profile that matches old V2 Widegamut
> profiles from Adobe and Canon. It's an interesting color space, but shortly
> after its introduction, Adobe switched their emphasis to the ProPhotoRGB
> color space.

This string looks like snippet out of developer's diary...

Are there no conditions for strings to be assigned either doc or app string?
Regards
LW


Hi,

These strings are from the new color profiles package. Personally, I do not 
think they can be separated into docs in the common sense. The notes were 
copied from the original work by Elle Stone. The only way to make them easier 
to translate is to shorten them (just my 2 cents).

The message is cc-ed to calligra-devel for further consideration.

Best regards,
Yuri


___
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

[Differential] [Updated] D362: Modularity++: Move find_package() to places where they belong, make other optional

[rempt (Boudewijn Rempt)]

rempt added a comment.

I would prefer to have as many checks in the toplevel cmakelists.txt as 
possible, actually, because we often end up having a check in two places if we 
don't. I think that this change would be best applied to a kexi-exit branch, 
where you can prepare for creating the separate repo by doing bigger 
refactorings.

For me, if this would land, I probably would have to restore the checks when 
preparing krita's exit branch. But then, that's going to need a bigger 
refactoring of the build system in any case.


REPOSITORY
  rCALLIGRA Calligra

REVISION DETAIL
  https://phabricator.kde.org/D362

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: staniek, kossebau, rempt
Cc: Calligra-Devel-list, wicik, staniek
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

"Done" porting...

[Boudewijn Rempt]

Hi,

I'm pretty square-eyed by now, but I've ported the big bulk of the libraries, 
some of the plugins and krita to no longer depend on kdelibs4support.

Libraries that are todo are:

* komain
* kokross
* kopageapp
* rdf

Plugins that are todo are:

* chartshape
* commentshape
* formulashape
* kexi
* pictureshape
* pluginshape
* semanticitems
* spacenavigator
* staging
* textediting
* variables
* vectorshaope
* videoshape

A couple of notes:

* I moved the karbon plugins to calligra/plugins/karbonplugins. There are 
filters for shapes and flake tools that are actually also used or usable in 
other applications. This has been a todo since the second koffice sprint in 
Berlin and it turned out not be too hard.

* KoResourcePaths offers the part of the KStandardDirs api we were actually 
using, but is implemented using QStandardPaths. I am pretty sure I didn't catch 
all the ways we were using that api, it was crazily flexible, so I'd really 
like some help testing and fixing here.

* Icons. Locally, Dmitry and I seem to have a problem with kiconloader's icon 
cache. Or maybe it's more generic: I see a lot of errors in the terminal output 
about qbuffer objects not being open, even if they are open.

My next step will be to debug, debug and debug... There's plenty still not 
working in Krita, so I'd really recommend all artists not to try master yet :-)

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

[Differential] [Commented On] D361: KoColorConversionTransformation: msvc can't export static data, change it to inline static methods

[rempt (Boudewijn Rempt)]

rempt added a comment.

Can you also add michael abrahams as a reviewer?


REPOSITORY
  rCALLIGRA Calligra

REVISION DETAIL
  https://phabricator.kde.org/D361

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: staniek, kossebau, rempt
Cc: Calligra-Devel-list
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

[Differential] [Updated] D361: KoColorConversionTransformation: msvc can't export static data, change it to inline static methods

[rempt (Boudewijn Rempt)]

rempt added a comment.

Um... But we've been building pigment and krita with msvc for years now?


REPOSITORY
  rCALLIGRA Calligra

REVISION DETAIL
  https://phabricator.kde.org/D361

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: staniek, kossebau, rempt
Cc: Calligra-Devel-list
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

[calligra] /: Make kowidgets kdelibs4support-free

[Boudewijn Rempt]

Git commit 8d771da3224621514cf39213755ba1149019d1e7 by Boudewijn Rempt.
Committed on 15/09/2015 at 07:21.
Pushed by rempt into branch 'master'.

Make kowidgets kdelibs4support-free

This breaks komain, which is now unported again...

CCMAIL:calligra-devel@kde.org

There is also a big todo left for the resourceserverprovider.
QStandardPaths and KStandardDirs have one really big difference:
KStandardDirs allows you to define a resource type and add different
locations to look for those resources, QStandardPaths doesn't.

The porting guide says to simply look in all those places when
using QStandardPaths::locate, but that doesn't work, of course, for
us, because our resource loading code is all generic.

So this needs thought...

M  +1-1CalligraProducts.cmake
M  +4-2libs/widgets/CMakeLists.txt
M  +2-2libs/widgets/KoColorPopupAction.cpp
M  +1-1libs/widgets/KoColorPopupButton.cpp
M  +1-2libs/widgets/KoColorSetWidget.cpp
M  +1-1libs/widgets/KoColorSetWidget_p.h
M  +9-9libs/widgets/KoCsvImportDialog.cpp
M  +1-1libs/widgets/KoDockWidgetTitleBar.cpp
M  +1-1libs/widgets/KoDockWidgetTitleBarButton.cpp
M  +1-1libs/widgets/KoDockWidgetTitleBar_p.h
M  +1-1libs/widgets/KoDocumentInfoDlg.cpp
M  +1-1libs/widgets/KoDocumentInfoPropsPage.cpp
M  +5-3libs/widgets/KoDpi.cpp
M  +2-1libs/widgets/KoDpi.h
M  +5-3libs/widgets/KoDualColorButton.cpp
M  +7-6libs/widgets/KoEditColorSetDialog.cpp
M  +2-2libs/widgets/KoFileDialog.cpp
M  +3-3libs/widgets/KoGlobal.cpp
M  +1-1libs/widgets/KoIconToolTip.cpp
M  +4-2libs/widgets/KoModeBox.cpp
M  +1-1libs/widgets/KoModeBoxDocker.cpp
M  +1-1libs/widgets/KoPageLayoutDialog.cpp
M  +1-1libs/widgets/KoPageLayoutWidget.cpp
M  +1-1libs/widgets/KoPagePreviewWidget.cpp
M  +1-1libs/widgets/KoPositionSelector.cpp
M  +3-2libs/widgets/KoResourceItemChooserSync.cpp
M  +2-2libs/widgets/KoResourceItemChooserSync.h
M  +1-1libs/widgets/KoResourceSelector.cpp
M  +30   -19   libs/widgets/KoResourceServer.h
M  +20   -19   libs/widgets/KoResourceServerProvider.cpp
M  +2-2libs/widgets/KoResourceServerProvider.h
M  +10   -9libs/widgets/KoResourceTagStore.cpp
M  +1-1libs/widgets/KoResourceTagStore.h
M  +2-2libs/widgets/KoResourceTaggingManager.cpp
M  +1-1libs/widgets/KoRuler.cpp
M  +1-1libs/widgets/KoRulerController.cpp
M  +2-2libs/widgets/KoRulerController_p.h
M  +2-2libs/widgets/KoSliderCombo.cpp
M  +1-1libs/widgets/KoSliderCombo_p.h
M  +3-3libs/widgets/KoToolBox.cpp
M  +1-1libs/widgets/KoToolBoxLayout_p.h
M  +3-3libs/widgets/KoToolDocker.cpp
M  +10   -10   libs/widgets/KoUnitDoubleSpinBox.cpp
M  +2-2libs/widgets/KoZoomAction.cpp
M  +3-3libs/widgets/KoZoomController.cpp
M  +1-1libs/widgets/KoZoomController_p.h
M  +1-1libs/widgets/KoZoomHandler.cpp
M  +1-1libs/widgets/KoZoomInput.cpp
C  +6-18   libs/widgets/WidgetsDebug.cpp [from: 
libs/widgets/tests/zoomcontroller_test.cpp - 057% similarity]
C  +11   -19   libs/widgets/WidgetsDebug.h [from: 
libs/widgets/tests/zoomcontroller_test.cpp - 056% similarity]
M  +1-1libs/widgets/tests/KoResourceTaggingTest.cpp
M  +1-1libs/widgets/tests/zoomcontroller_test.cpp
M  +1-1libs/widgets/tests/zoomhandler_test.cpp

http://commits.kde.org/calligra/8d771da3224621514cf39213755ba1149019d1e7

diff --git a/CalligraProducts.cmake b/CalligraProducts.cmake
index 13c8dc6..8383ef5 100644
--- a/CalligraProducts.cmake
+++ b/CalligraProducts.cmake
@@ -67,7 +67,7 @@ calligra_define_product(LIB_KOVECTORIMAGE "libkovectorimage")
 
 # calligra libs
 calligra_define_product(LIB_CALLIGRA "Calligra core libs"  REQUIRES 
BUILDTOOL_RNG2CPP)
-calligra_define_product(LIB_KOMAIN "Lib for one-file-per-window apps"  
REQUIRES LIB_CALLIGRA)
+calligra_define_product(LIB_KOMAIN "Lib for one-file-per-window apps" UNPORTED 
REQUIRES LIB_CALLIGRA)
 calligra_define_product(LIB_KOPAGEAPP "Lib for paged documents"  REQUIRES 
LIB_CALLIGRA LIB_KOMAIN)
 calligra_define_product(LIB_KOODF2 "libkoodf2"  REQUIRES LIB_CALLIGRA)
 calligra_define_product(LIB_KOODFREADER "libkoodfreader"  REQUIRES LIB_KOODF2 
LIB_CALLIGRA)
diff --git a/libs/widgets/CMakeLists.txt b/libs/widgets/CMakeLists.txt
index c9fd8a1..9f6761c 100644
--- a/libs/widgets/CMakeLists.txt
+++ b/libs/widgets/CMakeLists.txt
@@ -90,6 +90,8 @@ set(kowidgets_LIB_SRCS
 KoTableView.cpp
 
 KoIconUtils.cpp
+
+WidgetsDebug.cpp
 )
 
 ki18n_wrap_ui( kowidgets_LIB_SRCS
@@ -106,7 +108,7 @@ ki18n_wrap_ui( kowidgets_LIB_SRCS
 add_library(kowidgets SHARED ${kowidgets_LIB_SRCS})
 generate_export_header(kowidgets BASE_NAME kowidgets)
 
-target_link_libraries(kowidgets kotext pigmentcms kowidgetutils 
KF5::KDELibs4Support

ported libs/widgets

[Boudewijn Rempt]

Hi,

I've just ported libs/widgets and _that_ compiles. Unfortunately it breaks 
komain
and krita/ui... And there are still issues with KStandardDirs and QStandardPaths
that need a bit of thinking. I'll probably need to invent some sort of wrapper
class that allows us to associate a resource type with any number of 
locations...

But that's for tomorrow.

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

Re: [calligra] libs/pigment: Do not link to kdelibs4support

[Boudewijn Rempt]

On Mon, 14 Sep 2015, Adam Pigg wrote:


Na, kreport and kproperty beat it :D


They're not in calligra anymore :P



Sent from my BlackBerry 10 smartphone.
  Original Message  
From: Boudewijn Rempt
Sent: Monday, 14 September 2015 09:16
To: kde-comm...@kde.org
Reply To: Calligra Suite developers and users mailing list
Cc: calligra-devel@kde.org; kr...@kde.org
Subject: [calligra] libs/pigment: Do not link to kdelibs4support

Git commit 7f3d56081c492aaa28f160a84feb52e332c9cfc3 by Boudewijn Rempt.
Committed on 14/09/2015 at 08:15.
Pushed by rempt into branch 'master'.

Do not link to kdelibs4support

Pigment is the first Calligra library fully ported away
from kdelibs4support!

CCMAIL:calligra-devel@kde.org
CCMAIL:kr...@kde.org

M +3 -3 libs/pigment/CMakeLists.txt
M +2 -2 libs/pigment/benchmarks/CMakeLists.txt
M +11 -11 libs/pigment/tests/CMakeLists.txt

http://commits.kde.org/calligra/7f3d56081c492aaa28f160a84feb52e332c9cfc3

diff --git a/libs/pigment/CMakeLists.txt b/libs/pigment/CMakeLists.txt
index 95ba25e..af9bb5c 100644
--- a/libs/pigment/CMakeLists.txt
+++ b/libs/pigment/CMakeLists.txt
@@ -133,15 +133,15 @@ generate_export_header(pigmentcms
)

if (HAVE_VC)
- target_link_libraries(pigmentcms KF5::I18n KF5::KDELibs4Support)
- target_link_libraries(pigmentcms LINK_INTERFACE_LIBRARIES KF5::I18n 
KF5::KDELibs4Support)
+ target_link_libraries(pigmentcms KF5::I18n )
+ target_link_libraries(pigmentcms LINK_INTERFACE_LIBRARIES KF5::I18n )
endif()

target_link_libraries(
pigmentcms
koplugin
${EXTRA_LIBRARIES}
- KF5::I18n KF5::KDELibs4Support
+ KF5::I18n 
Qt5::Gui

Qt5::Xml
${WIN32_PLATFORM_NET_LIBS}
diff --git a/libs/pigment/benchmarks/CMakeLists.txt 
b/libs/pigment/benchmarks/CMakeLists.txt
index 3f2c2ce..7837f39 100644
--- a/libs/pigment/benchmarks/CMakeLists.txt
+++ b/libs/pigment/benchmarks/CMakeLists.txt
@@ -5,9 +5,9 @@ set(EXECUTABLE_OUTPUT_PATH ${CMAKE_CURRENT_BINARY_DIR})

set(ko_colorspaces_benchmark_SRCS KoColorSpacesBenchmark.cpp)
calligra_add_benchmark(KoColorSpacesBenchmark TESTNAME 
pigment-benchmarks-KoColorSpacesBenchmark ${ko_colorspaces_benchmark_SRCS})
-target_link_libraries(KoColorSpacesBenchmark pigmentcms KF5::I18n 
KF5::KDELibs4Support Qt5::Test)
+target_link_libraries(KoColorSpacesBenchmark pigmentcms KF5::I18n Qt5::Test)

set(ko_compositeops_benchmark_SRCS KoCompositeOpsBenchmark.cpp)
calligra_add_benchmark(KoCompositeOpsBenchmark TESTNAME 
pigment-benchmarks-KoCompositeOpsBenchmark ${ko_compositeops_benchmark_SRCS})
-target_link_libraries(KoCompositeOpsBenchmark pigmentcms KF5::I18n 
KF5::KDELibs4Support Qt5::Test)
+target_link_libraries(KoCompositeOpsBenchmark pigmentcms KF5::I18n Qt5::Test)

diff --git a/libs/pigment/tests/CMakeLists.txt 
b/libs/pigment/tests/CMakeLists.txt
index 5fb86f9..c80aae2 100644
--- a/libs/pigment/tests/CMakeLists.txt
+++ b/libs/pigment/tests/CMakeLists.txt
@@ -15,7 +15,7 @@ set(TestKoColorSpaceRegistry_test_SRCS 
TestKoColorSpaceRegistry.cpp )

kde4_add_unit_test(TestKoColorSpaceRegistry TESTNAME 
libs-pigment-TestKoColorSpaceRegistry ${TestKoColorSpaceRegistry_test_SRCS})

-target_link_libraries(TestKoColorSpaceRegistry pigmentcms KF5::I18n 
KF5::KDELibs4Support Qt5::Test)
+target_link_libraries(TestKoColorSpaceRegistry pigmentcms KF5::I18n Qt5::Test)

### next target ###

@@ -31,7 +31,7 @@ set(TestKoColorSpaceAbstract_test_SRCS 
TestKoColorSpaceAbstract.cpp )

kde4_add_unit_test(TestKoColorSpaceAbstract TESTNAME 
libs-pigment-TestKoColorSpaceAbstract ${TestKoColorSpaceAbstract_test_SRCS})

-target_link_libraries(TestKoColorSpaceAbstract pigmentcms KF5::I18n 
KF5::KDELibs4Support Qt5::Test)
+target_link_libraries(TestKoColorSpaceAbstract pigmentcms KF5::I18n Qt5::Test)

### next target ###

@@ -44,7 +44,7 @@ target_link_libraries(TestKoColorSpaceMaths pigmentcms 
Qt5::Test)
### next target ###
set(CCSGraph_GRAPH CCSGraph.cpp)
kde4_add_executable(CCSGraph ${CCSGraph_GRAPH})
-target_link_libraries(CCSGraph pigmentcms KF5::I18n KF5::KDELibs4Support)
+target_link_libraries(CCSGraph pigmentcms KF5::I18n )

### next target ###

@@ -52,7 +52,7 @@ set(TestColorConversionSystem_test_SRCS 
TestColorConversionSystem.cpp )

kde4_add_unit_test(TestColorConversionSystem TESTNAME 
libs-pigment-TestColorConversionSystem ${TestColorConversionSystem_test_SRCS})

-target_link_libraries(TestColorConversionSystem pigmentcms KF5::I18n 
KF5::KDELibs4Support Qt5::Test)
+target_link_libraries(TestColorConversionSystem pigmentcms KF5::I18n Qt5::Test)

### next target ###

@@ -60,14 +60,14 @@ set(TestKoColor_test_SRCS TestKoColor.cpp )

kde4_add_unit_test(TestKoColor TESTNAME libs-pigment-TestKoColor 
${TestKoColor_test_SRCS})

-target_link_libraries(TestKoColor pigmentcms KF5::I18n KF5::KDELibs4Support 
Qt5::Test)
+target_link_libraries(TestKoColor pigmentcms KF5::I18n Qt5::Test)


### next target ###

set(TestKoIntegerMaths_test_SRCS TestKoIntegerMaths.cpp

Re: Coding standard for qdebug in libs

[Boudewijn Rempt]

On Tue, 8 Sep 2015, Jaroslaw Staniek wrote:


On 8 September 2015 at 21:31, Friedrich W. H. Kossebau  wrote:

Am Samstag, 5. September 2015, 12:55:28 schrieb Jaroslaw Staniek:

With increasing modularity it's quite important
for our debugging needs to have logging categories.


Agreed.


A scheme could be like
{libnamelowercase}{Debug|Warning|Critical}()


+1 for that scheme. Simply because that namespace-prefixing seems to match the
usual namespace-prefixing as done with classes/files, don't see another reason
for/against.


I also propose to use a libname prefix for the header name. This is
what many bits in KF5 do. So we won't have to deal with dozens files
prefixed with "Debug" soon (so libpigment's DebugPigment.h could
become PigmentDebug.h or pigment_debug.h).


That's sort of fine, I don't have a real preference there. I still think that
having one debug category per library is a limitation, and we'll need categories
for debugging functional areas, not libraries, and funcational areas over-arch
libaries (whether that's good architecture, I don't know...)



When I looked into debug porting for libs/ last week (still need to complete
end of next week, so anyone wants to take over meanwhile? no code yet written
here), I wondered if installed headers better should not include any debug-
only headers at all.


*debug.h should not be installed. I see that KF5 does not install own headers.


But with publix/exported templates which need/better have debug statements
that might be unavoidable. Still not really sure though, it somehow seems
dirty to me :)


Is there at least such a case in calligra.git? We can add a template
specialization and keep the implementation in .cpp.


KoResourceLoader, I think.

I'm now porting libs to qCDebug. After thinking about it a bit,
I really, really, really don't like

vectorImageDebug(),

I think that

debugVectorImage()

is clearer and more grammatical as well. That may just be because we've 
had dbgCategory in Krita for ten years now, but this is the form I would

prefer to use.


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

Re: Coding standard for qdebug in libs

[Boudewijn Rempt]

Oh, and about the file names, looks like there's no real standard yet:

boud@linux:~/kf5/src/frameworks> find . -name \*Debug\*h
./kactivities/src/service/Debug.h
boud@linux:~/kf5/src/frameworks> find . -name \*debug\*h
./krunner/src/declarative/krunner_debug.h
./krunner/src/krunner_debug.h
./networkmanager-qt/src/nmdebug.h
./threadweaver/src/debuggingaids.h
./kio/src/core/kiocoredebug.h
./kauth/src/kauthdebug.h
./kactivities/src/lib/core/debug_p.h
./kservice/src/sycoca/sycocadebug.h
./kwindowsystem/src/debug_p.h
./kjobwidgets/src/debug.h
./kdelibs4support/autotests/kdebug_unittest.h
./kdelibs4support/src/kdecore/kdebugdbusiface_p.h
./kiconthemes/src/debug.h
./sonnet/src/plugins/hunspell/hunspelldebug.h
./sonnet/src/plugins/voikko/voikkodebug.h
./khtml/src/ecma/debugger/debugdocument.h
./khtml/src/ecma/debugger/debugwindow.h
./khtml/src/ecma/kjs_debugwin.h
./baloo/src/file/baloodebug.h
./modemmanager-qt/src/mmdebug_p.h
./kconfig/autotests/kconfig_compiler/test_qdebugcategory_debug.h
./ktexteditor/src/utils/katepartdebug.h
./bluez-qt/src/debug.h

But most of it seems lower-case.


On Mon, 14 Sep 2015, Boudewijn Rempt wrote:


On Tue, 8 Sep 2015, Jaroslaw Staniek wrote:

On 8 September 2015 at 21:31, Friedrich W. H. Kossebau <kosse...@kde.org> 

wrote:

Am Samstag, 5. September 2015, 12:55:28 schrieb Jaroslaw Staniek:

With increasing modularity it's quite important
for our debugging needs to have logging categories.


Agreed.


A scheme could be like
{libnamelowercase}{Debug|Warning|Critical}()


+1 for that scheme. Simply because that namespace-prefixing seems to match 

the
usual namespace-prefixing as done with classes/files, don't see another 

reason

for/against.


I also propose to use a libname prefix for the header name. This is
what many bits in KF5 do. So we won't have to deal with dozens files
prefixed with "Debug" soon (so libpigment's DebugPigment.h could
become PigmentDebug.h or pigment_debug.h).


That's sort of fine, I don't have a real preference there. I still think that
having one debug category per library is a limitation, and we'll need 
categories
for debugging functional areas, not libraries, and funcational areas 
over-arch

libaries (whether that's good architecture, I don't know...)



When I looked into debug porting for libs/ last week (still need to 

complete
end of next week, so anyone wants to take over meanwhile? no code yet 

written
here), I wondered if installed headers better should not include any 

debug-

only headers at all.


*debug.h should not be installed. I see that KF5 does not install own 

headers.



But with publix/exported templates which need/better have debug statements
that might be unavoidable. Still not really sure though, it somehow seems
dirty to me :)


Is there at least such a case in calligra.git? We can add a template
specialization and keep the implementation in .cpp.


KoResourceLoader, I think.

I'm now porting libs to qCDebug. After thinking about it a bit,
I really, really, really don't like

vectorImageDebug(),

I think that

debugVectorImage()

is clearer and more grammatical as well. That may just be because we've 
had dbgCategory in Krita for ten years now, but this is the form I would

prefer to use.


Boudewijn
___
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] /: Unport words and stage

[Boudewijn Rempt]

Git commit 43a5919cbadcd4b59f4a75448323ef70571209c0 by Boudewijn Rempt.
Committed on 11/09/2015 at 08:25.
Pushed by rempt into branch 'master'.

Unport words and stage

After porting libs and plugins from QAction to KAction and KShortcut
to QKeySequence, stage and words need to be ported again. It's mostly
a matter of running the kf5 convert script, but wherever QWidgetAction's
setDefaultWidget was used, it's more work.

CCMAIL:calligra-devel@kde.org

M  +2-2CalligraProducts.cmake

http://commits.kde.org/calligra/43a5919cbadcd4b59f4a75448323ef70571209c0

diff --git a/CalligraProducts.cmake b/CalligraProducts.cmake
index 700a919..933bbdb 100644
--- a/CalligraProducts.cmake
+++ b/CalligraProducts.cmake
@@ -82,8 +82,8 @@ calligra_define_feature(FEATURE_RDF "RDF feature")
 calligra_define_product(PLUGIN_TEXTSHAPE "Text shape plugin"  REQUIRES 
LIB_CALLIGRA)
 
 # parts
-calligra_define_product(PART_WORDS "Words engine"  REQUIRES LIB_CALLIGRA 
LIB_KOMAIN PLUGIN_TEXTSHAPE)
-calligra_define_product(PART_STAGE "Stage engine"  REQUIRES LIB_CALLIGRA 
LIB_KOMAIN LIB_KOPAGEAPP)
+calligra_define_product(PART_WORDS "Words engine" UNPORTED REQUIRES 
LIB_CALLIGRA LIB_KOMAIN PLUGIN_TEXTSHAPE)
+calligra_define_product(PART_STAGE "Stage engine" UNPORTED REQUIRES 
LIB_CALLIGRA LIB_KOMAIN LIB_KOPAGEAPP)
 calligra_define_product(PART_SHEETS "Sheets engine" UNPORTED REQUIRES 
LIB_CALLIGRA LIB_KOMAIN)
 calligra_define_product(PART_QTQUICK "QtQuick Plugin that provides Calligra 
components" UNPORTED REQUIRES PART_WORDS PART_STAGE)# SHEETS_PART)
 
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: [calligra] /: Unport words and stage

[Boudewijn Rempt]

On Fri, 11 Sep 2015, Friedrich W. H. Kossebau wrote:


Am Freitag, 11. September 2015, 08:26:41 schrieb Boudewijn Rempt:

Git commit 43a5919cbadcd4b59f4a75448323ef70571209c0 by Boudewijn Rempt.
Committed on 11/09/2015 at 08:25.
Pushed by rempt into branch 'master'.

Unport words and stage


Ported again :)


Nice! I'm on the verge of breaking them again, though... With a kicon->qicon
change :-)

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

[calligra] /: Unport words, stage and sheets again

[Boudewijn Rempt]

Git commit 820adc96cda98f0f47c4077213e239402e33f03e by Boudewijn Rempt.
Committed on 11/09/2015 at 13:13.
Pushed by rempt into branch 'master'.

Unport words, stage and sheets again

They need to be ported from KIcon to QIcon now...

CCMAIL:calligra-devel@kde.org

M  +3-3CalligraProducts.cmake

http://commits.kde.org/calligra/820adc96cda98f0f47c4077213e239402e33f03e

diff --git a/CalligraProducts.cmake b/CalligraProducts.cmake
index b9c9c3e..8a46b03 100644
--- a/CalligraProducts.cmake
+++ b/CalligraProducts.cmake
@@ -82,9 +82,9 @@ calligra_define_feature(FEATURE_RDF "RDF feature")
 calligra_define_product(PLUGIN_TEXTSHAPE "Text shape plugin"  REQUIRES 
LIB_CALLIGRA)
 
 # parts
-calligra_define_product(PART_WORDS "Words engine"  REQUIRES LIB_CALLIGRA 
LIB_KOMAIN PLUGIN_TEXTSHAPE)
-calligra_define_product(PART_STAGE "Stage engine"  REQUIRES LIB_CALLIGRA 
LIB_KOMAIN LIB_KOPAGEAPP)
-calligra_define_product(PART_SHEETS "Sheets engine" REQUIRES LIB_CALLIGRA 
LIB_KOMAIN)
+calligra_define_product(PART_WORDS "Words engine" UNPORTED  REQUIRES 
LIB_CALLIGRA LIB_KOMAIN PLUGIN_TEXTSHAPE)
+calligra_define_product(PART_STAGE "Stage engine"  UNPORTED REQUIRES 
LIB_CALLIGRA LIB_KOMAIN LIB_KOPAGEAPP)
+calligra_define_product(PART_SHEETS "Sheets engine"  UNPORTED REQUIRES 
LIB_CALLIGRA LIB_KOMAIN)
 calligra_define_product(PART_QTQUICK "QtQuick Plugin that provides Calligra 
components"  REQUIRES PART_WORDS PART_STAGE)# SHEETS_PART)
 calligra_define_product(PART_COMPONENTS "QtQuick2 Plugin that provides 
Calligra components"  REQUIRES PART_WORDS PART_STAGE PART_SHEETS)
 
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

[calligra] /: Port libs from KUrl to QUrl

[Boudewijn Rempt]

Git commit defb836a63608335988184e5ed0590588728f8be by Boudewijn Rempt.
Committed on 10/09/2015 at 09:41.
Pushed by rempt into branch 'master'.

Port libs from KUrl to QUrl

This means that several applications are back to unported status:

Sheets engine
QtQuick components
Karbon
Calligra Converter
Thumbnailer
Okular plugins

CCMAIL:calligra-devel@kde.org
CCMAIL:kimages...@kde.org

It's also a really invasive change, so please help with testing...

M  +9-9CalligraProducts.cmake
M  +1-1libs/kokross/KoScriptManager.cpp
M  +2-2libs/kokross/KoScriptManagerAdd.cpp
M  +1-1libs/kokross/KoScriptingPart.cpp
M  +1-1libs/kopageapp/KoPADocument.cpp
M  +9-9libs/kopageapp/KoPAView.cpp
M  +2-2libs/kopageapp/KoPAView.h
M  +2-2libs/kopageapp/tools/backgroundTool/KoPABackgroundToolWidget.cpp
M  +6-6libs/main/KoApplication.cpp
M  +2-2libs/main/KoDetailsPane.h
M  +36   -36   libs/main/KoDocument.cpp
M  +9-9libs/main/KoDocument.h
M  +1-1libs/main/KoFilter.cpp
M  +1-1libs/main/KoFilterChain.cpp
M  +2-2libs/main/KoFilterManager.cpp
M  +1-1libs/main/KoFilterManager_p.cpp
M  +2-2libs/main/KoFilterManager_p.h
M  +31   -28   libs/main/KoMainWindow.cpp
M  +5-5libs/main/KoMainWindow.h
M  +4-4libs/main/KoOpenPane.cpp
M  +3-3libs/main/KoOpenPane.h
M  +9-9libs/main/KoPart.cpp
M  +4-4libs/main/KoPart.h
M  +2-2libs/main/KoPartAdaptor.cpp
M  +2-2libs/main/KoRecentDocumentsPane.cpp
M  +5-7libs/main/KoTemplateCreateDia.cpp
M  +2-2libs/main/KoTemplatesPane.cpp
M  +2-2libs/main/KoVersionDialog.cpp
M  +2-2libs/main/KoView.cpp
M  +1-1libs/widgets/KoDocumentInfoDlg.cpp
M  +2-2libs/widgets/KoDocumentInfoPropsPage.cpp
M  +1-1libs/widgets/KoFileDialog.cpp
M  +1-1libs/widgets/KoResourceItemChooser.cpp

http://commits.kde.org/calligra/defb836a63608335988184e5ed0590588728f8be

diff --git a/CalligraProducts.cmake b/CalligraProducts.cmake
index b110b4a..f14d118 100644
--- a/CalligraProducts.cmake
+++ b/CalligraProducts.cmake
@@ -84,15 +84,15 @@ calligra_define_product(PLUGIN_TEXTSHAPE "Text shape 
plugin"  REQUIRES LIB_CALLI
 # parts
 calligra_define_product(PART_WORDS "Words engine"  REQUIRES LIB_CALLIGRA 
LIB_KOMAIN PLUGIN_TEXTSHAPE)
 calligra_define_product(PART_STAGE "Stage engine"  REQUIRES LIB_CALLIGRA 
LIB_KOMAIN LIB_KOPAGEAPP)
-calligra_define_product(PART_SHEETS "Sheets engine"  REQUIRES LIB_CALLIGRA 
LIB_KOMAIN)
-calligra_define_product(PART_QTQUICK "QtQuick Plugin that provides Calligra 
components"  REQUIRES PART_WORDS PART_STAGE)# SHEETS_PART)
+calligra_define_product(PART_SHEETS "Sheets engine" UNPORTED REQUIRES 
LIB_CALLIGRA LIB_KOMAIN)
+calligra_define_product(PART_QTQUICK "QtQuick Plugin that provides Calligra 
components" UNPORTED REQUIRES PART_WORDS PART_STAGE)# SHEETS_PART)
 
 # apps
 calligra_define_product(APP_WORDS "Words app (for Desktop)"  REQUIRES 
PART_WORDS)
 calligra_define_product(APP_STAGE "Stage app (for Desktop)"  REQUIRES 
PART_STAGE)
-calligra_define_product(APP_SHEETS "Sheets app (for Desktop)"  REQUIRES 
PART_SHEETS)
+calligra_define_product(APP_SHEETS "Sheets app (for Desktop)" REQUIRES 
PART_SHEETS)
 calligra_define_product(APP_AUTHOR "Author app (for Desktop)"  REQUIRES 
PART_WORDS)
-calligra_define_product(APP_KARBON "Karbon app (for Desktop)"  REQUIRES 
LIB_CALLIGRA LIB_KOMAIN)
+calligra_define_product(APP_KARBON "Karbon app (for Desktop)"  UNPORTED 
REQUIRES LIB_CALLIGRA LIB_KOMAIN)
 calligra_define_product(APP_KRITA "Krita app (for Desktop)" REQUIRES 
LIB_CALLIGRA)
 calligra_define_product(APP_KEXI "Kexi app (for Desktop)" REQUIRES 
LIB_CALLIGRA)
 calligra_define_product(APP_FLOW "Flow app (for Desktop)" UNPORTED  REQUIRES 
LIB_CALLIGRA LIB_KOMAIN LIB_KOPAGEAPP)
@@ -103,13 +103,13 @@ calligra_define_product(APP_GEMINI "The Calligra Gemini 
application"  REQUIRES P
 calligra_define_product(DOC "Calligra Documentations" UNPORTED)
 
 # extras
-calligra_define_product(APP_CONVERTER "Format converter for commandline"  
REQUIRES LIB_CALLIGRA LIB_KOMAIN)
+calligra_define_product(APP_CONVERTER "Format converter for commandline" 
UNPORTED REQUIRES LIB_CALLIGRA LIB_KOMAIN)
 calligra_define_product(FILEMANAGER_PROPERTIES "Plugin for the KDE file 
properties dialog"  REQUIRES LIB_CALLIGRA)
-calligra_define_product(FILEMANAGER_THUMBNAIL "Plugins for KDE filesystem 
thumbnailing"  REQUIRES LIB_CALLIGRA LIB_KOMAIN)
+calligra_define_product(FILEMANAGER_THUMBNAIL "Plugins for KDE filesystem 
thumbnailing"  UNPORTED REQUIRES LIB_CALLIGRA LIB_KOMAIN)
 calligra_define_product(FILEMANAGER_QUICKPRINT "Plugin for the filemanager 
a

kurl->qurl

[Boudewijn Rempt]

Just fyi: I'm trying to port to QUrl now. It's going to take at least
another day, since this is not an easy one. I intend to port libs, plugins
and krita. Libs is necessary for all applications, but unfortunately,
most apps seem to need at least some porting, which I hope is something
others can help out with once I've been able to push the libs port.

I hope to get that done by tomorrow evening, I'm about half-way through
now.

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

Re: Just building 2.9 against stable things on CI, anyone objects?

[Boudewijn Rempt]

On Wed, 9 Sep 2015, Friedrich W. H. Kossebau wrote:

objects meanwhile and can tell an important reason to keep building both 
against stable-qt4 and latest-qt4 versions of other KDE project. Is there any 
external dependency from KDE which still changes a lot in the qt4 version?


No, that should be absolutely fine.

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

[calligracommon] [Bug 346421] Calligra 2.9.2 build fails (fwd)

[Boudewijn Rempt]

Is it okay to update to libwps 0.4? Or should we stay with 0.3 for now,
or would it make sense to check the version and make the code conditional?

This is the patch they're talking about in the bug report:

diff --git a/cmake/modules/FindLibWps.cmake b/cmake/modules/FindLibWps.cmake
index f8c8225..58ef2b5 100644
--- a/cmake/modules/FindLibWps.cmake
+++ b/cmake/modules/FindLibWps.cmake
@@ -10,16 +10,16 @@

 include(LibFindMacros)
 libfind_package(LIBWPS LibWpd)
-libfind_pkg_check_modules(LIBWPS_PKGCONF libwps-0.3)
+libfind_pkg_check_modules(LIBWPS_PKGCONF libwps-0.4)

 find_path(LIBWPS_INCLUDE_DIR
 NAMES libwps/libwps.h
 HINTS ${LIBWPS_PKGCONF_INCLUDE_DIRS} ${LIBWPS_PKGCONF_INCLUDEDIR}
-PATH_SUFFIXES libwps-0.3
+PATH_SUFFIXES libwps-0.4
 )

 find_library(LIBWPS_LIBRARY
-NAMES wps wps-0.3
+NAMES wps wps-0.4
 HINTS ${LIBWPS_PKGCONF_LIBRARY_DIRS} ${LIBWPS_PKGCONF_LIBDIR}
 )

diff --git a/filters/words/works/import/WPSImport.cpp 
b/filters/words/works/import/WPSImport.cpp
index eea2cc9..94b859d 100644
--- a/filters/words/works/import/WPSImport.cpp
+++ b/filters/words/works/import/WPSImport.cpp
@@ -91,7 +91,9 @@ public:
 bool isSupportedFormat(librevenge::RVNGInputStream )
 {
 WPSKind kind = WPS_TEXT;
-WPSConfidence confidence = WPSDocument::isFileFormatSupported(, 
kind);
+WPSCreator creator = WPS_MSWORKS;
+bool needsEncoding = false;
+WPSConfidence confidence = WPSDocument::isFileFormatSupported(, 
kind, creator, needsEncoding);
 if (confidence == WPS_CONFIDENCE_NONE || kind != WPS_TEXT)
 return false;
 return true;
lines 1-39/39 (END)



-- Forwarded message --
Date: Thu, 03 Sep 2015 14:51:25 +
From: Timo Gurr 
Reply-To: bug-cont...@bugs.kde.org
To: b...@valdyas.org
Subject: [calligracommon] [Bug 346421] Calligra 2.9.2 build fails

https://bugs.kde.org/show_bug.cgi?id=346421

Timo Gurr  changed:

   What|Removed |Added

 CC||timo.g...@gmail.com

--- Comment #11 from Timo Gurr  ---
(In reply to var.spool.mail700 from comment #10)

https://projects.archlinux.org/svntogit/packages.git/plain/trunk/libwps-0.4.
patch?h=packages/calligra

krita requires libwps 0.3 while arch has libwps 0.4


Would be really nice to see this patch applied because LibreOffice now requires
libwps[>=0.4.0] and Calligra still requires 0.3.

--
You are receiving this mail because:
You are on the CC list for the bug.
You are watching the assignee of the bug.
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Further 2.9.x release plan

[Boudewijn Rempt]

I'd say, once a month until 3.x is good enough for end users. The first week of 
every month would be good for me.


On Mon, 7 Sep 2015, Jaroslaw Staniek wrote:


Hi,
How many releases would you see for the 2.9 series?
Is it possible to deduce already?

And is October 7 for 2.9.8 a good fit for you?

--
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: Coding standard for qdebug in libs

[Boudewijn Rempt]

There is one more thing about logging using qCDebug and friends:
the logging categories are supposed to be defined _per library_.

Which is actually pretty useless and not really how we've been
using categories in Calligra. Logging categories for file
handling, resource management or plugin handling that can be used
across libraries and applications make it possible to focus on
debugging a path through the application's execution.

I don't debug pigment, I debug color management, for instance, which
is present in pigment, the colorspace plugin and parts of Krita.

That's why for Krita, I made a generic debug interface in a little
global library that knows about all the categories and that can
be used from everywhere.


Boudewijn


Oe Sat, 5 Sep 2015, Jaroslaw Staniek wrote:


Hi,
This is a proposal for some consistency for naming of debug functions,
debug headers and logging categories.
I'll be trying to achieve in code I maintain. I can put some
guidelines on the dev wiki.

Details:
After looking at recent commits such as Friedrich's 1dddbcdbceab0
"kWarning -> warnPigment" I was wondering if we want to have standards
for debug handling.
I don't use one in Kexi, not yet, but use one in
kdb/kreport/kproperty. With increasing modularity it's quite important
for our debugging needs to have logging categories.

A scheme could be like
{libnamelowercase}{Debug|Warning|Critical}()

e.g. I use kdbDebug() << ... ;

Note, for clarity () is used here too like in qDebug().
See kdb_debug.h https://quickgit.kde.org/?p=kdb.git=blob=src%2Fkdb_debug.h

Furthermore, in kde_debug.cpp
[https://quickgit.kde.org/?p=kdb.git=blob=src%2Fkdb_debug.cpp] I
have:
Q_LOGGING_CATEGORY(KDB_LOG, "org.kde.kdb.core")

Note that you can pick your scheme for string, e.g.
org.kde.calligra.{someapp} or org.calligra.{someapp}
and for libs org.kde.{somelib}. It's important to have it unique and
relatively short. Planning for future expansion is a good way too.

For tests and example apps it may be enough to use default debug or
for big code decide to add special category too.

I also propose to use a libname prefix for the header name. This is
what many bits in KF5 do. So we won't have to deal with dozens files
prefixed with "Debug" soon (so libpigment's DebugPigment.h could
become PigmentDebug.h or pigment_debug.h).

PS: I am aware e.g. KF5 has various approaches there, use qDebug()
with no categories, use qCDebug without defines.
We have not fully migrated to logging categories in apps and internal
libs so I thought it may be cool to think about consistency early
enough.

--
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: Big reformat of sources before unfreeze of master (was: Re: Schedule to switch back to master for feature development)

[Boudewijn Rempt]

On Mon, 31 Aug 2015, Friedrich W. H. Kossebau wrote:


Am Freitag, 28. August 2015, 19:18:18 schrieb 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:
> > * 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 any of the non-Krita maintainers want to do a cleanup of the coding 
style?


If not and it's only Krita where that should happen, could that be done after 
the split-off, Boud? Especially when you realize your plan to dump history and 
start out with a plain snapshot, that would then be a good time to also do the 
reformatting.


Yes, sure.



Yue, Jarosław, Tomas, Camilla, Leinir, anyone of you want to do a reformatting 
of any part of Calligra?


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: Big reformat of sources before unfreeze of master (was: Re: Schedule to switch back to master for feature development)

[Boudewijn Rempt]

On Mon, 31 Aug 2015, Boudewijn Rempt wrote:

To amplify a bit, why I want to do the reformat as part of the kf5
port: we'll be hitting pretty much every other line anyway, with K->Q
changes. And there are places where our inconsistenty really is unpleased,
for instance, all the places where we have fileName vs filename. I really
want to clean things like that up now as well, so we have a clean base
for the next ten years.

And that's why I think we'll be hitting almost all of the code anyway. But
it can wait until we're done merging the animation/lod things and until
the repo split is done.

Boudewijn
___
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:


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

[Differential] [Changed Subscribers] D235: KoSectionModel instead of KoSectionManager implemented (fwd)

[Boudewijn Rempt]

-- Forwarded message --
Date: Sun, 30 Aug 2015 21:34:38 +
From: "deniskuplyakov (Denis Kuplyakov)" 
Reply-To: d235+public+31544a239115b...@phabricator.kde.org
To: b...@valdyas.org
Subject: [Differential] [Changed Subscribers] D235: KoSectionModel instead of
KoSectionManager implemented

deniskuplyakov added a subscriber: Calligra: 3.0.
deniskuplyakov added a comment.

Still no reviews I know that everybody now is busy with code formatting / 
splitting repos and other important stuff, but I don't want my patch will be 
lost or need to be rewritten entirely. Can anybodu review, so I can push it 
before big changes?


REPOSITORY
  rCALLIGRA Calligra

REVISION DETAIL
  https://phabricator.kde.org/D235

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: deniskuplyakov, boemann, rempt
Cc: Calligra: 3.0
___
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: Big reformat of sources before unfreeze of master (was: Re: Schedule to switch back to master for feature development)

[Boudewijn Rempt]

On Sun, 30 Aug 2015, Dmitry Kazakov wrote:


Hi, Friedrich!

I have several points against total reformatting of everything.

1) We are planning to alpha-release LevelOfDetail and Animation functionality 
soon for users to test. And we cannot base this
version on Frameworks, because the latter one has no decent tablet support on 
Linux (Qt5 makes the line look jittery and we have no
decision yet how to fix that). So we cannot merge it in atm.


You _have_ to. You can't go on building the animation branch against 2.9
and expect to be able to merge it to master later on. There will be too
many changes, not just whitespace cleanups. It's a pity that tablet support
isn't fixed yet, but that's not a reason not to move feature development
to the master/kf5/qt5 branch. We'll have to make sure tablet support is 
good again anyway.



2) I am personally against of automated whitespace reformatting, because it 
pollutes history of files without any use. Includes,
slots, forward declarations reformattings are ok. Whitespace no.


There is a lot of use in whitespace cleanup: it makes the code
consistent and readable.


3) Renaming files into CamesCaseStyle.cpp instead of underscore_style.cpp will 
break my workflow. You have to expect me to spent at
least 2 working days on readjusting my workflow. I'm ok with it, though I would 
prefer to spend this time on something more useful
for Krita.


Well, we can do two things, after we've split up the repositories:
rename everything to camelcase, or everything to underscores. As
for me, Qt Creator makes it much easier to work with files that 
have the same names as the class themselves.


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

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: Removing Braindump, Calligra Active, MPP import filter on Sep. 2nd

[Boudewijn Rempt]

On Sun, 30 Aug 2015, Jaroslaw Staniek wrote:


How about a blog entry and sending the info to more kde mailing lists?


What would that achieve? Blogging about karbon going unmaintained has
had zero result. Worse... We have a patch for Braindump:

https://git.reviewboard.kde.org/r/123554/

But no-one to apply it.

There are other KF5 patches on reviewboard, too:

https://git.reviewboard.kde.org/r/123985/
https://git.reviewboard.kde.org/r/123943/

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

Re: Handling of splitted Calligra repos and API changes

[Boudewijn Rempt]

On Fri, 28 Aug 2015, Friedrich W. H. Kossebau wrote:


What do you think? Would this work for you as well?


I'd say that having a regular bump day would indeed be the best idea, 
say every Saturday morning. That would also work if we still decide

to split of other calligra libraries so they can be re-used. That
might work for KoOdf and KoStore to begin with?

Another thing is that we might want to consider adding those libraries
and krita/calligra to kdesrc-build?

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

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

[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: 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

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