Contributing again

[Dag]

Hi all,
looks like I will have some idle time over the summer, so I thought I 
might help getting 3.0 on the road.

Could somebody give directions on what's left, what has priority etc.
Probably not all apps will make it into 3.0?

I already had a look at plan and fixed a couple of crashes.
How is the commit/review policy atm?

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

RE: Contributing again

[Dag]

Thanks, both.
Sure is glad you are still around, tackling words would be a bit 
daunting ;)


I ran the tests in libs and got a couple of errors, e.g:

FAIL!  : TestXmlReader::testRootError() Compared values are not the same
   Actual   (errorMsg): "Ekstra 
indhold sidst i dokumentet."
   Expected (QString("Extra content at end of document.")): "Extra 
content at end of document."


I assume this is ok, just the returned errormsg is localized.
But, if I run in C locale, could this hide other problems?
I saw something in the git log about localized values in xml files.

and I get:
QFATAL : TestColorConversionSystem::testConnections() Test function 
timed out


Is this real, or can it be that my system is missing something?


Camilla Boemann skrev den 2016-07-01 10:00:

Hi and welcome back

I think the review policy is as ever, get it reviewed somehow if it
touches common areas.

We use phabricator as the online tool.

So glad to get this mail - I feel motivated to hack this weekend too
now - let's try and get this release going :)

Best regards
Camilla Boemann

-Original Message-
From: calligra-devel [mailto:calligra-devel-boun...@kde.org] On Behalf 
Of Dag

Sent: 1. juli 2016 09:22
To: calligra-devel@kde.org
Subject: Contributing again

Hi all,
looks like I will have some idle time over the summer, so I thought I
might help getting 3.0 on the road.
Could somebody give directions on what's left, what has priority etc.
Probably not all apps will make it into 3.0?

I already had a look at plan and fixed a couple of crashes.
How is the commit/review policy atm?

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

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

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

Re: state of release and release plan

[Dag]

Preliminary input for Plan. Note that I have not even open all views 
much less tried much functionality, so there may be (a lot) more...
Also, I'm on vacation 2 last weeks of july and 3. week of august, so 
expecting to be release ready in 1 month would be a bit optimistic ;)

That said, this is what I know of now:

Locale/datetime: This could be a difficult problem. A possible solution 
could be to use time_t internally/for calculations etc and convert to 
QDateTime for ui.


Locale/currency: Should not be a problem, just needs a way to set the 
currency to use for a project so it does not follow the users locale.


Kross/python: Scripting is used for some functionallity so python 
support is needed. (or else convert to javascript)


Reports/KReport:
Scripting is used for getting data from Project and ScheduleManager. 
Alternative to fix KReport is to implement a different way to get this 
info in Plan.


Report items Chart and Web has not afaics been ported yet.

Expects to know more on monday,
Dag

Camilla Boemann skrev den 2016-07-02 08:17:

Hi

I think it's time we get a release out. We are stuck with not much work 
going

on so inspired by Dag's return let's do a push to get ready.

I think we should cut down on the number of applications so we have 
something

manageble left. It's tough but the alternative is that Calligra dies
completely. And nothing prevents us from bringing apps back  later.

So my question is: What is missing for us to have a release. I am not 
talking
about all the nice to have features and bug fixes. I am asking what 
would

create huge problems for our users if we release.

Let's get things listed. I'll start:


Words: Nothing blocking

Stage: Nothing I'm aware of

Sheets: ???

Plan: the locale thing? how much would a quick fix take or should we 
just

exclude Plan from first release?

Karbon: let's exclude from first release

Flow: let's exclude from first release

Kexi: are they even a part of the release schedule anymore

Braindump: let's drop it completely


Common stuff: ???

please fill in

and let's get ready for a release in a month or so ? We need to set a 
short

deadline to keep motivation high

best regards
Camilla
___
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: Contributing again

[Dag]

Hi, Friedrich.

Friedrich W. H. Kossebau skrev den 2016-07-01 13:20:

Hi Dag,

happy to see you back and giving Plan (and hopefully more) some needed 
love.

Thanks.


When no-one had been found to take over maintenance, I felt Plan was 
some too
good software to just wipe it, so took it as some playground and had 
done some
what I considered "cleaning" and also tried to do the port to Qt5/KF5 
for it.
A lot of cleaning is very much needed, indeed. I will focus on the 
release for know but I have a few things I have thought about for some 
time we should maybe discuss a bit before you put too much effort into 
it.


So far I only roughly reached that porting goal. While everything 
builds and

works to some initial degree, there is at least one big issue:
during the port from KLocale (which is deprecated and in 
kdelibs4support) to
Qt5's QDateTime with built-in timezone support I very possibly missed 
some
scenarios and have broken something. At least the unit tests when run 
for
timezones closer to the daybreak (e.g. Canada) begin to fail, where 
they work
fine in European timezones. Also do the schedulers not return the same 
results

as in Plan 2.9 IIRC. Had not yet found the time to tackle that.
Intriging behaviour, haven't looked at it yet, but as said in my other 
post maybe using time_t in place of KDateTime could be a solution.


Then the support for currencies from KLocale is not (yet) covered by 
Qt5, an

Shouldn't be a problem, see my other post.
issue other projects like KMyMoney also face. No solution for that one 
besides
keeping use of KLocale. Just has the disadvantage that there is no 
systemwide
way to configure currency settings, as Plasma Systemsettings only 
supports
what is exposed in Qt. So default currency settings can be only taken 
from the

installed KLocale data. Not sure what to do here.
Next to that there are some crashes due to libKGantt, but seems you 
already

investigated there and fixed first (or all?), great :)

Have not looked at KGantt yet, the fixes where for KChart.


Am Freitag, 1. Juli 2016, 11:10:03 CEST schrieb Dag:

Thanks, both.
Sure is glad you are still around, tackling words would be a bit
daunting ;)

I ran the tests in libs and got a couple of errors, e.g:

FAIL!  : TestXmlReader::testRootError() Compared values are not the 
same

Actual   (errorMsg): "Ekstra
indhold sidst i dokumentet."
Expected (QString("Extra content at end of document.")): "Extra
content at end of document."

I assume this is ok, just the returned errormsg is localized.
But, if I run in C locale, could this hide other problems?
I saw something in the git log about localized values in xml files.


Oh, interesting, I never hit that one, perhaps I am missing some Qt
translation catalogs in my install (and KDE CI as well).
This test should rather see fixing IMHO. Running in C locale might very 
much
hide other problems, actually at least in Sheets & Plan we currently 
have some

tests failing due to locale problems.


and I get:
QFATAL : TestColorConversionSystem::testConnections() Test function
timed out

Is this real, or can it be that my system is missing something?


Timeout is real, yes. No idea yet what to do with too long running 
tests in

general (also an issue in Marble, Krita, etc.).
I tried to increase ctest --timeout to 500 seconds but that didn't make 
any difference so either its a different timeout, or its a bug in ctest.

Hmmm, maybe there is a way to send an "alive" signal to ctest?


I was to point to 
https://build.kde.org/view/Calligra/job/calligra%20master
%20kf5-qt5/PLATFORM=Linux,compiler=gcc/ for some reference when it 
comes to
failing tests (in Canadian/US timezone/locale) but these very minutes 
that is

done, hopefully back when you try the link.
(last build was reported by CI as failed due to kreport build product 
not
being updated to latest kproperty, because CI does not track 
inter-project

dependencies on builds yet)

WRT review policy I agree with Camilla, review only needed for common 
areas.
For Plan, even while I have committed a lot there in the recent months, 
I yet
have no complete picture of all code, so I bow to you here and will be 
happy
to see your commits going straight in and learn from them, while myself 
will
now have any Plan commits of mine passed by your eyes first (none 
planned the

next days though).

I personally would be happy to see Plan being brought into a working 
state
again, so it can be part of the 3.0 release. By the questions on the 
forums
and bug reports I saw there are still some people interested in 
something like

it. Not everyone is sold to doing planning with Web interfaces :)

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

_

Plan/KGantt

[Dag]

There are issues with KGantt that needs to fixed.
It seems to me KGantt was imported from KDAB right?
At least some of the enhancements made for Plan is not in KGantt. Some 
are but maybe those where sync'ed back to KDAB, I don't quite remember, 
it was a looong time ago.


Anyway, is it ok to merge the missing stuff into KGantt or is there 
other users that may have issues with that?

Afaics kdepim still has it's own copy, but there are maybe others?

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

Re: Plan/KGantt

[Dag]

Friedrich W. H. Kossebau skrev den 2016-07-04 14:32:

Am Montag, 4. Juli 2016, 14:05:58 CEST schrieb Dag:

There are issues with KGantt that needs to fixed.
It seems to me KGantt was imported from KDAB right?
At least some of the enhancements made for Plan is not in KGantt. Some
are but maybe those where sync'ed back to KDAB, I don't quite 
remember,

it was a looong time ago.


When KGantt (as part of KDiagram project) was created from a dump of 
then
latest state of KDGantt, I tried to go through all custom modifications 
done

to the Calligra fork of KDGantt and applied them to KGantt.
Of course possible I missed something :)

Which enhancements are you missing exactly?
Seems handling constraintitems when hide/delete taskitems is missing, 
along with year scale and zoom slider.
Also there are some paint issues with taskitems/itemtexts but that might 
be straight bugs.


And there is a crash but haven't investigated yet.



Anyway, is it ok to merge the missing stuff into KGantt or is there
other users that may have issues with that?
Afaics kdepim still has it's own copy, but there are maybe others?


Right now I do not know of any other users of KGantt itself (KChart is 
shared
with KMyMoney & Massif-Visualizer). And ideally the PIM people would 
start to
adapt to KGantt as well, that is the whole idea here, to reduce the 
number of

forks :)
Indeed, it would be nice to avoid doing this again, this is not the 
first time...


So should be fine to commit directly. There also was no release yet 
(high on
my TODO list to get this scheduled though), so no API to break yet 
(though

ideally only done on Mondays :) ).

Ok, will have a look at this tomorrow.


(In matters of KDE CI, when doing a ABI change, best first wait for 
KDiagram

build to have finished and only then push the respective changes to the
Calligra repo. That should save us a failed build of Calligra :) 
(because
right now there is no dependency tracking when it comes to ABI 
changes))


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: Plan/KGantt

[Dag]

Thanks, but we have a copy, which we hope will become the original also 
for kdepim (or anybody that needs a gantt chart)


Regards, Dag

Treeve Jelbert skrev den 2016-07-04 14:35:

On Mon, 04 Jul 2016 14:05:58 +0200, Dag wrote:

There are issues with KGantt that needs to fixed.
It seems to me KGantt was imported from KDAB right?
At least some of the enhancements made for Plan is not in KGantt.
Some are but maybe those where sync'ed back to KDAB, I don't quite
remember, it was a looong time ago.

Anyway, is it ok to merge the missing stuff into KGantt or is there
other users that may have issues with that?
Afaics kdepim still has it's own copy, but there are maybe others?



there is a released library kdgantt2
http://download.kde.org/stable/applications/16.04.2/src/kdgantt2-16.04.2.tar.xz

It might be possible to use that.

Regards, Treeve


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

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

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

Plan status

[Dag]

Vacation is going to hit soon, and plan is not ready...
It has been a frustrating week with too much time used on non-productive 
things, but progress *has* been made and I am fairly confident I will be 
able to have something mid august.


Regarding currency, does somebody know what is needed for sheets?
Plan doesn't need a lot, but I was thinking about lifting at least some 
of the code from kde4, if it isn't too much hassle.


Well, I'm off a couple of weeks, have a nice summer everybody!

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

Re: Plan status

[Dag]

Hi,
back from vacation...
Think I have cracked the port away from KDateTime, so soon ready to 
tackle currency.
If nobody else (sheets) plans to do something, I will probably go with a 
minimum solution, with a slight loss of functionality, and wait for 
QLocale.


Tomas Mecir skrev den 2016-07-19 12:27:

Apologies about a delayed reply, just got back from a vacation myself.

For Sheets, the money formatting routines are the issue where we still
need to rely on kde4support -
https://mail.kde.org/pipermail/calligra-devel/2016-January/015746.html
has some info.

Yeah, well seems like quite a bit of work for full implementation.
Does it mean release with kde4support and wait for QLocale,
or do you have other plans?

Cheers, Dag




2016-07-15 14:10 GMT+02:00 Dag :

Vacation is going to hit soon, and plan is not ready...
It has been a frustrating week with too much time used on 
non-productive
things, but progress *has* been made and I am fairly confident I will 
be

able to have something mid august.

Regarding currency, does somebody know what is needed for sheets?
Plan doesn't need a lot, but I was thinking about lifting at least 
some of

the code from kde4, if it isn't too much hassle.

Well, I'm off a couple of weeks, have a nice summer everybody!

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

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

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

Re: state of release and release plan

[Dag]

Ping...
Any news, or are most still on vacation?

As for Plan, I think I should be able to have something beta like early 
september.

(Have a week vacation in there, but still.)
Dag

Camilla Boemann skrev den 2016-07-02 08:17:

Hi

I think it's time we get a release out. We are stuck with not much work 
going

on so inspired by Dag's return let's do a push to get ready.

I think we should cut down on the number of applications so we have 
something

manageble left. It's tough but the alternative is that Calligra dies
completely. And nothing prevents us from bringing apps back  later.

So my question is: What is missing for us to have a release. I am not 
talking
about all the nice to have features and bug fixes. I am asking what 
would

create huge problems for our users if we release.

Let's get things listed. I'll start:


Words: Nothing blocking

Stage: Nothing I'm aware of

Sheets: ???

Plan: the locale thing? how much would a quick fix take or should we 
just

exclude Plan from first release?

Karbon: let's exclude from first release

Flow: let's exclude from first release

Kexi: are they even a part of the release schedule anymore

Braindump: let's drop it completely


Common stuff: ???

please fill in

and let's get ready for a release in a month or so ? We need to set a 
short

deadline to keep motivation high

best regards
Camilla
___
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: state of release and release plan

[Dag]

Pau Garcia i Quiles skrev den 2016-08-02 17:17:

On Sat, Jul 2, 2016 at 8:37 PM, Dag  wrote:


Kross/python: Scripting is used for some functionallity so python
support is needed. (or else convert to javascript)


I would really prefer JavaScript (QJsEngine), as Kross does not work
on Windows.

Also, if a Plan user wants to implement some functionality, JavaScript
would looks less intimidating. After all, Plan users are Project
Managers, not developers.
Well, kross gives (gave) options (also javascript) but you will not get 
a big argument from me.
I have other ideas how to implement current functionality but that has 
to wait for later...


Cheers, Dag



--
Pau Garcia i Quiles
http://www.elpauer.org

___
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

KoResourcePaths fails

[Dag]

It seems to me KoResourcePaths fails to find anything but standard 
locations,

at least Plan ends up in "data" (QStandardPaths::GenericDataLocation).
Also krita has a much updated version, I see.
Anybody in-the-know?

Cheers, Dag

Qt version

[Dag]

I added a 5.7 specific thing recently, which prompts the question:
which qt version will be used in the release?

Cheers, Dag

Re: Qt version

[Dag]

Ok, ifdef it is.

Jaroslaw Staniek skrev den 2016-08-10 14:49:

I think traditionally even 5.6+ -only things shall be ifdef'd.

I am sure 5.7+ things *should* be and the code should compile with
5.5.

(Assuming we're targeting LTS distros and alike that may even have
5.3, which is a reasonable minimum required by calligra master now.)

On 10 August 2016 at 14:30, Camilla Boemann  wrote:


My build machine (debian) is still 5.6 so until they are at 5.7 I
cannot
agree to bumping higher than 5.6

-Original Message-
From: calligra-devel [mailto:calligra-devel-boun...@kde.org] On
Behalf Of
Dag
Sent: 10. august 2016 14:27
To: calligra-devel@kde.org
Subject: Qt version

I added a 5.7 specific thing recently, which prompts the question:
which qt version will be used in the release?

Cheers, Dag


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

2.9 bug fix release?

[Dag]

There is a crash and some other bugs in Plan 2.9.
Any plans for a new release?

Cheers, Dag

push mistake

[Dag]

Accidentally pushed to new branch 2.9 (using git push origin 2.9)
I don't think I have access to remove it, so could somebody do that?

Also, to not make another mess, it is:
git push origin calligra/2.9
I should have used?

Cheers, Dag

Re: KoResourcePaths fails

[Dag]

Ok, had a closer look at this, and afaics everyting with wildcards does 
not work, and that is used many places.

If nobody objects, I'll see if I can get it working.

Dag skrev den 2016-08-10 14:24:
It seems to me KoResourcePaths fails to find anything but standard 
locations,

at least Plan ends up in "data" (QStandardPaths::GenericDataLocation).
Also krita has a much updated version, I see.
Anybody in-the-know?

Cheers, Dag

Review of resource types/paths

[Dag]

I have worked on resource paths lately, and that prompts me to suggest a 
review how this is used in calligra.

I have noticed the following:

* generally apps do:
KoResourcePaths::addResourceType("sheet-styles", "data", 
"calligrasheets/sheetstyles/")


Qt can find the apps directory so a better way (imo) would be:
KoResourcePaths::addResourceType("sheet-styles", "appdata", 
"sheetstyles/")


According to qt docs the first will not be compatible with all 
platforms.


* common calligra resources like calligra/thesarus is now got at by eg:
KoResourcePaths::findResource("data", 
"calligra/thesaurus/thesaurus.txt"));

A better (imho) would be to add a thesaurus resource type:
KoResourcePaths::addResourceType("calligra_thesaurus", "data", 
"calligra/thesaurus")

and then all could get it by:
KoResourcePaths::findResource("calligra_thesaurus", "thesaurus.txt"));

This eases maintenance if for some reason they must be moved later.

* There are some absolute paths to gimp files like:
KoResourcePaths::addResourceDir("ko_patterns", 
"/usr/share/create/patterns/gimp");
This is of course not platform agnostic, so is it possible with better 
solution?

Is it neccessary, now that krita is gone?

Cheers, Dag

review of resourcepaths patch added to phabricator

[Dag]

Add a patch for review some time ago, but have had no answers, so start 
to wonder if reviewers has bee notified at all.
Thought I added all, but can't really find out through phabricator, so 
consider this a ping :)


Also, if somebody has a good workflow for this, please give me some 
hints!


Cheers, Dag

Re: 3.0 Beta releases, compatibility

[Dag]

Can't give you much advice on releases ;)
but +1 for stable releases, so we can avoid the odd regression we've 
seen in the past.
KReport / KProperty is used in Plan so would be nice to have any planned 
API/ABI changes in before release.


Cheers, Dag

Jaroslaw Staniek skrev den 2016-08-31 10:45:

Hello,
KDE Akademy[1] is starting so I thought it might be a good point to
push the Beta release button for Kexi and related frameworks:

KDb
KProperty
KReport (depends on KProperty)

tl;dr:
- we need source distribution of Kexi and the 3 frameworks to get more
users and contributors
- we need to find a way for the frameworks to serve both for Kexi
needs and general user
- when: release process takes about two weeks, let's add extra week
for a bootstrap of this process

Details.

As some of us are aware there are 4 repositories in the Kexi family.
We are no longer "outsourcing" the hard release work to general
calligra, so there's specific work to do. At first it takes some more
effort I think. I'll be looking at scripts such from releaseme.git or
kde-dev-scripts.git.
Advices are welcome here (Boudewijn has offered useful advice already
based on the experience with Krita releases).

Despite extra work, there are advantages of the separate releases,
more control and possibility of finer-grained releases, not a "release
all or nothing" scheme. Please note this is about the first level of
releases - source code and message translation files. Binaries would
appear thanks to distributors and separate work for Windows.

The three frameworks have various level of maturity, based on
attention; I'd say the most prepared is KDb, then KProperty, then
KReport. This especially apply to API and ABI guarantees (e.g. see
[2])


== How to version ==

And here's a challenge: at the moment the main consumer of the
frameworks is Kexi. Later it shouldn't be like that, otherwise we
could release a bundled source code based on all 4 repositories.
There's some consumption of KReport and KProperty in the Calligra Plan
app. that's it. It may be that someone plays or even uses git versions
of the code but that was not noticed.

So since Kexi is the major consumer, current development priorities
for the frameworks are rather Kexi-specific and sometimes it's hard to
keep (or justify fighting for) backward compatibility. A recent
example is an (August) merge of the Kexi's migration API that formed a
lower-level database access APIs for KDb. It's already in master
branch. Fortunately such moves become more rare over time.

So how to organize development of the frameworks: not blocking
development of features or fixes important for Kexi and staying
(binary) backward compatible? I thought of one approach:

- Version 3.x of the frameworks becomes binary compatible on first
stable release

- Version 4.x of the frameworks come into life as soon as needed by
Kexi and incompatible changes happen there, the version would carry
the "Beta" stamp for a long time to emphasize that there's no
compatibility guarantee

- Kexi 3.0 gets released as depending on 3.x initially and would
switch to 4.x when a need for incompatible changes in framework
appears

- Co-installability of 3.x and 4.x is assured, 4.x will never be an
upgrade for 3.x (a bit similar to situation with libPNG 12, 14, 16)

This way we have any chance to see users of the frameworks distributed 
and used.



== Q & A ==
Q: Why not push the frameworks to the KDE Frameworks 5 family?
A: Maybe one day but now it's too early and the workforce is too 
limited.


[1] https://akademy.kde.org (I am just present there in spirit...)
[2] 
https://community.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B

Re: state of release and release plan

[Dag]

Hi
Another month came and went, and not much happened...
I'm actually a little afraid of releasing because we might attract some 
users.
Well, to be more precise, that there will be nobody to support those 
users.
An example; a user posed a question about words on the forum close to 2 
months ago, still no answer.
I don't know enough to determine if the problem he ahs is just a matter 
of doing it the right way or if it is a bug or a limitation in odt or 
something else. It would take me a lot of time to find out so it would 
be much better if someone in the know (eg Camilla) could have answered.


I would support plan of course, but what about words and sheets?
Camila and Tomas; what are you able to commit to, are there others?
I'm willing to set aside other stuff I'm working on to help, but I would 
need guidance to get anything done in a reasonable time and reviews of 
course, so I don't mess up too much.


Also, not to be forgotten, KChart and KGantt needs to be released.

Cheers, Dag.

Friedrich W. H. Kossebau skrev den 2016-09-20 01:33:

Hi,

Am Samstag, 2. Juli 2016, 08:17:40 CEST schrieb Camilla Boemann:

I think it's time we get a release out. We are stuck with not much 
work

going on so inspired by Dag's return let's do a push to get ready.

I think we should cut down on the number of applications so we have
something manageble left. It's tough but the alternative is that 
Calligra
dies completely. And nothing prevents us from bringing apps back  
later.


So my question is: What is missing for us to have a release. I am not
talking about all the nice to have features and bug fixes. I am asking 
what

would create huge problems for our users if we release.

Let's get things listed. I'll start:



Karbon: let's exclude from first release


From my testing it mainly works, so no real difference to Stage or 
Words IMHO

So I would vote for include. Perhaps mark as experimental.


Flow: let's exclude from first release


Agreed. There would be also nothing to release :) Flow has not been 
ported
even, as the plan of its maintainer was to make Flow another UI to the 
Karbon
libs, optimized for Flow-specific use-cases. Just, has not happened 
yet.



Braindump: let's drop it completely


It has been ported, build and works. Pity for the work done there. But 
agreed.

No maintainer, no users known. Time tp git rm.

Gemini:
incomplete port to QtQuick2 -> not part of release, already marked as 
STAGING


Format Filters:
guess anything that builds is on similar state as with 2.9. At least 
all my

test files still work.

Okular plugins:
depend on unreleased Okular/KF5, work with current devel branch.
so fine keep included in release builds.
Okular/KF5 might be finally in KA 16.12

Other extras:
thumbnail etc. also work, so no reason to exclude

Cheers
Friedrich

KDiagram

[Dag]

Hi Friedrich.
First, a big thanks for the enormous amount of work you have put in to 
port to qt5/kf5.


As for KDiagram, I have a few issues.

KChart:
When I remove or add datasets, the labels are not updated. Labels are 
updated if I refresh the chart so it can clearly be fixed from outside 
KChart, so no big issue.


KGantt:
Printing on multiple pages seems to be possible only "horizontally" as I 
can specify a time span to print.
However, if I have more tasks than can fit on one page "vertically" the 
printout is scaled to fit the page. I can't see how I can split this on 
multiple pages.

I think this requires new API.

Zooming in/out switches between different time scales to make it easier 
for user to see where he is. The switching isn't optimal most notably in 
the low end (Day/Hour) and in the high end (Year/Month). Inge made a 
very useful layout for Year/Day in 2.x but KDAB has totally rewritten 
this part of the code so we can't use it :(
They have also added api to add a custom layout, which could be useful, 
but maybe we should make it possible to set layouts for all cases.
I would suspect kontact would have an issue with the Day/Hour layout 
too.


Cheers, Dag

Need some help with styles

[Dag]

Hi, I'm tracking a bug in Sheets style handling but I'm uncertain of how 
to fix it because I don't understand the code alt. how styles should 
work.


I thought default styles where used when there was no style assigned to 
an object, and *maybe* used to give default values for things not 
specified in a style (but I thought parent style where used for that)?


In Odf::loadSheetInsertStyles()
we have code like this:
if (autoStyles.contains(styleNames[i])) {
Style style;
style.setDefault(); // "overwrite" existing style
style.merge(autoStyles[styleNames[i]]);
outStyleRegions.append(qMakePair(styleRegion, style));
} else {

which effectivly adds a default sub style to the autostyle.

Then there is the comment: // "overwrite" existing style
What can that mean?

Later a new style is composed based on this style with code in:
StyleStorage::composeStyle()

for (int i = 0; i < subStyles.count(); ++i) {
if (subStyles[i]->type() == Style::DefaultStyleKey) {
style = *styleManager()->defaultStyle();
qDebug()<type() == Style::NamedStyleKey) {
etc. (adding the different substyles)

One problem here is that the position of the default substyle in the 
list seems to be random, and since all substyles positioned *before* the 
default substyle is forgotten about, the resulting style is also random.


Boudewijn, git blame says you added this in 2009, I'm sure you can 
remember why? It is only 7 years ago :)


The way I hit this was to format a number as scientific and then 
save/load; sometimes it is formatted as scientific, other times as a 
float.


Cheers, Dag

Re: state of release and release plan

[Dag]

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?


Tomas Mecir skrev den 2016-10-26 14:58:

2016-10-26 14:03 GMT+02:00 Dag :

I would support plan of course, but what about words and sheets?
Camila and Tomas; what are you able to commit to, are there others?


Varies. Bit more busy the last few months, will be better soonish. But
still interested, ya. Sheets is in a decent shape, some things to sort
out still, but nothing huge. Obviously there always are a lot of
things that could be added/improved.

Tomas

Re: Need some help with styles

[Dag]

Jos van den Oever skrev den 2016-11-08 16:24:

Hello Dag,

The way the inhertance works is described here:
http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#__RefHeading__1416276_253892949

Yes, this looks fairly sane, thanks.


Roughly, if a style does not define a property, there are quite a few 
places
where the code can look to find a value. First it looks in the parent 
styles.
If those do not define the property, that style of the parent element 
(and it's
parent styles) are queried. If that leads nowhere, the 


comes into play and only then should the code resort to using an
implementation specific default value.
I think Sheets are close to doing this, except for the case I outline 
below but I have to look at it again with a clear head.

Thanks again.



Cheers,
Jos


On Tuesday 08 November 2016 14:25:54 Dag wrote:
Hi, I'm tracking a bug in Sheets style handling but I'm uncertain of 
how

to fix it because I don't understand the code alt. how styles should
work.

I thought default styles where used when there was no style assigned 
to

an object, and *maybe* used to give default values for things not
specified in a style (but I thought parent style where used for that)?

In Odf::loadSheetInsertStyles()
we have code like this:
 if (autoStyles.contains(styleNames[i])) {
 Style style;
 style.setDefault(); // "overwrite" existing style
 style.merge(autoStyles[styleNames[i]]);
 outStyleRegions.append(qMakePair(styleRegion, style));
 } else {

which effectivly adds a default sub style to the autostyle.

Then there is the comment: // "overwrite" existing style
What can that mean?

Later a new style is composed based on this style with code in:
StyleStorage::composeStyle()

 for (int i = 0; i < subStyles.count(); ++i) {
 if (subStyles[i]->type() == Style::DefaultStyleKey) {
 style = *styleManager()->defaultStyle();
 qDebug()<type() == Style::NamedStyleKey) {
 etc. (adding the different substyles)

One problem here is that the position of the default substyle in the
list seems to be random, and since all substyles positioned *before* 
the
default substyle is forgotten about, the resulting style is also 
random.


Boudewijn, git blame says you added this in 2009, I'm sure you can
remember why? It is only 7 years ago :)

The way I hit this was to format a number as scientific and then
save/load; sometimes it is formatted as scientific, other times as a
float.

Cheers, Dag

cmake kreport jenkins

[Dag]

How to find the correct version of KReport?
Plan needs 3.0 and cannot use 3.1. I tried EXACT like this:
macro_optional_find_package(KReport 3.0.0 EXACT QUIET)
and this works but it would be nice to be able to find latest 3.0.x

Also jenkins uses latest KReport 3.1, so plan is not build atm.
How can this be fixed?

Cheers,
Dag

Re: state of release and release plan

[Dag]

Boudewijn Rempt skrev den 2016-11-11 15:16:

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.

Thanks, that's very nice of you, Boudewijn.
It might take a bit of time still. With the amount of serious bug 
reports on 2.9.11, there is quite a bit of testing needed :(


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.

Yes, well, we'll tackle it when we get there...

Re: cmake kreport jenkins

[Dag]

Adam Pigg skrev den 2016-11-12 14:52:

Port to kreport 3.1? Actually, dont do that as its not even ready.  Im
trying to make the 3.1 release the one that is binary compatible into
the future, so, when it is ready I would recommend switching to 3.1.
When it ready, yes. It was made co-installable to avoid plan aiming for 
a moving target.


What does macro_optional_find_package(KReport 3.0 QUIET) do?

Tried it, but it didn't work :(


On Sat, 12 Nov 2016 at 09:39 Dag  wrote:


How to find the correct version of KReport?
Plan needs 3.0 and cannot use 3.1. I tried EXACT like this:
macro_optional_find_package(KReport 3.0.0 EXACT QUIET)
and this works but it would be nice to be able to find latest 3.0.x

Also jenkins uses latest KReport 3.1, so plan is not build atm.
How can this be fixed?

Cheers,
Dag

Release, again

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

Also we are not releasing all apps, how do we handle that?
What about translations? I have a couple of new strings in plan, but I 
wouldn't loose much sleep if they were not translated for 3.0.


Then after release, do we work in master AND the 3.0 branch or should we 
maybe just work on master.
If we restrict to bug fixes we could maybe just use master? What do you 
think?


I'm away on a long weekend tomorrow, back on Wednesday.

Cheers,
Dag

Re: Release, again

[Dag]

Friedrich W. H. Kossebau skrev den 2016-11-25 15:00:

Hi Dag,

Translators prefer to be notified about upcoming release (which also 
means
frozen strings then) at least one week or better more. So if you 
schedule the
tarball creation for, say, December 4th and tell them immediately, that 
might
give them the change to brush over the strings catalogs a little (best 
also

tell which catalogs belong to staging products so do not need attention
currently).

Done.
So guys, we are in string freeze!



Then after release, do we work in master AND the 3.0 branch or should 
we

maybe just work on master.
If we restrict to bug fixes we could maybe just use master? What do 
you

think?


Given the amount of developer power currently a separate 3.0 branch 
would need
too much attention which nobody might have while working on master. So 
perhaps

having master as continous release branch where both bug fixes and new
features (but only completed ones) are committed would be the best for 
now to
ensure quality in what is released. As this way all developers see the 
branch
and their issues most of the time (when not in a personal feature 
branch).
Yes, my feeling, too. And with the number of developers atm, I don't 
think we will get past bug fixing for some time anyway.




Cheers
Friedrich

Re: calligra release planned for 04-12-2016

[Dag]

Hi Albert.
Found the "syntax error" in the calligra part we releases now, the rest 
is in kexi.
It seems either xgettext chokes on a long context or (more likely) 
calligra_xgettext.sh chokes on the msg xgettext produces. Shorting the 
msg by 1 character did the trick.


But: it seems calligra_xgettext.sh adds (qtundo-format) to (almost?) all 
messages, effectively doubling the amount of messages wether they are 
undo/redo msg or not!

No way to tell which are phony though :(

Seems Alexander Potashev was the one writing this, but if he doesn't 
respond I am probably the one that have to try to fix it. As it looks 
now, releasing next weekend seems unlikely. I'll be back with news 
later.


Cheers

Albert Astals Cid skrev den 2016-11-25 20:32:
El divendres, 25 de novembre de 2016, a les 19:12:13 CET, Dag va 
escriure:

Hi,


There is at the moment a bit of a screwup with the "special" way of 
extracting

i18n messages in calligra, see all those "syntax error" in
https://logs.l10n.kde.org/161125.trunk_l10n-kf5

I mailed Dmitry Kazakov and Alexander Potashev about it but I haven't 
had any
answer yet, do you know of someone else that would have time to have a 
look?


Cheers,
  Albert


we plan to release (parts of) calligra 4. December.
The following modules will *not* be released:
Gemini, Stage, Flow and Braindump
so no need to translate those.
As this is mainly a port to Qt5/KF5 afaik there are only a few string
changes.
(Note that this does not include krita and kexi, they are release
separatly)

Cheers,
Dag

Re: calligra 3.0.0 tarball

[Dag]

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?

Re: calligra 3.0.0 tarball

[Dag]

Boudewijn Rempt skrev den 2016-12-05 11:26:

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

Well, 98% certain, but the translators needs time to translate too...


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.

Yeah, understatement ;)

Re: calligra 3.0.0 tarball

[Dag]

Boudewijn Rempt skrev den 2016-12-05 11:37:

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:

Should you not use createtarball-kf5.rb?


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

Release again, again

[Dag]

Ok, I have asked translators for a release Monday 12. December to give 
them at least a whole weekend, so if nobody screams this is our new 
target.

Re: calligra 3.0.0 tarball

[Dag]

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.
Built and installed, looks ok except for the missing po-files and that 
stage is built.

It is not installed, though so...
It is marked UNMAINTAINED as is eg braindump and braindup is not built.
Does anybody have an explanation?

Re: calligra 3.0.0 tarball

[Dag]

Boudewijn Rempt skrev den 2016-12-05 11:26:

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

Re: calligra 3.0.0 tarball

[Dag]

Good, no problem then :)

Friedrich W. H. Kossebau skrev den 2016-12-06 16:29:

Am Dienstag, 6. Dezember 2016, 13:17:51 CET schrieb Dag:

Built and installed, looks ok except for the missing po-files and that
stage is built.
It is not installed, though so...
It is marked UNMAINTAINED as is eg braindump and braindup is not 
built.

Does anybody have an explanation?


What is tagged as UNMAINTAINED is the Stage application itself, but not 
the

Stage part/libs. Those are used by the Calligra presentation plugin for
Okular, which I consider still maintained (by myself :) ). And as this 
plugin
is not tagged as UNMAINTAINED, the product system makes sure the Stage 
part/
libs are added to the build and also installed (at least by theory, 
need to
test a release build myself, scheduled some time for Thursday to do 
that).


Cheers
Friedrich

Re: calligra 3.0.0 tarball

[Dag]

Boudewijn Rempt skrev den 2016-12-07 11:03:

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.
Hmmm, does not seem to work here. I can see the date on the file is 
07-Dec-2016 10:04 but when I download the same po-files are still 
missing.

Re: calligra 3.0.0 tarball

[Dag]

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)

Re: calligra 3.0.0 tarball

[Dag]

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?

Re: calligra 3.0.0 tarball

[Dag]

Boudewijn Rempt skrev den 2016-12-08 10:12:

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


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?

Re: calligra 3.0.0 tarball

[Dag]

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.

Re: calligra 3.0.0 tarball

[Dag]

Boudewijn Rempt skrev den 2016-12-08 11:53:

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.
Ehhh, no not quite, there is also desktop_calligra_krita.po and 
org.kde.krita.appdata.po, but still...

My concern is the future when something is added/changed.

I can't see more than two possible sustainable solutions:
Best: split calligra, kexi and krita properly both in git and svn.

Not so good: Make some cmake magic to install only the po files we can 
generate pot files for. This will work for all of us, except that there 
will be another special solution to maintain. But it will not solve the 
"problem" that it is less straight forward for the translators as always 
only parts of "calligra" (as they see it) is released.

Re: calligra 3.0.0 tarball

[Dag]

Boudewijn Rempt skrev den 2016-12-08 11:53:

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.
Ok, short term solution (note: never programmed in ruby): could we add 
an excludepo entry in config.ini so we get something like this for 
calligra:

[calligra]
gitModule   = yes
gitTag  = v3.0.0.0
mainmodule  = calligra
submodule   = calligra
version = 3.0.99.90
translations= yes
docs= no
kde_release = no
wholeModule = yes
excludepo   = *krita*,*kexi*

For kexi/krita, if you have only one po file as you say it works out of 
the box, if you have more po files you can use the:

custompo
attribute to list all your po files.

We then need something like this for calligra:
if appdata["wholeModule"]
 (...)
 for pofile in appdata["excludepo"].split(/,/)
   `rm -f #{dest}/#{pofile}.po`
 end

add to the create_tarball_kf5.rb

Re: Selecting the needed po catalogs in the module dir

[Dag]

Luigi Toscano skrev den 2016-12-09 00:10:
In data giovedì 8 dicembre 2016 20:44:34 CET, Friedrich W. H. Kossebau 
ha

scritto:

Am Donnerstag, 8. Dezember 2016, 12:11:26 CET schrieb Dag:
> Boudewijn Rempt skrev den 2016-12-08 11:53:
> > Well, for Krita, we only have krita.po with everything in it -- so that
> > works
> > out automatically. I'm not sure about kexi, though.
>
> Ehhh, no not quite, there is also desktop_calligra_krita.po and
> org.kde.krita.appdata.po, but still...

Po catalogs like *appdata.po, desktop_*.po, json_*.po are not to be 
included
in the release tarballs, those are just some translation process 
artifacts.
Their content is merged into the sources already every time scripty 
runs,
have a look e.g. into the appdata or desktop files. Thus no need for 
having
another copy by the separate catalogs, nothing will use them at 
runtime.
(IMHO they would be in a separate namespace on the server to not 
confuse

release managers, but such a change did not have enough supporters:
https://marc.info/?l=kde-i18n-doc&m=146615836224833&w=1)

So Krita just packaging krita.po files is correct, as they only have 
that

one single runtime catalog file for all of the Krita source code.

> My concern is the future when something is added/changed.
>
> I can't see more than two possible sustainable solutions:
> Best: split calligra, kexi and krita properly both in git and svn.
>
> Not so good: Make some cmake magic to install only the po files we can
> generate pot files for. This will work for all of us, except that there
> will be another special solution to maintain. But it will not solve the
> "problem" that it is less straight forward for the translators as always
> only parts of "calligra" (as they see it) is released.

Another hack might be to have some script to find all Messages.sh in 
the

source code and extract the catalog name from them.
Either by crude parsing the existing ones and grep for the .pot
content, or a more engineered approach by adding code to all 
Messages.sh
files to output the name of the catalog file(s) created when called 
with

some argument like --just-dump-the-catalog-base-name-please.

@Luigi, IIRC you are working on a similar challenge when it comes to 
KDE
Application tarballs, where in the future the po files should be 
inside the

respective source code tarballs, no longer in a separate one.
What approach are you taking there?


Parsing the Messages.sh file. See the attached functions which comes 
from the
work in progress (you can use it in the scripts which a license which 
matches

the KDE Policy license), the extraction works well in my testing.


Where in the infrastructure would this go?

Just for the record, the script will not work out of the box for 
calligra because we have construct like:

calligra_xgettext calligra.pot $LIST
but we could of course change all Message.sh to conform to requirements.




My long term idea is to get rid of Messages.sh and use a declarative 
format
(which can be a simple INI file) to define which translation files 
exists and
which files are associated to them, with a separate engine with 
pluggable
support for different translatable artifacts (regular gettext, json, 
etc).

Re: calligra 3.0.0 tarball

[Dag]

Jonathan Riddell skrev den 2016-12-17 17:42:

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.

Well, I sort of agree with debian, but there is a way, build with:
-DRELEASE_BUILD=true
and CMAKE_BUILD_TYPE is not considered.
Will notify packagers when we get there...



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  wrote:
On 12 December 2016 at 13:05, Boudewijn Rempt  
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

Future releases

[Dag]

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

Re: Future releases

[Dag]

Boudewijn Rempt skrev den 2016-12-20 11:22:
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

I get 'File format not recognized' on this :(

tar xJvf /home/dev/Hentet/calligra-3.0.0.1.tar.xz
xz: (stdin): File format not recognized
tar: Child returned status 1
tar: Error is not recoverable: exiting now



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

Sorry, totally blank on gpg

Re: Future releases

[Dag]

Jonathan Riddell skrev den 2016-12-20 11:58:

On 20 December 2016 at 08:12, Dag  wrote:

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


Any pgp key will do, the only requirement is a packager like myself
can verify it's the one the Calligra devs used which is usually done
by putting it on a pgp key server and putting the full fingerprint on
the release announcement web page and/or e-mails (not on a wiki as
Kirigami devs like to do).
Thought that was what the trust part should do, anybody could create a 
key and say they where a calligra dev.
OTOH probably some of us would protest if calligra was released and none 
of us knew about it ;)





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


You can't use upload.kde.org no but you could use share.kde.org or any
other of 100 services like Google Drive or Dropbox.


6. Publish tarball on download.kde.org (or possibly upload.kde.org)


very few people have direct access to download.kde.org, the normal
process is upload.kde.org and sysadmin request.

upload... would be fine with me.



7. Notify packagers and wait some time (a week?) for feedback


A week feels a bit much to me but as you wish

Less is more in this case. What would you suggest would be enough?


Jonathan

Re: Future releases

[Dag]

Jonathan Riddell skrev den 2016-12-20 12:39:

On 20 December 2016 at 11:29, Dag  wrote:

Any pgp key will do, the only requirement is a packager like myself
can verify it's the one the Calligra devs used which is usually done
by putting it on a pgp key server and putting the full fingerprint on
the release announcement web page and/or e-mails (not on a wiki as
Kirigami devs like to do).


Thought that was what the trust part should do, anybody could create a 
key

and say they where a calligra dev.
OTOH probably some of us would protest if calligra was released and 
none of

us knew about it ;)


Put it on a trusted place like calligra.org and voila, it's trusted.
It's important to include in any announcement to packagers though so
we know what key we should be looking for.

Yes, I see. So who can put up a page like that on calligra.org?



See for example my key on https://www.kde.org/info/plasma-5.8.0.php

I do share Boud's frustration with gpg-agent, it's a tricksy beastie
which sometimes works and sometimes doesn't. But it should be possible
to turn it off and just enter any password in directly.


7. Notify packagers and wait some time (a week?) for feedback



A week feels a bit much to me but as you wish


Less is more in this case. What would you suggest would be enough?


Both Plasma and Applications seem to use Thursday to Tuesday.
Frameworks leaves a week still.  With automated testing there
shouldn't be a need for so long is the thinking these days.

Ok, so ~5 days, including a weekend...



Jonathan

New year and who has access to calligra.org website?

[Dag]

2017 is here, and I wish for it to be a good year for us all!

Well, 2016 didn't produce the release we all expected, but I'm sure we 
will make it before the end of this year ;)


To get releases rolling seems we need a page like this on calligra.org:
https://www.kde.org/info/plasma-5.8.0.php

where we have fingerprints for all that is authorized to release 
calligra.


Who can do this?

Cheers,
Dag

Re: 3.0.0.1 tarball + signature

[Dag]

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

Re: 3.0.0.1 tarball + signature

[Dag]

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

Re: 3.0.0.1 tarball + signature

[Dag]

Looks fine, it's a go from me!

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

Re: 3.0.0.1 tarball + signature

[Dag]

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

RE: 3.0.0.1 tarball + signature

[Dag]

Camilla Boemann skrev den 2017-01-03 12:59:
I have prepared a release announcement, but it doesn't say much so 
maybe

someone has suggestions as to what we should highlight?


I was thinking something like this for the packagers:

A new version of Calligra has been released and files can be found here:
http://download.kde.org/stable/calligra/3.0.0.1/calligra-3.0.0.1.tar.xz
http://download.kde.org/stable/calligra/3.0.0.1/calligra-3.0.0.1.tar.xz.sig

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


Dependencies:
-
Note that atm Plan depends on KProperty and KReport version 3.0.0 
exactly.

Afaik this is the only version released so far.

Building:
-
Note that the tarball contains modules that should not be included in 
the release.
This release shall include the follow main apps: Words, Sheets, Karbon 
and Plan.
The following main apps shall not be included: Stage, Flow and 
Braindump.


Specify the cmake flag:

-DRELEASE_BUILD=true

to only build the modules that shall be released.

See README.PACKAGERS for details.

Unit tests
--
Some unit tests fails if not run in the C locale, use
LC_ALL=C make test
to avoid these failures.

Some unit tests fails but can be disregarded:
sheets-DatetimeFunctions
sheets-ValueConverter
sheets-ValueParser
libs-koodf-TestNumberStyle
libs-pigment-TestColorConversionSystem

Bug fixes:
--
This is mainly a port to KF5/Qt5, but some serious bugs present in 
2.9.11 has been fixed:


Plan:
Fixed crash on startup, crash on close, crash when selecting New.

Words
Fixed crash when adding connected text frame.

ChartShape:
Fixed crash when adding a second chart.

RE: 3.0.0.1 tarball + signature

[Dag]

Camilla Boemann skrev den 2017-01-03 14:09:

Right, but that is just for a mail right ?

Yes.


I mean our website announcement should be a bit more for end users

Indeed.


-Original Message-
From: calligra-devel [mailto:calligra-devel-boun...@kde.org] On Behalf 
Of

Dag
Sent: 3. januar 2017 13:46
To: Calligra Suite developers and users mailing list

Subject: RE: 3.0.0.1 tarball + signature

Camilla Boemann skrev den 2017-01-03 12:59:

I have prepared a release announcement, but it doesn't say much so
maybe someone has suggestions as to what we should highlight?


I was thinking something like this for the packagers:

A new version of Calligra has been released and files can be found 
here:

http://download.kde.org/stable/calligra/3.0.0.1/calligra-3.0.0.1.tar.xz
http://download.kde.org/stable/calligra/3.0.0.1/calligra-3.0.0.1.tar.xz.sig

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


Dependencies:
-
Note that atm Plan depends on KProperty and KReport version 3.0.0 
exactly.

Afaik this is the only version released so far.

Building:
-
Note that the tarball contains modules that should not be included in 
the

release.
This release shall include the follow main apps: Words, Sheets, Karbon 
and

Plan.
The following main apps shall not be included: Stage, Flow and 
Braindump.


Specify the cmake flag:

-DRELEASE_BUILD=true

to only build the modules that shall be released.

See README.PACKAGERS for details.

Unit tests
--
Some unit tests fails if not run in the C locale, use LC_ALL=C make 
test to

avoid these failures.

Some unit tests fails but can be disregarded:
sheets-DatetimeFunctions
sheets-ValueConverter
sheets-ValueParser
libs-koodf-TestNumberStyle
libs-pigment-TestColorConversionSystem

Bug fixes:
--
This is mainly a port to KF5/Qt5, but some serious bugs present in
2.9.11 has been fixed:

Plan:
Fixed crash on startup, crash on close, crash when selecting New.

Words
Fixed crash when adding connected text frame.

ChartShape:
Fixed crash when adding a second chart.

Version stuff in CMakeLists.txt

[Dag]

I can't figure out how this is meant to be used.

We have now released 3.0.0.1. Next should probably be 3.0.1.
So I gather current should be an alpha:
Major: 3
Minor: 0
Release: 89

But then we would go backwards to Release: 1 when releasing,
and after that we go to Release: 89 again and we can't see
what 3.0.89 actually means as it will crop up for every new 3.0 release.

Is it just me being confused, or...
Anybody?

Re: Version stuff in CMakeLists.txt

[Dag]

Had a closer look at this, and there is some cmake logic when generating 
calligraversion.h:
Any 3.0.x unstable (alpha/beta/rc) will get version 2.99.x. (3.1.x will 
be 3.0.x, etc)
Afaics this scheme only works when a minor version is increased, e.g 
3.0.x -> 3.1.0.
Is this a disaster? Probably not. If you add a conditional compile e.g 
in 3.0.1 you cannot test in an unstable release, but that would not be 
often, I think.


Alternatives:
1) Add a unstable release number as proposed by Rene.

2) Drop the special unstable numbers (89, 90..) and use the release 
number as a sequential number.
E.g: We released stable 3.0.0, so now the unstable will get 3.0.1 
(string could be 3.0.1 Alpha) and when we make a new release it would be 
3.0.2.
This will give unique and increasing version numbers, with the drawback 
that you can not see from version alone if it is unstable or stable, but 
we can use version string for that.


Opinions?

Dag skrev den 2017-01-04 10:45:

I can't figure out how this is meant to be used.

We have now released 3.0.0.1. Next should probably be 3.0.1.
So I gather current should be an alpha:
Major: 3
Minor: 0
Release: 89

But then we would go backwards to Release: 1 when releasing,
and after that we go to Release: 89 again and we can't see
what 3.0.89 actually means as it will crop up for every new 3.0 
release.


Is it just me being confused, or...
Anybody?

RE: 3.0.0.1 tarball + signature

[Dag]

Camilla Boemann skrev den 2017-01-03 12:59:
I have prepared a release announcement, but it doesn't say much so 
maybe

someone has suggestions as to what we should highlight?
Since it is mainly a port it isn't that much to highlight, but what *is* 
in and what is *not in* is the main thing imo.



If you want to include some bug fixes also, I have these:

Plan:
Fix crash on startup
Bug: 371930

Avoid crash in special cases (eg. when New is pressed)
BUG: 346976

Fix crash on close
BUG: 373527


Fix printing treeviews
BUG:302916

Add export report definition, fix bug in report import
BUG: 325263

Usability: Never block save, add Milestone option to task dialog
BUG:322661
BUG:352226

Implement sort by wbs to sort by wbs structure and not by the wbs 
code string

BUG:308857

Re-instate handling richtext (description) in reports
CCBUG:329430

Fix potential crash in resource request debug statement
BUG:358674

Re: 3.0.0.1 tarball + signature

[Dag]

Many thanks for your sustained, herculian effort Boudewijn!

Re: Version stuff in CMakeLists.txt

[Dag]

Jaroslaw Staniek skrev den 2017-01-05 10:50:

On 5 January 2017 at 08:59, Dag  wrote:


Had a closer look at this, and there is some cmake logic when
generating calligraversion.h:
Any 3.0.x unstable (alpha/beta/rc) will get version 2.99.x. (3.1.x
will be 3.0.x, etc)
Afaics this scheme only works when a minor version is increased, e.g
3.0.x -> 3.1.0.
Is this a disaster? Probably not. If you add a conditional compile
e.g in 3.0.1 you cannot test in an unstable release, but that would
not be often, I think.

Alternatives:
1) Add a unstable release number as proposed by Rene.

2) Drop the special unstable numbers (89, 90..) and use the release
number as a sequential number.
E.g: We released stable 3.0.0, so now the unstable will get 3.0.1
(string could be 3.0.1 Alpha) and when we make a new release it
would be 3.0.2.
This will give unique and increasing version numbers, with the
drawback that you can not see from version alone if it is unstable
or stable, but we can use version string for that.

Opinions?


IIRC we release no alphas. Even when we had that, we release no alphas
the patch version - for x.y.z (z>0).
x.(y-1).89 is thus compatible with the sequence, it comes after all
x.(y-1).* stable and before the next stable x.y.z.
Hmmm, do you mean we only release unstable when minor version is 
updated, in which case this will (almost) work?
I think we still have the problem that the version in git will get a 
lower version than the last version released, but as said above we could 
live with that.




Between 3.0.0 and 3.0.1 there's no extra number needed.

What we had with the x.y.z.v was special I think. (?)

Yes, forget that.


​


Dag skrev den 2017-01-04 10:45:


I can't figure out how this is meant to be used.

We have now released 3.0.0.1. Next should probably be 3.0.1.
So I gather current should be an alpha:
Major: 3
Minor: 0
Release: 89

But then we would go backwards to Release: 1 when releasing,
and after that we go to Release: 89 again and we can't see
what 3.0.89 actually means as it will crop up for every new 3.0
release.

Is it just me being confused, or...
Anybody?


--
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 [1]

Links:
--
[1] http://www.linkedin.com/in/jstaniek

Re: Version stuff in CMakeLists.txt

[Dag]

Jaroslaw Staniek skrev den 2017-01-05 11:29:

On 5 January 2017 at 11:12, Dag  wrote:


Jaroslaw Staniek skrev den 2017-01-05 10:50:
On 5 January 2017 at 08:59, Dag  wrote:

Had a closer look at this, and there is some cmake logic when
generating calligraversion.h:
Any 3.0.x unstable (alpha/beta/rc) will get version 2.99.x. (3.1.x
will be 3.0.x, etc)
Afaics this scheme only works when a minor version is increased, e.g
3.0.x -> 3.1.0.
Is this a disaster? Probably not. If you add a conditional compile
e.g in 3.0.1 you cannot test in an unstable release, but that would
not be often, I think.

Alternatives:
1) Add a unstable release number as proposed by Rene.

2) Drop the special unstable numbers (89, 90..) and use the release
number as a sequential number.
E.g: We released stable 3.0.0, so now the unstable will get 3.0.1
(string could be 3.0.1 Alpha) and when we make a new release it
would be 3.0.2.
This will give unique and increasing version numbers, with the
drawback that you can not see from version alone if it is unstable
or stable, but we can use version string for that.

Opinions?

IIRC we release no alphas. Even when we had that, we release no
alphas
the patch version - for x.y.z (z>0).
x.(y-1).89 is thus compatible with the sequence, it comes after all
x.(y-1).* stable and before the next stable x.y.z.

 Hmmm, do you mean we only release unstable when minor version is
updated, in which case this will (almost) work?

​After 2.9.11 our 3.0.0 beta was 2.9.8x or so (regardless of the
fact if it was physically released). All version are in sequence as in
semantic versioning.

​As you see minor version was not updated, it was still 9. It
turned​ 0 since 3.0.0.

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

Yes, I see that. It is not what I am talking about.
Can I ask you directly then what to put into CMakeLists.txt so we can 
get it right:


set(CALLIGRA_VERSION_STRING "3.0.0.1")
set(CALLIGRA_STABLE_VERSION_MAJOR 3) # 3 for 3.x, 4 for 4.x, etc.
set(CALLIGRA_STABLE_VERSION_MINOR 0) # 0 for 3.0, 1 for 3.1, etc.
set(CALLIGRA_VERSION_RELEASE 0) # 89 for Alpha, increase for next 
test releases, set 0 for first Stable, etc.

#set(CALLIGRA_ALPHA 1) # uncomment only for Alpha
#set(CALLIGRA_BETA 1) # uncomment only for Beta
#set(CALLIGRA_RC 1) # uncomment only for RC
set(CALLIGRA_YEAR 2017) # update every year





I think we still have the problem that the version in git will get a
lower version than the last version released, but as said above we
could live with that.


Between 3.0.0 and 3.0.1 there's no extra number needed.

What we had with the x.y.z.v was special I think. (?)

Yes, forget that.

​

Dag skrev den 2017-01-04 10:45:

I can't figure out how this is meant to be used.

We have now released 3.0.0.1. Next should probably be 3.0.1.
So I gather current should be an alpha:
Major: 3
Minor: 0
Release: 89

But then we would go backwards to Release: 1 when releasing,
and after that we go to Release: 89 again and we can't see
what 3.0.89 actually means as it will crop up for every new 3.0
release.

Is it just me being confused, or...
Anybody?


--
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 [1] [1]

Links:
--
[1] http://www.linkedin.com/in/jstaniek [1]

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

Links:
--
[1] http://www.linkedin.com/in/jstaniek

Re: Version stuff in CMakeLists.txt

[Dag]

Ahh, just dawned on me where I went wrong. A bug fix release will 
*always* be stable so... no problem.

Thanks for your patience, Jaroslaw.

Dag skrev den 2017-01-05 11:43:

Jaroslaw Staniek skrev den 2017-01-05 11:29:

On 5 January 2017 at 11:12, Dag  wrote:


Jaroslaw Staniek skrev den 2017-01-05 10:50:
On 5 January 2017 at 08:59, Dag  wrote:

Had a closer look at this, and there is some cmake logic when
generating calligraversion.h:
Any 3.0.x unstable (alpha/beta/rc) will get version 2.99.x. (3.1.x
will be 3.0.x, etc)
Afaics this scheme only works when a minor version is increased, e.g
3.0.x -> 3.1.0.
Is this a disaster? Probably not. If you add a conditional compile
e.g in 3.0.1 you cannot test in an unstable release, but that would
not be often, I think.

Alternatives:
1) Add a unstable release number as proposed by Rene.

2) Drop the special unstable numbers (89, 90..) and use the release
number as a sequential number.
E.g: We released stable 3.0.0, so now the unstable will get 3.0.1
(string could be 3.0.1 Alpha) and when we make a new release it
would be 3.0.2.
This will give unique and increasing version numbers, with the
drawback that you can not see from version alone if it is unstable
or stable, but we can use version string for that.

Opinions?

IIRC we release no alphas. Even when we had that, we release no
alphas
the patch version - for x.y.z (z>0).
x.(y-1).89 is thus compatible with the sequence, it comes after all
x.(y-1).* stable and before the next stable x.y.z.

 Hmmm, do you mean we only release unstable when minor version is
updated, in which case this will (almost) work?

​After 2.9.11 our 3.0.0 beta was 2.9.8x or so (regardless of the
fact if it was physically released). All version are in sequence as in
semantic versioning.

​As you see minor version was not updated, it was still 9. It
turned​ 0 since 3.0.0.

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

Yes, I see that. It is not what I am talking about.
Can I ask you directly then what to put into CMakeLists.txt so we can
get it right:

set(CALLIGRA_VERSION_STRING "3.0.0.1")
set(CALLIGRA_STABLE_VERSION_MAJOR 3) # 3 for 3.x, 4 for 4.x, etc.
set(CALLIGRA_STABLE_VERSION_MINOR 0) # 0 for 3.0, 1 for 3.1, etc.
set(CALLIGRA_VERSION_RELEASE 0) # 89 for Alpha, increase for next
test releases, set 0 for first Stable, etc.
#set(CALLIGRA_ALPHA 1) # uncomment only for Alpha
#set(CALLIGRA_BETA 1) # uncomment only for Beta
#set(CALLIGRA_RC 1) # uncomment only for RC
set(CALLIGRA_YEAR 2017) # update every year





I think we still have the problem that the version in git will get a
lower version than the last version released, but as said above we
could live with that.


Between 3.0.0 and 3.0.1 there's no extra number needed.

What we had with the x.y.z.v was special I think. (?)

Yes, forget that.

​

Dag skrev den 2017-01-04 10:45:

I can't figure out how this is meant to be used.

We have now released 3.0.0.1. Next should probably be 3.0.1.
So I gather current should be an alpha:
Major: 3
Minor: 0
Release: 89

But then we would go backwards to Release: 1 when releasing,
and after that we go to Release: 89 again and we can't see
what 3.0.89 actually means as it will crop up for every new 3.0
release.

Is it just me being confused, or...
Anybody?


--
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 [1] [1]

Links:
--
[1] http://www.linkedin.com/in/jstaniek [1]

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

Links:
--
[1] http://www.linkedin.com/in/jstaniek

Re: cmake error

[Dag]

Jonathan Riddell skrev den 2017-01-06 12:44:

Neon is finding a problem in the top level cmake file

09:20:14 CMake Error at CMakeLists.txt:486 (if):
09:20:14   if given arguments:
09:20:14
09:20:14 "KReport_FOUND" "AND" "GREATER" "80"
09:20:14
09:20:14   Unknown arguments specified


added earlier today
commit 84091746c37a80dc907c412d0903d7baae16415c
Author: Dag Andersen 
Date:   Fri Jan 6 09:05:22 2017 +0100

Work here of course.
Think I found and fixed it, but we will see...



Jonathan

Re: KReport version found is not stable

[Dag]

Adam Pigg skrev den 2017-02-23 15:38:

Kproperty and kreport master are working towards 3.1, but are not
released.  is plan developing against master, but commented out  to
allow the CI system to work?

No plan develops against 3.0, so plan is just not build.
It should be possible to install both 3.0 and master (co-installable) so 
both kexi and plan gets build, but probably needs some ci trickery...


On Thursday, 23 February 2017, Jonathan Riddell wrote:

Currently our build of calligra doesn't build Plan because
"KReport version found is not stable", same for KPropertyWidgets
cmakelists.txt says this is deliberate
"This is a temporary measure to avoid that the whole calligra build
fails on build.kde.org"
but we're building the latest kreport and kpropertywidgets and
calligra.  should we hold back versions of kreport/propertywidgets? Or
just not build plan? or remove that temporary measure?

Jonathan


---

Release 3.0.1

[Dag]

Hi, should we make a bug fix release soon?

A few bugs has been fixed, and there is 3 months since 3.0.0 ;)

Anybody has something that *needs* to be fixed?

Cheers,
Dag

RE: Release 3.0.1

[Dag]

Ok, we are in string freeze.

Tarballs planned for monday 20. if translators do not bulge.

Re: Release 3.0.1

[Dag]

Ok, git tagged v3.0.1 and tarball created.

Files can be found here:
https://share.kde.org/index.php/s/yanrJWiQFB3rrvc

My public key is here:
https://share.kde.org/index.php/s/pYwk5c7UNcXGYfP

Please test.

Upload etc planned for next week.

Cheers,
Dag

Re: libpigmentcms.so - multiple definitions KoCompositeOp

[Dag]

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 can see that cmake outputs this for you:
Following objects are generated from the per-arch lib
compositeops/KoOptimizedCompositeOpFactoryPerArch.cpp

It generates this for me:
Following objects are generated from the per-arch lib
/build/neon/release/calligra-3.0.1/libs/pigment/KoOptimizedCompositeOpFactoryPerArch_SSE2.cpp/build/neon/release/calligra-3.0.1/libs/pigment/KoOptimizedCompositeOpFactoryPerArch_SSSE3.cpp/build/neon/release/calligra-3.0.1/libs/pigment/KoOptimizedCompositeOpFactoryPerArch_SSE4_1.cpp/build/neon/release/calligra-3.0.1/libs/pigment/KoOptimizedCompositeOpFactoryPerArch_AVX.cpp/build/neon/release/calligra-3.0.1/libs/pigment/KoOptimizedCompositeOpFactoryPerArch_AVX2+FMA+BMI2.cpp

I'm no expert on this, but I don't think the
compositeops/KoOptimizedCompositeOpFactoryPerArch.cpp
is meant to be compiled.

No idea why, any input welcome!



libs/pigment/CMakeFiles/pigmentcms.dir/compositeops/KoOptimizedCompositeOpFactoryPerArch.cpp.o:
In function `KoCompositeOp*
KoOptimizedCompositeOpFactoryPerArch::create<(Vc_1::Implementation)0>(KoColorSpace
const*)':
KoOptimizedCompositeOpFactoryPerArch.cpp:(.text+0x0): multiple
definition of `KoCompositeOp*
KoOptimizedCompositeOpFactoryPerArch::create<(Vc_1::Implementation)0>(KoColorSpace
const*)'
libs/pigment/CMakeFiles/pigmentcms.dir/compositeops/KoOptimizedCompositeOpFactoryPerArch_Scalar.cpp.o:KoOptimizedCompositeOpFactoryPerArch_Scalar.cpp:(.text+0x0):
first defined here


cmake-3.7.2
gcc-6.3.0
vc-1.3.1
qt-5.8.0

Full compile log attached

Regards, Treeve

---
SENDT FRA MIN JUBII MAIL
Jubii Mail har eksisteret i 20 år og er en af Danmarks største
mail-udbydere med langt over 100.000 brugere. Jubii Mail er et 100% 
dansk

produkt med både support og hosting i Danmark. Vi sætter en ære i at
levere en personlig kvalitets-mail til både private og foreninger - og 
med

knap 150 domænenavne tør vi godt love, at vi også har en personlig
email-adresse til dig. KLIK HER - OPRET JUBII MAIL [1].

Links:
--
[1] 
https://konto.jubii.dk/SignUp?utm_source=Webmail%20Signatur&utm_medium=Webmail%20Signatur

Re: Release 3.0.1

[Dag]

Compiled a list fixes, please add if I missed something.

General
---
Fix crash in move command when using arrow keys

Respect container boundaries when moving shapes by arrow keys

Remove shape manipulation handles when the tool is deactivated

Always display shapes in the the same order in the 'Add shape' docker


Sheets
--
Improve formatting of scientific numbers

Fix save/load of cell borders


Plan

Bug 376469: Bad month calendar in Work & Vacation
Day numbers where not initialized correctly.
Manually entered dates where not parsed correctly.

Use default currency symbol if the currency symbol is not explicitly set


Chart
-
Fix crash when chart type is changed

Fix crash when a chart component is deleted

Fix crash when x- or y-axis is removed

Fix ui when editing axis label

Limit moving chart components to chart boundaries

Fix edit font dialog: Keep the axis fonts QFont size in sync with 
KCharts fontSize


Fix save/load of axis label font size and font family

Save/load legend alignment flags

Do not save axis label if it is not visible

Always do legend alignment when legend becomes visible.

Make axis dimensions translatable

Add undo command for hide/show titles

Add undo command for add/remove axis

Respect margins/spacing

Handle resizing in a reasonable way

Cheers,
Dag

Re: libpigmentcms.so - multiple definitions KoCompositeOp

[Dag]

Great, thanks.

Treeve Jelbert skrev den 2017-03-23 14:37:

I have just done a clean compile, deleting some extraneous cmake
definitions and everything  now compiles correctly.

Regards


On Wed, 22 Mar 2017 18:13:43 +0100, Treeve Jelbert wrote:

I just tried to build calligra from git-master, which I think is the
same as the release tarball.


libs/pigment/CMakeFiles/pigmentcms.dir/compositeops/KoOptimizedCompositeOpFactoryPerArch.cpp.o:
In function `KoCompositeOp*

KoOptimizedCompositeOpFactoryPerArch::create<(Vc_1::Implementation)0>(KoColorSpace
const*)':
KoOptimizedCompositeOpFactoryPerArch.cpp:(.text+0x0): multiple
definition of `KoCompositeOp*

KoOptimizedCompositeOpFactoryPerArch::create<(Vc_1::Implementation)0>(KoColorSpace
const*)'

libs/pigment/CMakeFiles/pigmentcms.dir/compositeops/KoOptimizedCompositeOpFactoryPerArch_Scalar.cpp.o:KoOptimizedCompositeOpFactoryPerArch_Scalar.cpp:(.text+0x0):
first defined here


cmake-3.7.2
gcc-6.3.0
vc-1.3.1
qt-5.8.0

Full compile log attached

Regards, Treeve

Re: libpigmentcms.so - multiple definitions KoCompositeOp

[Dag]

Created a todo for this
https://phabricator.kde.org/T5738
so we don't forget...

Boudewijn Rempt skrev den 2017-03-23 11:34:

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

Re: Release 3.0.1

[Dag]

Turns out I ma away the next week,
so if somebody does not take it the last steps,
release will be delayed...

---
Cheers,
Dag

Re: Release 3.0.1

[Dag]

Tarball now on download.kde.org and packagers notified.

Could somebody with karma prepare an announcement for Friday (or the 
weekend)?


Created new calligra/3.0 branch so master now open for new features.

Please backport (important) bugfixes in case we need a 3.0.2 release.

---
Cheers,

Dag

Re: calligra master broken

[Dag]

Jonathan Riddell skrev den 2017-04-07 17:22:

Latest commit to calligra master seems to have broken compile for neon

Hmm, works here, I'll hava look tomorrow.


http://build.neon.kde.org/job/xenial_stable_calligra_calligra_bin_amd64/56/console

Note that calligra stable is branch calligra/3.0 now


15:17:50 /workspace/build/plan/kptview.cpp: In member function ‘void
KPlato::View::createReportView(const QDomDocument&)’:
15:17:50 /workspace/build/plan/kptview.cpp:2687:14: error:
‘ViewListReportsDialog’ was not declared in this scope
15:17:50  QPointer vd = new
ViewListReportsDialog( this, *m_viewlist, doc, this );

Jonathan

Re: calligra master broken

[Dag]

Dag skrev den 2017-04-07 20:55:

Jonathan Riddell skrev den 2017-04-07 17:22:

Latest commit to calligra master seems to have broken compile for neon

Hmm, works here, I'll hava look tomorrow.

No, sorry, my bad. Should be fixed now.



http://build.neon.kde.org/job/xenial_stable_calligra_calligra_bin_amd64/56/console

Note that calligra stable is branch calligra/3.0 now


15:17:50 /workspace/build/plan/kptview.cpp: In member function ‘void
KPlato::View::createReportView(const QDomDocument&)’:
15:17:50 /workspace/build/plan/kptview.cpp:2687:14: error:
‘ViewListReportsDialog’ was not declared in this scope
15:17:50  QPointer vd = new
ViewListReportsDialog( this, *m_viewlist, doc, this );

Jonathan

Moving calligra kostore and koodf

[Dag]

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).
This will possibly make it easier to keep up to date on odf spec 
changes.


Any thoughts?

--
Cheers,

Dag

Release

[Dag]

Hi, I would like to get Plan out soonish, and it would be nice to also 
include gemini along with words, sheets and karbon if it is ready for 
consumption.


I suggest January 25 for final release and a beta December 15.


--
Cheers,

Dag

Re: Release

[Dag]

Jaroslaw Staniek skrev den 2017-12-05 11:42:

Nice to hear this, Dag.
For the record, next 30 days is also estimated time for Kexi &
Frameworks 3.1 release.
There are Plan -> Frameworks dependencies, right?

Yes and no :)
If it is ready, I'll include it, if not it can wait for a later release.



On 5 December 2017 at 10:34, Dag  wrote:


Hi, I would like to get Plan out soonish, and it would be nice to
also include gemini along with words, sheets and karbon if it is
ready for consumption.

I suggest January 25 for final release and a beta December 15.

--
Cheers,

Dag


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

Feature freeze

[Dag]

Expect to tag and release tarballs today, so please only bug fixes from 
now on.


--
Cheers,

Dag

Beta is out

[Dag]

Could someone with karma announce it on calligra.org?

--
Cheers,

Dag

String freeze for calligra 3.1 release

[Dag]

Hi,
We plan to release Calligra 3.1 on Thursday 2018-01-25.
We release from master/trunk.

String freeze is in effect from now on until release and stable branches 
has been created.


--
Cheers,

Dag

Re: Help with Phabricator needed

[Dag]

Sebastian Pettke skrev den 2018-01-22 21:00:

Hi,

I tried to submit a patch using Phabricator:
https://phabricator.kde.org/D10014

but it won't appear on this page:
https://phabricator.kde.org/project/profile/23/

Is this expected behaviour or is there anything I am missing or should 
do now?
I'm not overly comfortable with phab myself, the interface might be 
intuitive but it does not match my intuition ;)

But, we got the review request, looking at it right now.

---
Cheers,
Dag

Re: Help with Phabricator needed

[Dag]

Sebastian Pettke skrev den 2018-01-23 23:38:

On January 23, 2018 at 10:30 AM Dag  wrote:

Sebastian Pettke skrev den 2018-01-22 21:00:
> Hi,
>
> I tried to submit a patch using Phabricator:
> https://phabricator.kde.org/D10014
>
> but it won't appear on this page:
> https://phabricator.kde.org/project/profile/23/
>
> Is this expected behaviour or is there anything I am missing or should
> do now?
I'm not overly comfortable with phab myself, the interface might be
intuitive but it does not match my intuition ;)
But, we got the review request, looking at it right now.


Thanks for reviewing.
It does not seem to be in the repository yet, what would be the next
steps to get it there?

git push, or if you used arc: arc land

Re: Help with Phabricator needed

[Dag]

Sebastian Pettke skrev den 2018-01-24 16:36:
unfortunately I don't have the permission to push and according to 
this:

https://community.kde.org/Infrastructure/Phabricator#Workflow
I also can't use arc land without a full KDE Developer Account (I
don't have one).

Might someone else with the necessary permissions please push or land
the changes if they are ok? :)

Yes, done. And thanks!

Calligra 3.1.0 release delayed

[Dag]

The plan was to create tarballs today, but I have hit some strange 
behavior when CMAKE_BUILD_TYPE is empty so need to make some more 
timeconsuming tests.


If possible I will release tomorrow, but it might not happen until 
monday.


Feature- and string freeze remain in effect until further notice.

--
Cheers,
Dag

3.1.0 is out

[Dag]

Ok, release is out so master is open for features and strings again.

Need an announcement, I'll collect from commit log, but please, those 
who has something post it here.


@leinir could you say something about gemini?

--
Cheers,

Dag

Release announced on kde-announce-app

[Dag]

See att file.
It would be swell if somebody with access could do likewise on 
calligra.org, maybe add more about gemini.


--
Cheers,

Dag

We are pleased to announce the release of Calligra 3.1.0 with the following 
apps included:
Words, Sheets, Karbon, Gemini, and Plan.

Note that Gemini, the KDE Office suite for 2-in-1 devices, is back.

Tarballs can be found here:
http://download.kde.org/stable/calligra/3.1.0/calligra-3.1.0.tar.xz.mirrorlist
http://download.kde.org/stable/calligra/3.1.0/calligraplan-3.1.0.tar.xz.mirrorlist

Also note that Kexi, the visual database applications creator is close to 
release 3.1.0.
See http://www.kexi-project.org.

The following is a list of new features and bug fixes since the last release 
(3.0.1).

Common:
---
* Picture shape tool: Paint crop rectangle and its handles with 1px wide 
outline. (BUG: 388930)
Due to the painter scaling the pen width (1 by default) was scaled too, 
which caused the outlines to cover the whole image.

* Textlayout: Do not enter infinite loop when line rect is not valid.

* Add RTF support to Okular. (BUG: 339835)


Sheets:
---
* LaTeX export: Fix typo in UI string. (BUG: 380030)


Plan:
-
* Add dialog to be able to edit multiple tasks at once. (BUG: 310937)

* Provide expand all/collapse all in context menu. (BUG: 313606)
Expands/collapses selected item(s) and all children.
Retains the treeviews expanded rows across operations.

* Printing: Make changes to page layout persistent. (BUG: 385084)

* Open Document Text format report generator added.
Adds the abillity to generate reports in odt format directly.
Reports can be viewed using an odt viewer like Calligra Words or 
LibreOffice Writer.
Report templates are also in odt format and can be designed using e.g 
Words or Writer.

* Add support for sharing resources in multiple projects.

* Improved context help and documentation.

* Add support for automatic holidays generation.

* Calendar view: Handle context menus with no calendar.

* Replace the file centric startup page with page more suitable for 
projects.

* Add editing and reloading of task modules.

* Gantt view: Fix possible crash when deleting gantt view with large 
projects.

* Gantt view: Fix issue with task dependencies not cleared in certain 
situations.

* Fix undo/redo issue with modifying project target times.

* Fix potential crash in Cost Breakdown View.

* Fix potential crash when creating new project from current project.

* Fix performance issue in chart view.

Note:
* Support for scripting is discontinued.

* Reports using KReport is not supported in this release.

Re: Release announced on kde-announce-app

[Dag]

Boudewijn Rempt skrev den 2018-01-31 14:00:
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.

Ahh, never knew. Thanks.

Re: Calligra 3.1 status

[Dag]

Jonathan Riddell skrev den 2018-02-06 14:52:

The calligraplan tar contains translations which conflict with those
in the calligra tar

calligraplanlibs.mo  calligraplan.mo  calligraplan_scheduler_rcps.mo
calligraplan_scheduler_tj.mo  calligraplanwork.mo  krossmoduleplan.mo

Hmmm, cannot find any calligraplan* files in the calligra-3.1.0.tar.xz.
Can you give me any pointers?



On 6 February 2018 at 13:21, Jonathan Riddell  wrote:
It's not clear what the status of Calligra 3.1 is.  There's an 
announce up but

https://community.kde.org/Calligra
still says 3.0.1 is stable, repo-metadata says calligra/3.0 is the
stable branch.

Yeahh, forgot about that page, it has fallen out of use lately.


There's a separate calligraplan tar which isn't announed why that
seems to be separate.

It was mentioned at release-t...@kde.org:
https://mail.kde.org/pipermail/release-team/2018-January/010806.html

---
Cheers,

Dag

Re: Calligra 3.1 status

[Dag]

Jonathan Riddell skrev den 2018-02-06 15:38:

On 6 February 2018 at 14:25, Dag  wrote:

Jonathan Riddell skrev den 2018-02-06 14:52:


The calligraplan tar contains translations which conflict with those
in the calligra tar

calligraplanlibs.mo  calligraplan.mo  calligraplan_scheduler_rcps.mo
calligraplan_scheduler_tj.mo  calligraplanwork.mo  krossmoduleplan.mo


Hmmm, cannot find any calligraplan* files in the 
calligra-3.1.0.tar.xz.

Can you give me any pointers?


Oh I see I'm using Neon dev edition which builds calligra from Git
which still has Plan there.
Ahh, yes hoped I could keep plan in the calligra repository, but 
probably would be simpler in the long run if it was moved out like e.g. 
kexi.





There's a separate calligraplan tar which isn't announed why that
seems to be separate.


It was mentioned at release-t...@kde.org:
https://mail.kde.org/pipermail/release-team/2018-January/010806.html


Oh aye, thanks

Jonathan

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

[Dag]

Afaik we do not need koffice.net and koffice.org.
koffice.org just points to calligra.org, and koffice.net does not have 
any content.

So, please do not renew.

---
Cheers,

Dag


Ben Cooksley skrev den 2018-03-20 07:25:

On Tue, Mar 20, 2018 at 8:37 AM, Thomas Pfeiffer
 wrote:

Dear Calligra team,


Hi all,

we just got notified that the domain koffice.net is about to expire 
and has to be renewed, and sysadmin asked the board whether the domain 
is still used.
Since KOffice has not been around for years now, we wonder if you 
still need the old domain as a redirect to calligra.org, or if we can 
drop it.

The domain is set to expire by Friday (March 23rd).


Please note that koffice.org is also coming up for renewal one day
after koffice.net, so comments on that would also be appreciated.



If we do not get a reply from someone by *Thursday, March 22nd, 
23:59:59 CET* saying that the domain is still needed, we are going to 
drop the domain koffice.net.


Thank you,
Thomas




Regards,
Ben

Re: Calligra Sheets feedback mode?

[Dag]

iIjier Iuiresd skrev den 2018-03-23 19:32:

Thanks, I'm not a Calligra developer, is there a way to get this info
without having to build Calligra Sheets?

Quick try to see if you get some output. Run from terminal:
QT_LOGGING_RULES="calligra.lib.odf=true;calligra.sheets=true" 
calligrasheets&


---
Cheers,

Dag





23.03.2018, 20:26, "Tomas Mecir" :

Have you tried compiling sheets with debug info and enabling sheets
debugs in kdebugdialog5? That might give some idea what's wrong.

Tomas

2018-03-23 19:22 GMT+01:00 iIjier Iuiresd :

 Hi,
 I'm finishing up a new Qt5 .ods reading/writing library that will 
deprecate

 my current one:
 https://github.com/f35f22fan/QOds
 and unlike LibreOffice, Calligra Sheets (v3.0.1) often doesn't 
display the
 .ods data as expected or at all and doesn't report there's an issue 
with it.


 I was wondering if there's some way to query Calligra what exactly 
it

 doesn't like about an .ods document?

 I would need this info to make it worth it for me to create .ods 
files that

 Calligra can read properly.

State of windows

[Dag]

@leinir
Could you comment on this comment?
https://www.calligra.org/news/calligra-3-1-0-released/

--
Cheers,

Dag

Re: D9537: [kotextlayoutarea] Make percentage line height relative to the default height

[Dag]

Camilla Boemann skrev den 2018-05-28 20:20:

boemann added a comment.
View Revision [1]

This is not correct

I refer to https://www.w3.org/TR/xsl11/#line-height

which states that percentage is releative to fontheight - if not
percentage is give a default of 120 percent is used

but you should not multiply 1.2 to the percentage

Hmmm, it says:
"The computed value of the property is this percentage multiplied by the 
element's computed font size"

My question: what is "element's computed font size"?
Could it be what is computed for "normal"?

A thought experiment:
If percent is 100, should we not get the same height as in "normal"?



I say again that the fix should be found in the table code or
rendering

You are probably right, but the the text isn't crystal clear to me...

Help with words, anchored shapes and dialog

[Dag]

Hi,
I'm working on the chartshape and have noticed that when adding a shape 
it is does not get an anchor.
The result is that LO does not know where to put it, and it ends up in 
the wrong position.

Somehow words figures it out, maybe with some default values?

A possible fix is to add a default anchor in KWDocument::addShape(),
but I do not know if this covers all cases and maybe there are shapes 
that should not be anchored?


Also, the shape context menu pops up again after closing the Shape 
Properties dialog.

Any idea how to fix this?

And last, I do not want a context menu for chart components (which are 
shapes).

Any idea how to avoid this?

--
Cheers,

Dag

Re: Fwd: KDE CI: Dependency Build Calligra kf5-qt5 WindowsMSVCQt5.10 - Build # 1 - Failure!

[Dag]

From cmake:
 * KF5AkonadiContact , Library for Accessing Contacts stored in Akonadi 
, <https://www.kde.org/>

   Optionally used by Plan
 * KF5Akonadi , Library for general Access to Akonadi , 
<https://www.kde.org/>

   Optionally used by semantic items Event and Contact

Plan's use og KF5AkonadiContact is atm not working but needs a 
reimplementation anyways to be useful,

so I have no problem with removing it for Windows.

The semantic items stuff is also not working atm, it has not yet been 
ported properly I think.
So at least for the near future, there should be no problem with making 
it optional for Windows.



---
Cheers,

Dag



Jaroslaw Staniek skrev den 2018-07-25 11:03:

Hi Calligra Devs,
Thanks to Ben, we're getting a Jenkins view for Calligra builds:
https://build.kde.org/view/Calligra/.
I am forwarding info on one defect so you have opportunity to fix this
dependency to make Calligra auto-build on Windows!
One way I would imagine is to make Prison optional dependency. Another
to make it temporarily off on Windows or optional on Windows.

@Ben
I understand this issue is not affecting kexi* builds for Windows?

-- Forwarded message --
From: BEN COOKSLEY 
Date: 25 July 2018 at 10:53
Subject: Fwd: KDE CI: Dependency Build Calligra kf5-qt5
WindowsMSVCQt5.10 - Build # 1 - Failure!
To: Jaroslaw Staniek 

Hey Jaroslaw,

I'm afraid you'll need to resolve this before we can continue with
Calligra on Windows CI builds.

If akonadi-contacts is an optional dependency of Calligra we can
exclude it, otherwise you'll have to arrange for
​​
​​Prison's dependencies to be buildable on Windows using Craft..

Cheers,
Ben

-- Forwarded message --
From: CI SYSTEM 
Date: Wed, Jul 25, 2018 at 12:20 AM
Subject: KDE CI: Dependency Build Calligra kf5-qt5 WindowsMSVCQt5.10 -
Build # 1 - Failure!
To: bcooks...@kde.org

BUILD FAILURE

 Build URL

https://build.kde.org/job/Dependency%20Build%20Calligra%20kf5-qt5%20WindowsMSVCQt5.10/1/
[1]

 Project:
Dependency Build Calligra kf5-qt5 WindowsMSVCQt5.10

 Date of build:
Tue, 24 Jul 2018 09:12:57 +

 Build duration:
3 hr 7 min and counting

 CONSOLE OUTPUT

[...truncated 38.40 MB...]

PROCESSOR_LEVEL = '6'

PROCESSOR_REVISION = '3d02'

PROGRAMDATA = 'C:\ProgramData'

PROGRAMFILES = 'C:\Program Files'

PROGRAMFILES(X86) = 'C:\Program Files (x86)'

PROGRAMW6432 = 'C:\Program Files'

PROMPT = '$P$G'

PSMODULEPATH = 
'C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules\'

PUBLIC = 'C:\Users\Public'

RUN_CHANGES_DISPLAY_URL =
'https://build.kde.org/job/Dependency%20Build%20Calligra%20kf5-qt5%20WindowsMSVCQt5.10/1/display/redirect?page=changes
[2]'

RUN_DISPLAY_URL =
'https://build.kde.org/job/Dependency%20Build%20Calligra%20kf5-qt5%20WindowsMSVCQt5.10/1/display/redirect
[3]'

STAGE_NAME = 'Build Product Dependencies'

SYSTEMDRIVE = 'C:'

SYSTEMROOT = 'C:\WINDOWS'

TEMP = 'C:\Users\Jenkins\AppData\Local\Temp'

TMP = 'C:\Users\Jenkins\AppData\Local\Temp'

UCRTVERSION = '10.0.17134.0'

UNIVERSALCRTSDKDIR = 'C:\Program Files (x86)\Windows Kits\10\'

USERDOMAIN = 'DESKTOP-66R8QOQ'

USERNAME = 'Jenkins'

USERPROFILE = 'C:\Users\Jenkins'

VCIDEINSTALLDIR = 'C:\Program Files (x86)\Microsoft Visual
Studio\2017\Professional\Common7\IDE\VC\'

VCINSTALLDIR = 'C:\Program Files (x86)\Microsoft Visual
Studio\2017\Professional\VC\'

VCTOOLSINSTALLDIR = 'C:\Program Files (x86)\Microsoft Visual
Studio\2017\Professional\VC\Tools\MSVC\14.14.26428\'

VCTOOLSREDISTDIR = 'C:\Program Files (x86)\Microsoft Visual
Studio\2017\Professional\VC\Redist\MSVC\14.14.26405\'

VCTOOLSVERSION = '14.14.26428'

VISUALSTUDIOVERSION = '15.0'

VS140COMNTOOLS = 'C:\Program Files (x86)\Microsoft Visual Studio
14.0\Common7\Tools\'

VS150COMNTOOLS = 'C:\Program Files (x86)\Microsoft Visual
Studio\2017\Professional\Common7\Tools\'

VSCMD_ARG_APP_PLAT = 'Desktop'

VSCMD_ARG_HOST_ARCH = 'x64'

VSCMD_ARG_TGT_ARCH = 'x64'

VSCMD_VER = '15.7

Re: Krita donation proposal

[Dag]

Imho, a good idea. Does not seem krita gets anything directly, maybe 
because it is considdered part of calligra.


---
Cheers,

Dag



Jaroslaw Staniek skrev den 2018-10-16 18:06:

Dear Calligra contributors,
Congratulations again on the donation [1] and big thanks to the
Handshake Foundation for recognizing Calligra!

tl;dr: I'd like to propose that 10% of the sum goes to support Krita.

Introduction

As person helping with completing the donation process I'd like to
repeat the fact that Calligra was recognized by the Handshake
Foundation as an organization having specific achievements in the FOSS
world. The Foundation decided to offer the donation unconditionally
and independently of the KDE's one.

Unlike other "Office" projects Calligra has no dedicated foundation so
the solution was to join KDE e.V. on the task around the bookkeeping
and related matters and to ensure transparency. It also felt most
natural since we're KDE. So there was no decision of the KDE board or
KDE community to split the one fund to Calligra and the rest of KDE,
there are two funds.

Details

Now that we're around next, harder step, I'd like to share my position
that addresses possible question of the contributors and fans: what
with supporting Krita?

Based on what I learned from the donor the funding is based on
recognition for the *entire* history of KOffice/Calligra so Krita
being important member of our family, not only can but *should* be
included i nthe support. Krita has been on the same level of
organization as other Calligra applications until 2.9 version [2].
There were 10 visible Calligra apps, not counting variations of apps
like mobile or Active and the Office Engine. So I'd like to propose
that 10% of the sum goes to support Krita, formally the Krita
Foundation.

Assertions

This is my idea, without any requests from the Krita side. And for my
understanding the idea does not limit possibility of Krita or current
Calligra to benefit from the "KDE" donation, especially indirectly,
e.g. through the shared infrastructure and common development
programs.

Common sense suggest me reasonable requirement for supporting Calligra
sub-projects: they needs to be active (have relatively recent
releases) with potential to growth, and activity should be
sufficiently independent of existence of the attractive funding that
was received. I think Krita meets these requirements.

[1]
https://dot.kde.org/2018/10/15/kde-ev-receives-sizeable-donation-handshake-foundation
[2] https://www.calligra.org/krita
--

regards, Jaroslaw Staniek

KDE:
: A world-wide network of software engineers, artists, writers,
translators
: and facilitators committed to Free Software development -
http://kde.org
KEXI:
: A visual database apps builder - http://calligra.org/kexi
  http://twitter.com/kexi_project https://facebook.com/kexi.project
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek