Re: calligra tarball contains kexi translations also contained in the kexi tarball (idem for krita)

[Friedrich W. H. Kossebau]

Am Dienstag, 27. Dezember 2016, 17:59:14 CET schrieb René J.V. Bertin:
> On Tuesday December 27 2016 16:33:58 Friedrich W. H. Kossebau wrote:
> > See thread "calligra 3.0.0 tarball" on this mailinglist, with some
> > background info in email
> 
> Apologies, I didn't read every message on that thread religiously ...

No problem, happens :) And a link is quickly passed on.

Better two people pointing issues out than noone.
Friedrich

Re: map support, Marble and Mac

[Friedrich W. H. Kossebau]

Am Montag, 26. Dezember 2016, 10:20:04 CET schrieb René J.V. Bertin:
> Hi!
> 
> Might I suggest to use macro_optional_find_package() to detect presence of
> Marble? From a packaging point of view it would be more elegant to be able
> to avoid opportunistic dependencies on large and complex projects like
> Marble.

Calligra uses macro_optional_find_package with Marble currently:
https://cgit.kde.org/calligra.git/tree/CMakeLists.txt#n543

So what do you mean?

Cheers
Friedrich

Re: packaging Calligra: common dependencies?

[Friedrich W. H. Kossebau]

Am Sonntag, 25. Dezember 2016, 12:06:42 CET schrieb René J.V. Bertin:
> Hi,
> 
> Sorry in advance if I could have scraped this information from the build
> instructions:
> 
> I'm starting to look at creating MacPorts ports for Calligra (starting with
> Karbon). I see that it's possible to build and package a set of Calligra
> libraries and components shared among all or a major subset of components.
> That's great because with the MacPorts approach the build and packaging
> steps are linked, meaning it's not possible to build everything once and
> then generate packages for individual components.

Currently the Calligra buildsystem expects the shared libs being part of the 
sources that are build, not being imported from the outside. There is no 
support for that.

So pruning is what you will need to do currently.

Cheers
Friedrich

Re: calligra tarball contains kexi translations also contained in the kexi tarball (idem for krita)

[Friedrich W. H. Kossebau]

Hi René,

Am Montag, 26. Dezember 2016, 20:04:06 CET schrieb René J.V. Bertin:
> Hi,
> 
> The venom is all in the title: the calligra and kexi tarballs both contain
> translations for kexi. The same applies to krita.
> 
> This is very annoying for packaging, unless I missed a CMake switch in
> Calligra's cmake file to filter out unwanted translations per product?
> 
> R.

Thanks for the hint, has already been spotted. 

See thread "calligra 3.0.0 tarball" on this mailinglist, with some background 
info in email 
https://mail.kde.org/pipermail/calligra-devel/2016-December/016535.html

Cheers
Friedrich

Re: Calligra and Okular versions

[Friedrich W. H. Kossebau]

Thanks for the heads-up, Jonathan.

Am Freitag, 9. Dezember 2016, 15:49:08 CET schrieb Jonathan Riddell:
> Recently Okular's internal version changed and so did the requirement
> for Okular by Calligra.
> 
> Okular is now set to 0.99.0 for the stable Applications/16.12 branch
> and Calligra wants 0.99.60.
> 
> How before these versions changed I had a version of Calligra master
> (due to become 3.0.0 shortly) which compiled fine with Okular from
> Applications/16.12
> http://build.neon.kde.org/job/xenial_stable_calligra_calligra_bin_amd64/1/
> 
> It would be a shame if Calligra released without a version of Okular
> that it worked with also being released.  Does Calligra work with
> Okular from Applications/16.12 ?

Yes, it does.

What happened is that Okular has 
ecm_setup_version(0.99.${KDE_APPLICATIONS_VERSION_MICRO}
  VARIABLE_PREFIX OKULAR
  VERSION_HEADER "${CMAKE_CURRENT_BINARY_DIR}/core/version.h"
  PACKAGE_VERSION_FILE "${CMAKE_CURRENT_BINARY_DIR}/
Okular5ConfigVersion.cmake")

and someone bumped KDE_APPLICATIONS_VERSION_MICRO from 90 to 0, but noone made 
sure the 0.99 gets bumped too. :/

Depending on whether 16.12.0 tarballs have already been made either Calligra 
needs to adapt to that now, or Okular could still get fixed.

Cheers
Friedrich

Selecting the needed po catalogs in the module dir (was: Re: calligra 3.0.0 tarball)

[Friedrich W. H. Kossebau]

Am Donnerstag, 8. Dezember 2016, 12:11:26 CET schrieb 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...

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

Cheers
Friedrich

Re: calligra 3.0.0 tarball

[Friedrich W. H. Kossebau]

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: Release, again

[Friedrich W. H. Kossebau]

Hi Dag,

Am Freitag, 25. November 2016, 12:14:05 CET schrieb Dag:
> Hi, everybody
> We are closing in on release I don't think I know of more than getting
> the migration stuff in.
> Has anybody anything else they think has to be done before release?
> 
> Boudewijn, is there anything we need to prepare before we (you) start
> creating tarballs.
> I had a look at the release script and couldn't find anything about
> calligra in the config file.

For a start you might perhaps also try the "old" Calligra-specific scripts 
from Cyrille. See them linked in section "Tarball creation" of https://
community.kde.org/Calligra/Release_Howto

> Also we are not releasing all apps, how do we handle that?

There is a check in the toplevel CMakeLists.txt which will disable all 
products tagged with STAGING in release build mode (near l.141). That's also 
how it was done in the last 2.9 releases.
So the source tarball would as before contain the complete snapshot of the 
repo, dumping things is then done at build time.

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

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

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

Cheers
Friedrich

KDiagram 2.6.0 released

[Friedrich W. H. Kossebau]

Hi,

KDiagram 2.6.0 has been tagged and is now available on the KDE servers.

http://download.kde.org/stable/kdiagram/2.6.0/src/
kdiagram-2.6.0.tar.xz.mirrorlist
commit 56aaece273f615da52e2f7ddd93c4b04d66c2fed
sha256 02788dad7e15c64b74a2d1073c5910469ab4cf46ba905030c1713dce45981882

KDiagram is the bundle of KChart (library for creating all kind of charts) and 
KGantt (library for creating Gantt diagrams).

Known users of either of those libraries are ...
... already:
  * Massif Visualizer
... in upcoming release:
  * KMyMoney
  * KDE PIM EventViews & IncidenceEditor
  * Calligra Plan & chart component
... perhaps in some upcoming release:
  * KReport/Kexi

For some background info on KDiagram see
https://marc.info/?l=kde-core-devel=142335191017238=2

Cheers
Friedrich

Re: "non standalone app bundle" builds on Mac

[Friedrich W. H. Kossebau]

Am Sonntag, 6. November 2016, 13:55:21 CET schrieb René J.V. Bertin:
> On Sunday November 06 2016 13:47:13 Friedrich W. H. Kossebau wrote:
> 
> Hi,
> 
> > For properly reaching Krita devs please use the ml kimageshop (sic, named
> > like> 
> > that for historic reasons):
> > https://mail.kde.org/mailman/listinfo/kimageshop
> 
> Thanks. Great, yet another mailing list subscription ... :)
> 
> 
> The question I raised isn't relevant to them only, of course, but also for
> the rest of Calligra.

Krita is now (since Krita v3) a project completely separated from Calligra (if 
you e.g. see "calligra" still mentioned in the repo structure path, that is 
legacy setup and has no meaning by itself).
Which also means "rest of Calligra" == "all of current Calligra" :)

So: to reach Krita developer community, use mentioned ml.

When it comes to Calligra and MacPorts, I do have not seen anyone working on 
macOS-related stuff. So if you have patches/improvements, there might be noone 
to discuss how-to-macOS. Which means if it does not break/screw the Linux 
build (or Windows when it comes to Kexi & Co.), your chance to rule.

Cheers
Friedrich

Re: "non standalone app bundle" builds on Mac

[Friedrich W. H. Kossebau]

Hi René,

Am Sonntag, 6. November 2016, 09:54:29 CET schrieb René J.V. Bertin:

> It turn out that Krita is one of those select fews. I haven't followed the
> split-off closely so I don't know if this ML is still the best place to
> raise questions about building on Mac, but I hope I can still reach at
> least some Krita devs here.


For properly reaching Krita devs please use the ml kimageshop (sic, named like 
that for historic reasons):
https://mail.kde.org/mailman/listinfo/kimageshop

Cheers
Friedrich

Re: KDiagram

[Friedrich W. H. Kossebau]

Hi Dag,

Am Freitag, 28. Oktober 2016, 16:49:50 CET schrieb Dag:
> As for KDiagram, I have a few issues.

Issues, but no showstoppers for the initial release, did I understand that 
correctly?

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

How can I reproduce that exactly? Please file that also as a bug, best for 
kdiagram:KChart, so it can be tracked.

Cheers
Friedrich

Re: KDiagram

[Friedrich W. H. Kossebau]

Hi,

Am Freitag, 28. Oktober 2016, 16:49:50 CET schrieb Dag:
> 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.

Currently I have just subscribed to working on release management of KDiagram, 
no time available for working on KGantt itself. So allow me to forward this 
discussion to the PIM people and also Andreas, hoping for some synergy :)

(Context: Calligra Plan, a project management program, where Dag is author & 
maintainer, uses KGantt from KDiagram. See https://calligra.org/plan/)

Cheers
Friedrich

Re: state of release and release plan

[Friedrich W. H. Kossebau]

Hi Dag & all,

Am Mittwoch, 26. Oktober 2016, 14:03:12 CEST schrieb 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.

If I speak openly that is also my subjective line of thinking.

Making a release of software means giving it to others and thus making a 
promise to them, so subscribing to moral responsibilities.

Even while having spent so much time and energy into the porting over the last 
two years, I am not sure I am motivated to spent my bit of needed time into 
maintenance where needed by non-contributors currently. At least when it comes 
to the main Calligra editor apps.

My personal interest is in the middleware and technology, and I joined the 
Calligra project because it was closest to what I would like to have, though 
with big plans for redesigning basic parts (and quite some draft branches are 
on my local disk). Which is also why I never officially signed up as 
maintainer of any of the maintainer-less apps, only for the plugins for Okular 
and some import filters.

Still, to get some momentum in this discussion, I have just taken the liberty 
to push a commit which removes Braindump, Karbon app & Stage app from release 
builds, as there is no-one even coming close to be a maintainer. At least with 
Stage I hope that commit will trigger someone to react, but then hope dies 
last, they say ;)
And by that commit I also express my hope that you the Plan, Sheets & Words 
maintainers will still do a release for your software, so that my porting 
contributions are coming to someone else's gain still.

Besides that though I have to state now (also to myself) that I have no 
personal motivation to drive or invest into any release work right now, as 
there is no itch to scratch for myself here, especially when looking at the 
consequences.

I will happily assist where possible though anyone with a Calligra 3.0 release 
for small related tasks.

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

Yes, thanks for the push :) Though I have had already started to play around 
with the packaging scripts the other WE. As written in private email, planning 
for release on latest Nov. 7th.

Cheers
Friedrich

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

[Friedrich W. H. Kossebau]

Am Montag, 12. September 2016, 13:37:26 CEST schrieb Boudewijn Rempt:
> Git commit deff966ee3041104f0e2bda587c94d58403670af by Boudewijn Rempt.
> Committed on 12/09/2016 at 13:37.
> Pushed by rempt into branch 'master'.
> 
> Fix a memory leak: the popup action should "own" the image collection
> 
> And the pattern background should check whether the popup still
> exists. This bug probably is also in Calligra.
> 
> CCMAIL:calligra-devel@kde.org
> 
> M  +15   -6libs/flake/KoPatternBackground.cpp
> M  +4-3libs/widgets/KoResourcePopupAction.cpp
> 
> http://commits.kde.org/krita/deff966ee3041104f0e2bda587c94d58403670af
> 
> diff --git a/libs/flake/KoPatternBackground.cpp
> b/libs/flake/KoPatternBackground.cpp index a2289b7..9f0a170 100644
> --- a/libs/flake/KoPatternBackground.cpp
> +++ b/libs/flake/KoPatternBackground.cpp
> @@ -37,6 +37,7 @@
> 
>  #include 
>  #include 
> +#include 
> 
>  class KoPatternBackgroundPrivate : public KoShapeBackgroundPrivate
>  {
> @@ -123,7 +124,7 @@ public:
>  QSizeF targetImageSizePercent;
>  QPointF refPointOffsetPercent;
>  QPointF tileRepeatOffsetPercent;
> -KoImageCollection * imageCollection;
> +QPointer imageCollection;
>  KoImageData * imageData;
>  };
> 
> @@ -131,7 +132,7 @@ public:
>  // 
> 
> 
> -KoPatternBackground::KoPatternBackground(KoImageCollection *
> imageCollection)
> +KoPatternBackground::KoPatternBackground(KoImageCollection
> *imageCollection)
>  : KoShapeBackground(*(new KoPatternBackgroundPrivate()))
> 
>  {
>  Q_D(KoPatternBackground);
> @@ -160,7 +161,9 @@ void KoPatternBackground::setPattern(const QImage
> ) {
>  Q_D(KoPatternBackground);
>  delete d->imageData;
> -d->imageData = d->imageCollection->createImageData(pattern);
> +if (d->imageCollection) {
> +d->imageData = d->imageCollection->createImageData(pattern);
> +}
>  }
> 
>  void KoPatternBackground::setPattern(KoImageData *imageData)
> @@ -358,7 +361,9 @@ void KoPatternBackground::fillStyle(KoGenStyle ,
> KoShapeSavingContext  style.addProperty("draw:fill", "bitmap");
>  style.addProperty("draw:fill-image-name", patternStyleName);
> 
> -context.addDataCenter(d->imageCollection);
> +if (d->imageCollection) {
> +context.addDataCenter(d->imageCollection);
> +}
>  }
> 
>  bool KoPatternBackground::loadStyle(KoOdfLoadingContext , const
> QSizeF &) @@ -383,9 +388,13 @@ bool
> KoPatternBackground::loadStyle(KoOdfLoadingContext , const QSizeF &
> return false;
> 
>  delete d->imageData;
> -d->imageData = d->imageCollection->createImageData(href,
> context.store()); -if (! d->imageData)
> +d->imageData = 0;
> +if (d->imageCollection) {
> +d->imageData = d->imageCollection->createImageData(href,
> context.store()); +}
> +if (! d->imageData) {
>  return false;
> +}
> 
>  // read the pattern repeat style
>  QString style = styleStack.property(KoXmlNS::style, "repeat");
> diff --git a/libs/widgets/KoResourcePopupAction.cpp
> b/libs/widgets/KoResourcePopupAction.cpp index 95f0192..1c27b0c 100644
> --- a/libs/widgets/KoResourcePopupAction.cpp
> +++ b/libs/widgets/KoResourcePopupAction.cpp
> @@ -50,6 +50,7 @@ public:
>  QMenu *menu;
>  KoResourceItemView *resourceList;
>  QSharedPointer background;
> +KoImageCollection *imageCollection;
>  KoCheckerBoardPainter checkerPainter;
>  };
> 
> @@ -83,8 +84,8 @@
> KoResourcePopupAction::KoResourcePopupAction(QSharedPointer rceSe qg->setCoordinateMode(QGradient::ObjectBoundingMode);
>  d->background = QSharedPointer(new
> KoGradientBackground(qg)); } else if (pattern) {
> -KoImageCollection *collection = new KoImageCollection();
> -d->background = QSharedPointer(new
> KoPatternBackground(collection)); +d->imageCollection = new
> KoImageCollection();
> +d->background = QSharedPointer(new
> KoPatternBackground(d->imageCollection));
> static_cast(d->background.data())->setPattern(pattern
> ->pattern()); }
> 
> @@ -116,7 +117,7 @@ KoResourcePopupAction::~KoResourcePopupAction()
>  }
> 
>  delete d->menu;
> -
> +delete d->imageCollection;
>  delete d;
>  }


Thanks for the cc:, Boud.

Just, this one results in a crash in ~KoResourcePopupAction() on the new
delete d->imageCollection;
when quitting the app (e.g. calligrastage) so this patch at least does not 
apply like is to Calligra codebase.

I have no big picture of the usage of imageCollection, so myself for now 
ignoring this memory leak reported here.

Cheers
Friedrich

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

[Friedrich W. H. Kossebau]

Am Dienstag, 13. September 2016, 07:22:56 CEST schrieb Boudewijn Rempt:
> Git commit fbd916d2af9cc025f505117fd1da13a29e6e3030 by Boudewijn Rempt.
> Committed on 13/09/2016 at 07:22.
> Pushed by rempt into branch 'master'.
> 
> Fix memory leak
> 
> ==10207== 424 (24 direct, 400 indirect) bytes in 1 blocks are definitely
> lost in loss record 11,215 of 12,325 ==10207==at 0x4C29670: operator
> new(unsigned long) (in
> /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==10207==by
> 0x321A1982: KoStyleManager::KoStyleManager(QObject*)
> (KoStyleManager.cpp:152) ==10207==by 0x31B41D3F:
> TextShapeFactory::newDocumentResourceManager(KoDocumentResourceManager*)
> const (TextShapeFactory.cpp:158) ==10207==by 0x6D70D3F:
> KoShapeBasedDocumentBase::KoShapeBasedDocumentBase()
> (KoShapeBasedDocumentBase.cpp:40) ==10207==by 0x50FB291:
> KisShapeController::KisShapeController(KisDocument*, KisNameServer*)
> (kis_shape_controller.cpp:71) ==10207==by 0x5344AD8:
> KisDocument::init() (KisDocument.cpp:591) ==10207==by 0x534B5CC:
> KisDocument::KisDocument() (KisDocument.cpp:527) ==10207==by 0x538013A:
> KisPart::createDocument() const (KisPart.cpp:197) ==10207==by
> 0x5293D47: KisCustomImageWidget::createNewImage()
> (kis_custom_image_widget.cc:273) ==10207==by 0x529503E:
> KisCustomImageWidget::createImage() (kis_custom_image_widget.cc:232)
> ==10207==by 0xC344390: QMetaObject::activate(QObject*, int, int,
> void**) (in /home/boud/dev/deps/lib/libQt5Core.so.5.6.1) ==10207==by
> 0xB2A6551: QAbstractButton::clicked(bool) (in
> /home/boud/dev/deps/lib/libQt5Widgets.so.5.6.1) ==10207==
> ==10207== 430 (24 direct, 406 indirect) bytes in 1 blocks are definitely
> lost in loss record 11,216 of 12,325 ==10207==at 0x4C29670: operator
> new(unsigned long) (in
> /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==10207==by
> 0x321A1960: KoStyleManager::KoStyleManager(QObject*)
> (KoStyleManager.cpp:151) ==10207==by 0x31B41D3F:
> TextShapeFactory::newDocumentResourceManager(KoDocumentResourceManager*)
> const (TextShapeFactory.cpp:158) ==10207==by 0x6D70D3F:
> KoShapeBasedDocumentBase::KoShapeBasedDocumentBase()
> (KoShapeBasedDocumentBase.cpp:40) ==10207==by 0x50FB291:
> KisShapeController::KisShapeController(KisDocument*, KisNameServer*)
> (kis_shape_controller.cpp:71) ==10207==by 0x5344AD8:
> KisDocument::init() (KisDocument.cpp:591) ==10207==by 0x534B5CC:
> KisDocument::KisDocument() (KisDocument.cpp:527) ==10207==by 0x538013A:
> KisPart::createDocument() const (KisPart.cpp:197) ==10207==by
> 0x5293D47: KisCustomImageWidget::createNewImage()
> (kis_custom_image_widget.cc:273) ==10207==by 0x529503E:
> KisCustomImageWidget::createImage() (kis_custom_image_widget.cc:232)
> ==10207==by 0xC344390: QMetaObject::activate(QObject*, int, int,
> void**) (in /home/boud/dev/deps/lib/libQt5Core.so.5.6.1) ==10207==by
> 0xB2A6551: QAbstractButton::clicked(bool) (in
> /home/boud/dev/deps/lib/libQt5Widgets.so.5.6.1) ==10207==
> 
> Probably also present in Calligra
> 
> CCMAIL:calligra-devel@kde.org
> 
> M  +2-0plugins/flake/textshape/kotext/styles/KoStyleManager.cpp
> 
> http://commits.kde.org/krita/fbd916d2af9cc025f505117fd1da13a29e6e3030
> 
> diff --git a/plugins/flake/textshape/kotext/styles/KoStyleManager.cpp
> b/plugins/flake/textshape/kotext/styles/KoStyleManager.cpp index
> 4dc0cbb..9544133 100644
> --- a/plugins/flake/textshape/kotext/styles/KoStyleManager.cpp
> +++ b/plugins/flake/textshape/kotext/styles/KoStyleManager.cpp
> @@ -187,6 +187,8 @@ KoStyleManager::KoStyleManager(QObject *parent)
> 
>  KoStyleManager::~KoStyleManager()
>  {
> +delete d->footNotesConfiguration;
> +delete d->endNotesConfiguration;
>  delete d;
>  }

Thanks, indeed also applies to Calligra master, handled it.
Though there are even more related issues, see
http://commits.kde.org/calligra/a267973803f0ac9caf3b0b2766706fb2520baaaf

Cheers
Friedrich

[Differential] [Closed] D364: Move KoFindToolbar to Words, it's only user

[kossebau (Friedrich W. H. Kossebau)]

This revision was automatically updated to reflect the committed changes.
Closed by commit rCALLIGRAd628f85b24b3: Move KoFindToolbar to Words, it's only 
user (authored by kossebau).

CHANGED PRIOR TO COMMIT
  https://phabricator.kde.org/D364?vs=895=6836#toc

REPOSITORY
  rCALLIGRA Calligra

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D364?vs=895=6836

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

AFFECTED FILES
  libs/main/CMakeLists.txt
  libs/main/KoFindToolbar.cpp
  libs/main/KoFindToolbar.h
  libs/main/KoFindToolbar_p.h
  words/part/CMakeLists.txt
  words/part/KWView.cpp
  words/part/widgets/KoFindToolbar.cpp
  words/part/widgets/KoFindToolbar.h
  words/part/widgets/KoFindToolbar_p.h

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

To: kossebau, boemann, deniskuplyakov, staniek
Cc: Calligra-Devel-list

[Maniphest] [Commented On] T3755: Kexi API docs missing in the calligra section

[kossebau (Friedrich W. H. Kossebau)]

kossebau added a comment.


  In https://phabricator.kde.org/T3755#55412, @staniek wrote:
  
  > Are we sure?
  >
  > For example KDevelop has kdevplatform 
https://api.kde.org/extragear-api/kdevelop-apidocs/index.html, just released 
yesterday, but Calligra does not:
  >
  > https://api.kde.org/bundled-apps-api/calligra-apidocs/
  
  
  This is because the pages generated below kdevelop-apidocs include both repos 
kdevelop and kdevplatform. The script there is not run on each repo separately, 
but run at the checkout of both.
  But only kdevplatform has a Mainpage.dox file. So by that old kdelibs script 
system of just generating documentation for things in the folders below the 
deepest Mainpage.dox files this results in what can be seen.
  
  The script also used to do the same before with the repos krita, kexi & 
calligra, generating all documentation for all of them in one go below 
calligra-apidocs.
  Which of course resulted in a mess, due to the forked classes and also was 
wrong with krita no longer being a Calligra project.
  So @winterz on my request changed the setup to generate the documentation for 
all three repos separately. Due to kexi having KUndo duplicated and also having 
a different code layout, I decided against still generating kexi & calligra 
docs together.
  
  The only thing still missing for that setup is being listed on 
https://api.kde.org/other.php
  
  But indeed this is just for now, as intermediate solution. Someone  needs to 
look into a future-proof setup for the separate contributor-oriented complete 
source-code covering generation of API dox. Not me, too much to do already, 
only available for giving over-smart comments ;)
  
  @staniek I would recommend to move src/Mainpage.dox to the toplevel dir (and 
adopting the EXCLUDE entry). Because right now this results in the additional 
subsection "Kexi" on https://api.kde.org/bundled-apps-api/kexi-apidocs/ without 
any use.

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

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

To: kossebau
Cc: piggz, kossebau, Calligra-Devel-list, bcooksley, ochurlaud, sysadmin, 
staniek, blazquez

[Maniphest] [Commented On] T3755: Kexi API docs missing in the calligra section

[kossebau (Friedrich W. H. Kossebau)]

kossebau added a comment.


  In https://phabricator.kde.org/T3755#55355, @staniek wrote:
  
  > > there is not much content right now on the kexi pages
  >
  > Right if you mean 'special pages' with prose. But there's plenty of doxygen 
API docs in the context of classes and functions. Over 4000 lines with @ or \ 
tag.
  
  
  I meant "kexi pages" = "generated html pages" :)
  Your comment leaves me unsure if it was understood how it comes that right 
now only those pages are created from the existing api dox comments?
  If not, please have another look at what I wrote about the "tree of nodes 
with Mainpage.dox files" and ping me on irc for resolving the missing details :)

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

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

To: kossebau
Cc: kossebau, Calligra-Devel-list, bcooksley, ochurlaud, sysadmin, staniek, 
blazquez

[Maniphest] [Commented On] T3755: Kexi API docs missing in the calligra section

[kossebau (Friedrich W. H. Kossebau)]

kossebau added a comment.


  For one, Kexi is currently covered by api.kde.org, just not explicitely 
listed on https://api.kde.org/other.php (similar to krita).
  @ochurlaud  Do you have access to that page and could add Kexi & Krita there?
  
  Kexi: https://api.kde.org/bundled-apps-api/kexi-apidocs/
  Krita: https://api.kde.org/bundled-apps-api/krita-apidocs/
  
  Now, there is not much content right now on the kexi pages. That is, because 
AFAIK those api dox pages are still generated by the old kdelibs doxygen 
scripts. Which organize things by the Mainpage.dox files they find in the repo. 
And do that in a way, that if they find a Mainpage.dox file in a folder, they 
will ignore content in any sibling folders below the next Mainpage.dox file at 
a higher level, unless there is a Mainpage.dox file in the sibling as well, 
which then would span a group of api dox for that section (image a tree of with 
Mainpage.dox files as nodes, and for the leaf nodes there is a separate api dox 
 section generated for any code in the folder starting at that leaf 
Mainpage.dox).
  So the file src/widget/undo/Mainpage.dox is masking any other dirs with code 
right now, resulting in the content visible on the linked pages.
  A fix would be to remove widget/undo/Mainpage.dox. That should result in 
apidox coverage for everything in src/ again (and that is not in EXCLUDE in 
src/Mainpage.dox).
  If you would like grouping per subfolder of src, add Mainpage.dox files into 
each of those direct subfolders, as new leafs to the Mainpage.dox tree :)
  
  All this is for complete API dox of the complete sources code, targetted at 
contributors. Which is a separate purpose to what the current redesign of 
api.kde.org targets on, which is documenting the public API of KDE products, so 
targetting 3rd-party developers of libraries with published API (which of 
course can also be KDE 3rd-parties, when using other KDE products in own 
projects).
  Where to put the "old style" content of api.kde.org (so anything e.g. at 
https://api.kde.org/other.php but also https://api.kde.org/history4.php), so 
the documentation targettted at project contributors, that is still open to 
discussion.
  
  For the libs in the "calligra" repo since the port there is no published API 
yet again, noone has looked into making the installed headers usable (and thus 
they are not even installed ATM). So no use to be on "new" api.kde.org right 
now.
  
  No idea about Kexi, does kexi itself install libs with a public API?

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

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

To: kossebau
Cc: kossebau, Calligra-Devel-list, bcooksley, ochurlaud, sysadmin, staniek, 
blazquez

Re: Qt version

[Friedrich W. H. Kossebau]

Am Mittwoch, 10. August 2016, 14:27:06 CEST schrieb Dag:
> I added a 5.7 specific thing recently, which prompts the question:
> which qt version will be used in the release?

I personally would not mind bumping the minimal required versions to Qt 5.6 
and KF5 5.16 at least.

Reasoning:
Noone (I assume) is testing things with the current minimum versions. So we 
have no idea if things even build at all.
And there is no defined target group for the release from which minimum 
versions could be derived.

* rolling-release distris have Qt 5.6 and KF5 5.2* already -> covered
* binary packages for win/osx/* would use a recent Qt/KF5 anyway -> covered
* new and older LTS distris: no idea which important ones there are and what 
cmake/Qt/KF5 they have. Perhaps something like appimage could be used as 
escape, if someone is interested in having one or the other Calligra app there

So the question is: does any Calligra app maintainer/contributor target (or 
use) any specific LTS distri? So that it makes sense to do the extra efforts 
of ifdefs or not using newer features for their fellow contributors?

SailfishOS is also porting to Qt 5.6 currently, so the people (like me) who 
look forward to get SailfishOS Documents finally use unforked Calligra code 
would be fine with Qt 5.6 as well (KF5 might be a different, more complicated 
story on SFOS, to be solved independently).

Cheers
Friedrich

[Differential] [Accepted] D2702: flake: Include rather than

[kossebau (Friedrich W. H. Kossebau)]

kossebau accepted this revision.
kossebau added a reviewer: kossebau.
kossebau added inline comments.
This revision is now accepted and ready to land.

INLINE COMMENTS

> KoSnapStrategy.cpp:34
>  
>  #if defined(_MSC_VER) && (_MSC_VER < 1800)
>  #define isfinite(x) (double)(x)

Please also remove this no longer needed #define, given plain `isfinite` is no 
longer used.

REPOSITORY
  rCALLIGRA Calligra

BRANCH
  master

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

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

To: heikobecker, Calligra-Devel-list, kossebau
Cc: kossebau, staniek

Re: kdiagram in calligra project component?

[Friedrich W. H. Kossebau]

Hi Jarosław,

Am Montag, 5. September 2016, 01:03:32 CEST schrieb Jaroslaw Staniek:
> Hi,
> Background: The kde:sysadmin/repo-metadata git repo now replaces the
> project.kde.org stuff.
> I am moving kdb, kreport and kproperty repo metadata to projects/calligra
> from playground/libs as I see them more fit to the new location and they
> are, well, developed within our master project Calligra anyway, regardless
> of repo fragmentation.
> 
> That's not my play, the kde:releaseme tool which I'd be trying to use for
> preparing releases depends on the projects metadata so it's good to have
> the metadata as correct as possible.
> 
> Now, that's mostly a question to Friedrich:
> 
> There is projects/extragear/graphics/kdiagram. It describes "Powerful
> libraries (KChart, KGantt) for creating business diagrams". Do you think
> that kdiagram better fits to calligra/ and not so much to graphics/?
> ​KChart clearly implements office-oriented objects: data charts and Gantt
> charts.

For one, those paths in the repo hierachy are just legacy and long-term will 
be dropped, for a flat list of repos.

Then, that description is copied unchanged from marketing-buzzword loaded 
origin :)

I had put kdiagram into projects/extragear/graphics after discussion as 
diagrams can be used for lots of things. There is a (business) world outside 
offices :)
Current users known to me of either KChart or KGantt are Massif-Visualizer, 
something in KDEPIM, KMyMoney, Plan, a Calligra shape plugin and a KReport 
plugin.
So KDiagram is a project shared by many KDE projects, nothing Calligra-centric 
there. So I do not see a reason to move this.

More, as long as that legacy adressing hierarchy of repos exists, I would 
rather recommend to move non-Calligra-only stuff like KDb, KReport & KProperty 
somewhere into the generic extragear namespace, as those libs target 
developers, unlike the "apps" which make up what currently is known as 
Calligra and what is about end user products. By being in the generic 
extragear namespace this might help stressing the libs general usability 
outside of the existing set of Calligra apps.

My 2 cents on that :)
Friedrich

Adapting to changed config file names/locations in master

[Friedrich W. H. Kossebau]

Hi,

I just pushed a row of commits to master which have changed a the location of 
some config files. So if you have some custom settings with your local 
development setup you would like to recover, please see below for the needed 
file location/name adaptions.

The goal of the commits was to make the applications properly startable by D-
Bus, to follow the appdata naming scheme some more and to cleanup the 
installation a little bit more, by having more consistent names and 
namespaces.

# Adapt app config files:
# e.g. $HOME/.config/
export MYCONFIGDIR=$HOME/where/your/user/config/is

mv $MYCONFIGDIR/planrc $MYCONFIGDIR/calligraplanrc
mv $MYCONFIGDIR/planworkrc $MYCONFIGDIR/calligraplanworkrc
mv $MYCONFIGDIR/sheetsrc   $MYCONFIGDIR/calligrasheetsrc
mv $MYCONFIGDIR/stagerc$MYCONFIGDIR/calligrastagerc
mv $MYCONFIGDIR/wordsrc$MYCONFIGDIR/calligrawordsrc

# Adapt xmlgui config files:
# e.g. $HOME/.local/share/kxmlgui5
export MYXMLGUIDIR=$HOME/where/your/user/xmlgui/is

mv $MYXMLGUIDIR/plan/plan.rc $MYXMLGUIDIR/calligraplan/calligraplan.rc
mv $MYXMLGUIDIR/planwork/planwork.rc $MYXMLGUIDIR/calligraplanwork/
calligraplanwork.rc
mv $MYXMLGUIDIR/sheets/sheets.rc $MYXMLGUIDIR/calligrasheets/calligrasheets.rc
mv $MYXMLGUIDIR/stage/stage.rc   $MYXMLGUIDIR/calligrastage/calligrastage.rc
mv $MYXMLGUIDIR/words/words.rc   $MYXMLGUIDIR/calligrawords/calligrawords.rc


Which also reminds that someone needs to write config migration code for 2.* -
> 3.0, see https://phabricator.kde.org/T469

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

Re: Adding stable/l10n-kf5 translations for "krita/3.0" branch

[Friedrich W. H. Kossebau]

Am Montag, 4. Juli 2016, 20:53:08 CEST schrieb Burkhard Lück:
> Am Montag, 4. Juli 2016, 13:07:50 CEST schrieb Friedrich W. H. Kossebau:
> > Hi translation admins,
> > 
> > seems we forgot to set up translations for stable/l10n-kf5 when Krita 3.0
> > was branched off.
> > 
> > The branch name for the stable release version is "krita/3.0".
> > 
> > Please add that in the setup.
> > 
> > If I learned things correctly last WE that the fix would be to add in
> > branches/stable/l10n-kf5/scripts/get_paths for the function get_branch an
> > entry like this?
> > 
> > calligra_krita)
> > 
> > echo "krita/3.0"
> > ;;
> > 
> > Though seems also other functions need more fixes, when I compare to the
> > get_paths one for trunk, e.g. get_po_path and get_path
> > 
> > Well, you know your scripts and I for now better try to not also mess
> > around there :)
> 
> kde_projects.xml still has:
> 
> none
> none
> master
> none

Aha, missed that things also need to be set there. Who can do that these days? 
IIRC (now) that was done via projects.kde.org settings before, what is the 
replacement?
 
> And what about other Calligra apps? Scripty tracks stable kde4 from
> calligra/ 2.9

While the krita repo is inside the calligra domain, Krita is now an project 
completely independent of Calligra. Just for legacy reasons krita is still 
there in the repo tree, could also be extragear/graphics.

"stable kde4" for "calligra/2.9" is fine still, at least kexi has some 
inofficial maintenance in that branch still.

Hopefully what remains Calligra these days also sees a 3.0 release soon, we 
are working on that, will take a few more weeks.

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

Re: Plan/KGantt

[Friedrich W. H. Kossebau]

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?

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

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

(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

Re: Introduction of a "type mode" and an "unicode mode" of input

[Friedrich W. H. Kossebau]

Am Sonntag, 3. Juli 2016, 12:40:52 CEST schrieb Jaroslaw Staniek:
> On 3 July 2016 at 11:58, René J.V.  wrote:
> > On Sunday July 03 2016 11:28:28 Jaroslaw Staniek wrote:
> > >On a GUI level: There's KDE GUI for that (there are many equivalents):
> > >https://utils.kde.org/projects/kcharselect/
> > 
> > Does that have a KF5 equivalent yet?
> 
> ​Nope and for a reason. 

May I allow myself to correct things a little?
(Good to see I am not the only one whose memory sometimes fail :) )

There is both a standalone app called kcharselect, which the above link is 
about. And there is a Qt5/KF5-based version of it.

Next, there has been a utility class KCharSelect in kdelibs which allowed to 
pick a character (sharing a lot of code with the above app).
And this class is also part of KF5, in the module KWidgetAddons:
https://api.kde.org/frameworks/kwidgetsaddons/html/classKCharSelect.html

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

[Differential] [Closed] D2058: Make TestXmlReader/TestXmlReaderWithoutSpaces handle translated error messages

[kossebau (Friedrich W. H. Kossebau)]

This revision was automatically updated to reflect the committed changes.
Closed by commit rCALLIGRA9f1ebd6d901a: Make 
TestXmlReader/TestXmlReaderWithoutSpaces handle translated error messages 
(authored by kossebau).

REPOSITORY
  rCALLIGRA Calligra

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D2058?vs=4887=4896

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

AFFECTED FILES
  libs/odf/tests/TestXmlReader.cpp
  libs/odf/tests/TestXmlReaderWithoutSpaces.cpp

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

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

[Differential] [Request, 8 lines] D2058: Make TestXmlReader/TestXmlReaderWithoutSpaces handle translated error messages

[kossebau (Friedrich W. H. Kossebau)]

kossebau created this revision.
kossebau added a reviewer: Calligra-Devel-list.
Restricted Application added projects: Kexi, Calligra: 3.0.

REVISION SUMMARY
  Linking KI18n results in Qt translations being loaded on start. And
  QXmlStreamReader, used internally by KoXmlDocument, returns translated error 
messages.
  So running in a non-en locale still testing the english strings will fail.
  
  Checking undocumented error strings is fragile already, so relying on a 
certain
  translation context does not make things a lot worse.

TEST PLAN
  Tests no longer fail with Qt translations installed and running in a non-en
  locale.

REPOSITORY
  rCALLIGRA Calligra

BRANCH
  fixTestXmlReaderTestingTranslatedErrorMessages

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

AFFECTED FILES
  libs/odf/tests/TestXmlReader.cpp
  libs/odf/tests/TestXmlReaderWithoutSpaces.cpp

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

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

Re: Contributing again

[Friedrich W. H. Kossebau]

Hi Dag,

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

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.

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.
Then the support for currencies from KLocale is not (yet) covered by Qt5, an 
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 :)

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

Re: What to do with the Krita & Calligra?

[Friedrich W. H. Kossebau]

Am Montag, 30. Mai 2016, 19:03:39 CEST schrieb Jaroslaw Staniek:
> On 30 May 2016 at 18:27, Friedrich W. H. Kossebau <kosse...@kde.org> wrote:
> > Am Montag, 30. Mai 2016, 17:20:58 CEST schrieb Boudewijn Rempt:
> > > On Mon, 30 May 2016, Friedrich W. H. Kossebau wrote:
> > > > So this is about being able to install Krita3 next to e.g. Calligra
> > > > Words2.9 or Karbon2.9, right?
> > > > So where do you expect problems here, where would/could things
> > 
> > installed
> > 
> > > > clash, assuming at least the krita app program has been put into a
> > > > separate
> > > > package?
> > > 
> > > Yes -- I haven't tested it, but I expect problems there. Because, well
> > > Murphy.
> > 
> > The ones to test it would/should be the distri packagers IMHO :)
> > 
> > Problem here is, we do not have much feedback by them, as they, unless
> > following closely Krita development, might not know about the upcoming
> > Krita 3
> > release and thus also have not yet started packaging or giving things some
> > more testing.
> > At least I only saw the email by Cyrille to
> > kde-distro-packag...@kde.org for
> > Krita 3.0 Beta in April, but nothing else. Is there another list?
> 
> I am usually sending announcements to ​kde-announce-a...@kde.org​.

Right, but that one is for the actual release, here we are talking about 
prerelease announcement to packagers. So the packagers have the chance to do 
testing and packaging of the official software version in time for the actual 
release.
So that users, when they read about the announcement, are able to get the 
stuff from their package manager, if they are on a rolling release distri :) 
And not have to read the release news, look, not find it packaged, be 
disappointed and forget about it again.
And so that the packagers can find issues in time, so we developers can fix 
things up before the release is announced.

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

Re: What to do with the Krita & Calligra?

[Friedrich W. H. Kossebau]

Am Montag, 30. Mai 2016, 17:20:58 CEST schrieb Boudewijn Rempt:
> On Mon, 30 May 2016, Friedrich W. H. Kossebau wrote:
> > So this is about being able to install Krita3 next to e.g. Calligra
> > Words2.9 or Karbon2.9, right?
> > So where do you expect problems here, where would/could things installed
> > clash, assuming at least the krita app program has been put into a
> > separate
> > package?
> 
> Yes -- I haven't tested it, but I expect problems there. Because, well
> Murphy.

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

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

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

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

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

Re: What to do with the Krita & Calligra?

[Friedrich W. H. Kossebau]

Am Montag, 30. Mai 2016, 16:39:54 CEST schrieb Friedrich W. H. Kossebau:
> Hi,
> 
> Am Montag, 30. Mai 2016, 16:14:32 CEST schrieb Boudewijn Rempt:
> > Hi,
> > 
> > Tomorrow we'll release Krita 3.0.
> 
> So awesome to have reached that point :)
> 
> > At that point, the stable version
> > of Krita is no longer part of Calligra. On the other hand, Krita is
> > still part of the last stable release of Calligra, which makes it
> > hard for distributions to package both and make them coinstallable.
> 
> Does it? Did anyone report problems?

To be more precise:
do you expect people being able to install Krita3 next to Krita2.9? I guess 
no, given the conflict at least when it comes to executable name (and menu 
entries).

So this is about being able to install Krita3 next to e.g. Calligra Words2.9 
or Karbon2.9, right?
So where do you expect problems here, where would/could things installed 
clash, assuming at least the krita app program has been put into a separate 
package?
Plugins and libs should not, given the libs renamed and the plugins living in 
different folders (and lookup methods).
Any other resources where things might clash? If there are, possibly worth to 
check also Calligra3 & Krita3 for such.

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

Re: What to do with the Krita & Calligra?

[Friedrich W. H. Kossebau]

Hi,

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

So awesome to have reached that point :)

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

Does it? Did anyone report problems?

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

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

> * Make a Calligra 2.9 release without Krita

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

> * Accept the problem and do nothing

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

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

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

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

Re: Calligra - FTBFS - due to VC?

[Friedrich W. H. Kossebau]

Am Dienstag, 29. März 2016, 07:27:07 CEST schrieb Boudewijn Rempt:
> For Krita, and so I guess for Calligra as well, the right version is 0.7.
> Thorsten Zachmann is working on the port to 1.2, but he hasn't pushed
> anything yet.

Okay.

So translated in some tasks for changing settings on CI for now (as I assume 
those settings are admin-only, nothing normal developers can help with, 
right?)

Please see
https://phabricator.kde.org/T1992 (use only 0.7.* with any Vc builds)
https://phabricator.kde.org/T1993 (use "qt4" build of Vc as dep for Calligra 
Qt4 build)
https://phabricator.kde.org/T1994 (add Vc as build dep to krita build)

Cheers
Friedrich

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

Re: Calligra - FTBFS - due to VC?

[Friedrich W. H. Kossebau]

Am Dienstag, 29. März 2016, 11:36:18 CEST schrieb Ben Cooksley:
> Hi Calligra Developers,
> 
> It appears Calligra currently fails to build on the CI system, due to
> ifdef's which are dependent on VC variables. This is despite VC being
> found (depending on a too new / too old version / missing an include?)
> 
> Please see
> https://build.kde.org/view/branchGroup%20kf5-qt5/job/calligra%20master%20kf
> 5-qt5/5/PLATFORM=Linux,compiler=gcc/consoleFull
> 
> Could someone take a look and fix it please?

Seems CI uses Vc 1.2 for qt5/kf5 stable builds and even Vc master for master 
kf5-qt5.
Was that done by requests of Krita devs? Which would be fine, just needs 
Calligra to follow any changes needed then.

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

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

Re: Review Request 127371: Support selections in Calligra ODT plugin for Okular (main textflow-only for now)

[Friedrich W. H. Kossebau]

> On March 18, 2016, 7:54 p.m., Camilla Boemann wrote:
> > In general my reservations is the same as you explain - an entire method 
> > just to enable a plugin
> > 
> > in theory it would be possible to use selectionRect but I conceede it would 
> > be really un-economical

I so hoped you had a better idea :) Too bad then.
At least the code is isolated and does not interfer with other code, so if we 
hopefully one day can discard it again due to native selection possible it 
could be simply dropped again without any problems.


> On March 18, 2016, 7:54 p.m., Camilla Boemann wrote:
> > libs/textlayout/KoTextLayoutEndNotesArea.h, line 48
> > <https://git.reviewboard.kde.org/r/127371/diff/1/?file=449993#file449993line48>
> >
> > apidox pls since it's use is so specific

Added a longer APIDOX comment to KoTextLayoutArea::generateCharAreaInfos() 
where also all other area methods have all their comments.


> On March 18, 2016, 7:54 p.m., Camilla Boemann wrote:
> > libs/textlayout/KoTextLayoutTableArea.cpp, line 287
> > <https://git.reviewboard.kde.org/r/127371/diff/1/?file=449996#file449996line287>
> >
> > because for painting we want to repeat the headers on every page :)

But isn't that ensured by the separate loops for the header rows and the 
`firstRow` calculation?
I just had another look, and now even less than before grasp what both 
`testRow` and `visitedCells` are supposed to do in the end.
Need to catch you on irc to teach me :)
So keeping this TODO for now and doing with commit including it, as something 
here either is fishy or needs better documentation for newbies like me :)


- Friedrich W. H.


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


On March 18, 2016, 12:56 a.m., Friedrich W. H. Kossebau wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127371/
> ---
> 
> (Updated March 18, 2016, 12:56 a.m.)
> 
> 
> Review request for Calligra and Camilla Boemann.
> 
> 
> Repository: calligra
> 
> 
> Description
> ---
> 
> A first approach to collect chars and their positions on a given page, as 
> needed by Okular.
> 
> I followed the logic used for painting, as that one also needs to calculate 
> what content is part of a certain page, so copying the algorithm seemed most 
> obvious for a start.
> 
> Disadvantage: This approach needs access to internal data of the area 
> objects, so I had to add the code to the actual *Area classes. So they now 
> carry logic for a currently single use-case, which also is not the most 
> typical. Surely not a lot of code, but ideally this special need for the 
> Okular plugin should not add its payload for everyone.
> 
> So looking for better ideas here, at least for later.
> 
> TODOs for the future:
> - text from master pages (headers/footers)
> - text in objects (floating text boxes, diagrams, whatever)
> - include header/paragraph numbering/bullet points
> - only add line-breaks for real paragraph ends perhaps
> 
> Please give this some first round of feedback. IMHO it already adds value, as 
> it finally allows to copy text from the main textflow.
> So would not mind to have this as-is for 3.0, to be improved than at least 
> later, if not before. Unless it is unacceptable for good reasons :)
> 
> In a perfect future Okular´s plugin API will allow native selections, so all 
> the knowledge about text flow is not lost. But for now we have to support the 
> API which exists.
> 
> (Short note: I will not be able to instantly reply, currently seeing to 
> replace broken IT, might take another week at least, no email or irc for now. 
> This patch here was already uploaded before things turned defunct locally, so 
> pushing it out now for review at least).
> 
> 
> Diffs
> -
> 
>   extras/okularodtgenerator/OkularOdtGenerator.h c4404c4 
>   extras/okularodtgenerator/OkularOdtGenerator.cpp d1d428d 
>   libs/textlayout/KoCharAreaInfo.h PRE-CREATION 
>   libs/textlayout/KoTextLayoutArea.h 27934d7 
>   libs/textlayout/KoTextLayoutArea.cpp bacfa58 
>   libs/textlayout/KoTextLayoutEndNotesArea.h 6c1eb12 
>   libs/textlayout/KoTextLayoutEndNotesArea.cpp 2c1e241 
>   libs/textlayout/KoTextLayoutTableArea.h 8d912ee 
>   libs/textlayout/KoTextLayoutTableArea.cpp 4d2cdc1 
> 
> Diff: https://git.reviewboard.kde.org/r/127371/diff/
> 
> 
> Testing
> ---
> 
> Normal text, text in tables, text in generated content, footnotes & endnotes 
> could be selected in the ODT (& DOC/DOCX/WPD) files I tried.
> 
> 
> Thanks,
> 
> Friedrich W. H. Kossebau
> 
>

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

Review Request 127371: Support selections in Calligra ODT plugin for Okular (main textflow-only for now)

[Friedrich W. H. Kossebau]

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

Review request for Calligra and Camilla Boemann.


Repository: calligra


Description
---

A first approach to collect chars and their positions on a given page, as 
needed by Okular.

I followed the logic used for painting, as that one also needs to calculate 
what content is part of a certain page, so copying the algorithm seemed most 
obvious for a start.

Disadvantage: This approach needs access to internal data of the area objects, 
so I had to add the code to the actual *Area classes. So they now carry logic 
for a currently single use-case, which also is not the most typical. Surely not 
a lot of code, but ideally this special need for the Okular plugin should not 
add its payload for everyone.

So looking for better ideas here, at least for later.

TODOs for the future:
- text from master pages (headers/footers)
- text in objects (floating text boxes, diagrams, whatever)
- include header/paragraph numbering/bullet points
- only add line-breaks for real paragraph ends perhaps

Please give this some first round of feedback. IMHO it already adds value, as 
it finally allows to copy text from the main textflow.
So would not mind to have this as-is for 3.0, to be improved than at least 
later, if not before. Unless it is unacceptable for good reasons :)

In a perfect future Okular´s plugin API will allow native selections, so all 
the knowledge about text flow is not lost. But for now we have to support the 
API which exists.

(Short note: I will not be able to instantly reply, currently seeing to replace 
broken IT, might take another week at least, no email or irc for now. This 
patch here was already uploaded before things turned defunct locally, so 
pushing it out now for review at least).


Diffs
-

  extras/okularodtgenerator/OkularOdtGenerator.h c4404c4 
  extras/okularodtgenerator/OkularOdtGenerator.cpp d1d428d 
  libs/textlayout/KoCharAreaInfo.h PRE-CREATION 
  libs/textlayout/KoTextLayoutArea.h 27934d7 
  libs/textlayout/KoTextLayoutArea.cpp bacfa58 
  libs/textlayout/KoTextLayoutEndNotesArea.h 6c1eb12 
  libs/textlayout/KoTextLayoutEndNotesArea.cpp 2c1e241 
  libs/textlayout/KoTextLayoutTableArea.h 8d912ee 
  libs/textlayout/KoTextLayoutTableArea.cpp 4d2cdc1 

Diff: https://git.reviewboard.kde.org/r/127371/diff/


Testing
---

Normal text, text in tables, text in generated content, footnotes & endnotes 
could be selected in the ODT (& DOC/DOCX/WPD) files I tried.


Thanks,

Friedrich W. H. Kossebau

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

Re: Resetting metadata after new from template ?

[Friedrich W. H. Kossebau]

Hi Pierre,

Am Dienstag, 2. Februar 2016, 22:21:59 schrieb Pierre:
> On Tuesday, February 02, 2016 02:08:53 PM Jaroslaw Staniek wrote:
> > On 1 February 2016 at 23:20, Pierre  wrote:
> > > Hi
> > > 
> > > Right now, when we create a new empty document (at least for words),
> > > like
> > > any
> > > other office suite, it is created from a template. But we currently lack
> > > the
> > > reset of some metadata from our templates, leading to funny situations…
> 
> For
> 
> > > instance, any document created by calligra using the A4 template is more
> > > than
> > > 7 years old :)
> > > 
> > > We have several possible fix :
> > > - strip metadata from templates : we would still copy the metadata for
> 
> user
> 
> > > templates, including creation date, bad imho
> > > - strip all metadata when creating a file from template : bad too, users
> > > could
> > > have specific metadata they don't want to lose
> > > - override specific metadata like the creation date with sane values
> > > 
> > > Each one is very simple to implement, I just don't know which one is the
> > > best.
> > > I would go for the third option, but I don't have a list of metadata to
> > > erase.
> > > (we already override the generator BTW, but elsewhere in the saving
> > > code)
> > > 
> > > Any thoughts on this ?
> > 
> > ​Very interesting finding​
> > ​, Pierre.​
> > If you ask me, the 3rd option looks best. Documenting the new behaviour,
> > whatever it is, in the API docs, would be useful.
> 
> I just went through the ODF 1.2 spec part regarding metadata, I think we
> should reset all the meta data defined in the spec except
> "meta:user-defined"… And remember to fill in the meta:template with the
> XLink to the source template.
> If nobody disagrees nor sees anything hazardous in it, I'll implement that.

Happy to see you pick this up, I have found this annoying/funny as well :)

And I agree with & support your implementation plan basically, just a few 
modifications I would like to propose, read on.

IMHO the ODF spec has a flaw here WRT metadata and templates. There should be 
separate metadata for the actual template, and separate metadata for the to-
be-generated document. The first can be used as usual, to know more about the 
template itself when managing templates, and the second can be used to preset 
metadata of the actual generated document, as it fits (e.g. keywords, 
language, or whatever user-defined keys are standard with the organisation 
using the documents). (someone should bring this up in the OASIS TC, what, 
me?)

But we have to deal now with what there is in the current spec. So I would 
agree that resetting/dumping most metadata on document creation makes sense.

For the pre-defined metadata (as in ODF 1.2, §4.3.2) I think the following 
metadata could be kept though, as they are about the document/content type and 
less about the template, or only really make sense with the actual document.
So if they are present and set, they could be considered to target the created 
document, right?
* 
* 
* 

For  and  it is hard to tell, given their 
less specific semantics. They could contain data only useful for template 
management or could be preset metadata for the generated document.
Having to choose between the chance to leak template handling data into 
generated documents and the inability to preset metadata for documents, the 
second seems a greater issue for me (given I have no template tags like "form 
letter to shutdown stupid customers" ;) ).

So I agree, let's keep , but then also .

And then there is RDF metadata (§4.2.2), which for the non-content-specific 
statements has the same problem as  and . So 
better kept as is.

Custom metadata (§4.3.1) would also be treated like  and 
 for the same reasons, keeping as is.

So in summary, IMHO we should reset/drop these predefined metadata types:
  - reset to empty
- reset to empty
- reset to empty
  - reset to current author profile
- reset to current author profile
- reset to "now"
   - reset to "now"
   - reset to 1
 - reset to 0
 - reset to template iri

 - dump
 - dump

   - generated on the fly when saving only
 - generated on the fly when saving only

Does this small adaption to your plan make sense to you as well? :)

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

Re: Porting KLocale::formatMoney()/readMoney() to Qt5/KF5, best practise?

[Friedrich W. H. Kossebau]

Hi John,

Am Donnerstag, 7. Januar 2016, 05:18:42 schrieb Friedrich W. H. Kossebau:
> Am Mittwoch, 6. Januar 2016, 10:07:55 schrieb John Layt:
> > To save you some work, I do have an old draft implementation of the new
> > QNumberFormatter class at [2], it works on ICU and Mac but the api is a
> > bit
> > outdated now. If you're happy to wait a week or two I'll have a new
> > version
> > of the draft api and test ICU implementation completed which now includes
> > a
> > proper QCurrencyFormatter class which you could copy.
> 
> I personally only care about Linux & similar platforms, so ICU is a fine
> dependency for me :) Perhaps in a few months Android as well, seems ICU
> might be doable there as well. If Windows & OSX are supported by ICU as
> well, even better, if some want to have Plan & Sheets over there.
> So using ICU seems a good option, as it solves the currency database problem
> for what I understood.
> 
> Additional bonus, if the drafts of the QNumberFormatter classes can be used
> decoupled from the real QLocale, their API can already get some real-world
> testing in our apps. And once they are official part of Qt our code does not
> need bigger changes.
> 
> So looking forward to those QCurrencyFormatter classes you are working on.
> 1-2 weeks waiting is fine, in the meantime we could look closer at the
> exact needs we have (e.g. with parsing) and compile some relevant unit test
> data.

Did you manage to get some time to work on a new version of the draft API, or 
should we better start off with the old version for now?
If the latter, in which parts should we expect changes in a new version you 
would come up with?

Cheers
Friedrich

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

Re: Review Request 124630: Use SHARE_INSTALL_PREFIX instead of {INSTALL_PREFIX, }share

[Friedrich W. H. Kossebau]

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



Given the appdata file installation rules seem to use SHARE_INSTALL_PREFIX with 
success, seems to be an acceptable var :)

But I have no idea how the var works for windows, osx and other non-linuxoid 
platforms.
@boud, can you tell, given this is mainly about things installed by krita?

- Friedrich W. H. Kossebau


On Sept. 8, 2015, 7:05 p.m., Heiko Becker wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/124630/
> ---
> 
> (Updated Sept. 8, 2015, 7:05 p.m.)
> 
> 
> Review request for Calligra.
> 
> 
> Repository: calligra
> 
> 
> Description
> ---
> 
> Allowing to configure the install location, which is helpful with a
> multiarch layout, where prefix might be something like /usr/ but
> arch independent data should be installed to /usr/share/...
> 
> 
> Diffs
> -
> 
>   active/CMakeLists.txt 8fa0c6f 
>   krita/data/profiles/CMakeLists.txt a2a997b 
>   krita/data/profiles/elles-icc-profiles/CMakeLists.txt 8aa5a83 
> 
> Diff: https://git.reviewboard.kde.org/r/124630/diff/
> 
> 
> Testing
> ---
> 
> tquiChecked that the affected files get installed into the desired location.
> 
> 
> Thanks,
> 
> Heiko Becker
> 
>

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

Re: Review Request 122153: KD Chart

[Friedrich W. H. Kossebau]

> On Jan. 16, 2016, 12:31 a.m., Jarosław Staniek wrote:
> > @Friedrich What to do with this patch? Is it needed now or?

Guess so. Still missing proper sets of files/data to test it, so can only 
blindly commit it, but perhaps better than to ignore. Will do in the next days.


- Friedrich W. H.


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


On Dec. 3, 2015, 7:58 a.m., Stephen Leibowitz wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/122153/
> ---
> 
> (Updated Dec. 3, 2015, 7:58 a.m.)
> 
> 
> Review request for Calligra and Jarosław Staniek.
> 
> 
> Repository: calligra
> 
> 
> Description
> ---
> 
> These patches are also being made at kdab.com. Those who have a KDAB account 
> can see the discussion in “Suggested Changes to KD Chart” at 
> https://quality.kdab.com/browse/KDCH-1020
> 
> Calligra’s kdchart and kdgantt files are out-of-date, even with the patches 
> from the above paragraph. For example, “Compiler warnings” at
> http://mail.kde.org/pipermail/calligra-devel/2015-January/012762.html
> mentioned an error in KDChartPieDiagram.cpp. But the error is in a private 
> function that was removed from the latest version (2.5.1) of KD Chart. KDAB 
> will not patch previous versions. See “PieDiagram::drawPieSurface” at
> https://quality.kdab.com/browse/KDCH-1023
> 
> KDAB makes available source code for the latest and earlier versions of its 
> KD Chart and other GPL licensed software at http://docs.kdab.com/
> 
> 
> Diffs
> -
> 
>   3rdparty/kdchart/src/KDChartLayoutItems.cpp 095d2cd 
>   3rdparty/kdchart/src/KDChartStockDiagram_p.cpp d8636d7 
> 
> Diff: https://git.reviewboard.kde.org/r/122153/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Stephen Leibowitz
> 
>

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

Heads-up: kdesrc-build should now work better with kexi & krita repos, calligra repo changed position

[Friedrich W. H. Kossebau]

Hi,

if you are using kdesrc-build with kexi & krita or would like to use it, 
things should work better now due to some adaptions in the KDE repo metadata 
structure, i.e. no longer result in also the calligra repo being fetched and 
build in some cases or the krita/kexi sources being mixed into the calligra 
sources.

Those using kdesrc-build for the calligra repo, please take into account that 
the position of the calligra repo has now moved from "calligra/" to 
"calligra/calligra/", thus can also result in calligra source and build dir 
now being different on your storage system (perhaps unless you configured 
things explicitely, no expert).

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

[Maniphest] [Commented On] T665: Show default (empty) document on startup in document-based Calligra apps

[kossebau (Friedrich W. H. Kossebau)]

kossebau added a subscriber: kossebau.
kossebau added a comment.

Would it be a good idea to have UI/UX experts look at this as well?
Because I personally prefer the current UI if I just start the application 
binary itself, without any parameters. So if we agree on changing the default 
start UI, I would like to keep the current one as option at least, so I can 
stay happy.

Now, the "frequent" in "frequent scenario" is measured how? :)

Please rethink the 1 step in the scenario you gave, "Run a word processor, 
without delay": How do users start the word processor? By selecting some item 
in the UI of their workspace? If so, what do they actually mean and expect when 
the chose that item? What about having that item having a more specific meaning 
than "start app into whatever state"?

Looking at myself, I found I have certain set of different subtypes of richtext 
documents  I create (when talking about page-centric text documents), and most 
are not started from just plain empty sheets, but have a dedicated predefined 
structure and predefined content: generic formal letters, reports of several 
kinds, documentations.
So most of the time I use a richtextdocument editor for a new document it seems 
I do not need a blank sheet or another single type of template to start from. 
But instead first need to decide on the subtype of richtext document I am 
creating.
So the proposed new UX here would be a regression for me and people who also 
work like me (e.g. in most offices, the real world work places I mean here, 
template-based document creation surely is widespread for improved processes). 
Thus the proposal should be an optional start variant IMHO, at most.

While talking about it, I personally dream of a workspace which is not just an 
app starter, but integrated in my workflows. So for Plasma I have some draft 
plasmoid and runner which allows me to start creating & editing new documents 
by typing "new letter" or "new $other-doc-template" in krunner or selecting a 
template from a plasmoid drop-down, which then results in the matching app 
being shown with a new document created from the selected template, so I can 
type away. Hello document-centric UI :)
It is currently stuck in making this a general-purpose thing, so it can be used 
to create all kind of new documents with all kind of apps. Making things 
generic is not easy, especially in a wild world :)
It also needs a patch to Calligra, I should brush that over and hand it in for 
review finally in any case, so expect a review request soon.


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

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

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

[Maniphest] [Commented On] T665: Show default (empty) document on startup in document-based Calligra apps

[kossebau (Friedrich W. H. Kossebau)]

kossebau added a comment.

Unless I have seen and read the reports of the UI designers of MS, LO & Co. and 
their reasoning for why it is like this, it seem just blind copying of their 
UI, which does not make sense to me and my needs.
And otherwise I also would not need to work on Calligra, if LO UI would already 
be what I want.

Surely helping people to transition from learned & trainred usage patterns 
(first start app, then go to app menu to find template, select template) is 
something that can be useful, when trying to gain new users for the only sake 
of gaining new users. For them having this variant makes sense, they would 
possibly thing something is broken if there is no empty white sheet seen after 
app start.

The plasmoid and krunner I talk about is completely decoupled from Calligra 
code, so no need to fear dependencies.
The integration hook needed in Calligra for which I will send the patch is 
generic as well and useful for other cases. Don't judge too quickly without 
having seen the details :)


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

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

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

State of Proposal to improving KDE Software Repository Organization?

[Friedrich W. H. Kossebau]

Hi,

(calligra-devel, kexi-devel, kimageshop mailinglists only for heads-up,
 please remove from reply, discussion only on kde-core-devel should be fine)

4 months ago there was the thread "Proposal to improving KDE Software 
Repository Organization" on this mailinglist.
What happened to that plan? Are people preparing its execution?

And would that be a time where some bigger reorganization of the repos is 
possible?

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

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

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

More, not only Calligra & Krita related:
* "Extragear" is an awful grouping name for apps with individual
  release plans, a legacy term that no longer fits most of the apps
  in that substructure
* "KDE Applications" is a misleading grouping name for apps with a
  central release plan, as if those with individual release plans
  are not "KDE" applications (as in, not done in the KDE community)
* a single category per app as needed by the current tree structure layout
  of the repos, like "office", "graphics", "utils", is rather awkward,
  many apps do not match exactly one or would match multiple categories

So IMHO some update of the repository organisation would be good, to reflect 
how things are these days.
Renaming of "Extragear" and "KDE Applications" is surely something which needs 
care from promo/marketing/VDG people first to find if that makes sense at all 
and what a good solution would be.
(Being both maintainer of Okteta, which is in "KDE Applications", and meta-co-
maintainer of Calligra, which is not, but still done in the very same KDE 
community, that current naming seems so wrong to me).

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


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

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

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

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


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

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

[Friedrich W. H. Kossebau]

Am Samstag, 9. Januar 2016, 00:11:12 schrieb Jaroslaw Staniek:
> On 8 January 2016 at 23:29, Camilla Boemann  wrote:
> > Yeah regarding library names the renaming should rather be the other way
> > 
> > I don't want that ko everywhere
> 
> Same feeling here. Consistency is good but what I detest while using
> bash or IDE (Creator) completion and most if not all folders have
> names with the same prefix. The purpose of such a prefix is unclear then.
> Especially that these are all local libs. So yes, I'd go the other
> way, in particular kundo2 -> undo.

Using just basenames was also my initial idea. But disadvantages:
a) unbalanced naming of folders:
   libs with generic basename (main, text) vs. special named (flake, pigment).
b) results in another alias for the libname ones has to have in mind
   (local source files also have full name of class defined in it,
   not prefixless, so perhaps a pattern to pick up)
c) generic basenames (main, text) can be mixed up with generic resource folder
   names (pics, templates, styles, data), using the full lib name would be
   more clear

Like prefixes with class names never have annoyed me when using completion, 
also prefixes of folder names have not really done that, So not a real 
disadvantage on my list.

But if those two chars are a big bugger for you, I have no strong opinion 
here, fine to rename instead the other to prefixless if more people prefer 
that?

> > And regarding kundo2 - wasn't it supposed to be a clone of the qt5 so we
> > could get rid of our own version ?
> I am interested in this too since kexi.git forked kundo2 to reduce
> deps. I'd like to know if Qt 5 has all we need or if kundo stays, if
> we can have it in a separate repo. It's 1.5K SLOC. If so I am
> volunteering for making it a repo.

From what was said and what I saw it seems KUndo2 turned into quite some 
variant of its own, coupled with the special calligra_xgettext.

While I am not too keen about splitting more repos off, also due to extra work 
on releasing, if that helps to reduce code duplication it might be a good 
thing to do afterall.
But what namespace to use for the lib and its repo? KoUndo? KUndo?
Needs someone to analyze what is so special about this undo system, so it 
could be reflected in the name. Possibly KoUndo would be best for now, keeping 
it a private shared lib of Calligra, not yet maintained for public 
consumption, only in own repo for reuse needs between Calligra apps in split 
repos.

So not touching kundo2 subfolder for now.

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

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

[Friedrich W. H. Kossebau]

Hi,

to remove some complexity and add more patterns to the code structure, both 
for us current developers and even more for future developers trying to grasp 
the landscapes of Calligra code, I will be going to do two things next week 
(around Wednesday 13th) in master:

a) rename the kundo2 lib and all its classes to koundo/KoUndo

b) rename folders in libs/ consistently to match the lib name

   version -> koversion
   widgetutils -> widgetutils
   widgets -> kowidgets
   store -> kostore
   odf -> koodf
   textlayout -> kotextlayout
   kundo2 -> koundo
main -> komain
rdf -> kordf
vectorimage -> kovectorimage


Any issues with that?

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

Re: [Kde-finance-apps] Porting KLocale::formatMoney()/readMoney() to Qt5/KF5, best practise?

[Friedrich W. H. Kossebau]

Hi Klaas,

Am Mittwoch, 6. Januar 2016, 10:06:48 schrieb Klaas Freitag:
> On 06.01.2016 08:12, Friedrich W. H. Kossebau wrote:
> > QUESTIONS
> > 
> > How have developers of e.g. Skrooge & KMyMoney approached the issue of
> > conversion of currency values to/from strings?
> 
> The outcome of the KDE finance group so far is a lib called alkimia
> which was set up by the KMyMoney people, which is awesome. There you
> find a very powerful class AlkValue for financial numbers. And this one
> has a constructor that parses a QString. Maybe that is already enough
> for parsing?!

Ah, interesting, thanks for the pointer.
Had a quick look, but seems the parsing does not handle any currency 
symbols/terms, so sadly not up for the requirements we have in Sheets and Plan 
(e.g. things like "15 EUR" and "€ 15.10" should be correctly parsed in German 
locale, perhaps even "DM" variants additionally. And bitcoin & co. and 
regional non-state currencies would be nice to see supported as well in some 
way).

> About formatting, yes, QLocale is really limited, found that out during
> my KF5 porting actions of Kraft as well. Not only for currency, but also
> for dates.

Calligra Plan I managed to port completely to QLocale's dates API, as using 
just the gregorian calendar was no regression.
Well, modulo a few locale-dependent bugs the unit tests are showing on CI, it 
is anything but an easy port from KDateTime::Spec & Co. to Qt::TimeSpec... :)
 
> > Do you know about any activities to improve QLocale here?
> > 
> > Seems that Calligra apps Plan & Sheets are the only KDE apps using
> > KLocale::readMoney() ?
> > https://lxr.kde.org/ident?v=stable-qt4&_i=readMoney&_remember=1
> > 
> > But KLocale::formatMoney() might be used by KMyMoney, Skrooge, Kraft &
> > others (did not check though if not custom code):
> > https://lxr.kde.org/ident?v=stable-qt4&_i=formatMoney&_remember=1
> 
> Yes, and I do not konw how to solve that yet. What you described above
> might be the best option, but, as said, doesn't that apply to dates as
> well?

Only needed for dates if one deals with non-gregorian calendars, from what I 
understood. Not an expert though, only diving into this now.

> On a site note, KDE4 Kraft can deal with two different Locales, the one
> it was started with, and one for the specific document. That way you can
> write a lets say dutch invoice on a german desktop. That is nice, but I
> almost decided to drop that feature for KF5. Would be great if I could
> keep it.

One can create multiple QLocale instances and specify the locale for each, so 
I see nothing preventing such a thing :)

Calligra apps do they same, the UI locale does not need to be the same as for 
the content. Whole documents can have a locale assigned, and then even 
subparts different ones again.

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

Re: Porting KLocale::formatMoney()/readMoney() to Qt5/KF5, best practise?

[Friedrich W. H. Kossebau]

Hi Tomas,

Am Mittwoch, 6. Januar 2016, 12:09:05 schrieb Tomas Mecir:
> Hey Friedrich and others!
> 
> I've hit the very same issue in Sheets earlier that you did, and ended up
> postponing that part of the porting (though I do have a local branch with
> partial results).

Yes, I saw your commenting commits. IIRC Mek also already had a look at it in 
October or so, and postponed as well. Like I also did before, I had a proof-
of-concept libkolocale as fork/import of the used parts of KLocale, but that 
seemed wrong to do, so I dumped it and hoped someone else would have a better 
idea. But with everyone incl. you having postponed now, there was noone left 
to hope for :)

> Not really sure what the best solution would be - the
> problem with KLocale is that it seems to be out of sync with QLocale, so
> for me at least they both report different locales/languages. Weird, that.

You mean when requesting the system QLocale and system KLocale, right? That is 
possibly because both use different env vars and config settings to decide on 
the system's locale (LC_* vs. other stuff, incl. klocale config, latter no 
longer exposed in plasma5 systemsettings app and thus unreliable).
From what I tried this can be worked around by using the system QLocale id 
strings when creating the "system" KLocale:
QLocale locale;
klocale = new KLocale( QLocale::languageToString(locale.language()),
   QLocale::countryToString(locale.country()) );
But not studied in detail, so maybe something is still 

> Anyway. I've looked at QLocale's code, and adding precision to the
> formatting routines would be trivial technically - the routine called by
> formatMoney supports it, so it's just a matter of adding an optional
> argument to formatMoney - should even be BIC, as I understand it. Not sure
> how easy/hard it'd be to get the change into Qt.

That bit sounds promising for the long term solution, good, thanks for having 
peeked into the code :)

For BIC though this might need some overloads of the method, changing the 
signature of existing methods, even if only appending an argument to the list 
of arguments, does not work, or?
Given there are already 8 overloads for the different numeric types, well, 
that needs possibly more thinking still.

> The main problem with QLocale seems to be that it essentially is a black
> box - it has all the locale info we need, but we can't pull it out of it.
> So if functions to return the format string, precisions, etc for the
> current locale could be added, so that wrapper classes can be built, that'd
> probably be all we really need.

Yes, QLocale being readonly is a third issue in the list of blockers. And not 
only for the currency related methods. So our issues are:
- no currency string parsing method
- string formatting method toCurrencyString() does not allow
  to control precision
- no option to extend/overwrite/customize locale data

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

Re: Porting KLocale::formatMoney()/readMoney() to Qt5/KF5, best practise?

[Friedrich W. H. Kossebau]

Hi John,

Am Mittwoch, 6. Januar 2016, 10:07:55 schrieb John Layt:
> On 6 January 2016 at 07:12, Friedrich W. H. Kossebau <kosse...@kde.org>
> 
> wrote:
> > QUESTIONS
> > 
> > How have developers of e.g. Skrooge & KMyMoney approached the issue of
> > conversion of currency values to/from strings?
> > 
> > Do you know about any activities to improve QLocale here?
> 
> Hi Friedrich,
> 
> Apologies that the new QLocale features are taking so long,

No need for apologies, I am actually thankful for all the work you have done 
and brain cells you have invested here already, and I very much understand it 
is a highly complicated problem to model all these cultural artifacts with 
their random rules in a generic way and then also integrate with all the 
different platforms and their possible simplifications of the problem. Nothing 
I would ever pick myself to work on :)

> but it's
> proving very hard to find an acceptable cross-platform solution that isn't
> dumbed-down to the lowest feature set (i.e. Win32) and therefore useless to
> us. I've just started working on Plan D [1], each of the previous plans
> representing 3-6 months work before getting shot down. If this plan
> survives the inevitable savaging on the qt-dev mailing list then I'm hoping
> it will make the Qt 5.8 release, so perhaps a year before you could really
> use it.

Okay, glad to read that you are again going for it. Possibly a good chance for 
us currency-handling-app developers to play with the new API from the very 
beginning and give early feedback, so the final result will not leave us 
unsatisfied :)

> In the interim I'd suggest using ICU, seeing as the plan for Qt on Linux
> will be to wrap ICU anyway. It's not a pretty api, but it has all the
> features you want and you can rely on it being packaged everywhere. The
> main problem to watch out for is that there is no binary compatibility
> guarantee on the C++ api, so to be safe it's better to use the C api, but
> that unfortunately has fewer features available.
> 
> To save you some work, I do have an old draft implementation of the new
> QNumberFormatter class at [2], it works on ICU and Mac but the api is a bit
> outdated now. If you're happy to wait a week or two I'll have a new version
> of the draft api and test ICU implementation completed which now includes a
> proper QCurrencyFormatter class which you could copy.

I personally only care about Linux & similar platforms, so ICU is a fine 
dependency for me :) Perhaps in a few months Android as well, seems ICU might 
be doable there as well. If Windows & OSX are supported by ICU as well, even 
better, if some want to have Plan & Sheets over there.
So using ICU seems a good option, as it solves the currency database problem 
for what I understood.

Additional bonus, if the drafts of the QNumberFormatter classes can be used 
decoupled from the real QLocale, their API can already get some real-world 
testing in our apps. And once they are official part of Qt our code does not 
need bigger changes.

So looking forward to those QCurrencyFormatter classes you are working on. 1-2 
weeks waiting is fine, in the meantime we could look closer at the exact needs 
we have (e.g. with parsing) and compile some relevant unit test data.

> The other area still needing work is replacing KCurrencyCode for general
> data look-up tasks. I'd like to get a Qt version of it, but I'm doubtful it
> will make it in to Qt as Win32 doesn't provide the required data or api and
> I'd need to convince Qt that including all the data would be worth it. It's
> an area I'm still researching.

Never came across KCurrencyCode so far, not used in Plan & Sheets. So not 
commenting on that one. Though if such a class is redone in Qt, ideally it has 
setters or another way to create a custom object on the fly, not just a custom 
QFileInfo that could be passed to the constructor and thus the need to go via 
the filesystem, as with KCurrencyCode.
Use cases are non-ISO/non-state currencies (like digital currencies or 
local/community currencies).

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

Porting KLocale::formatMoney()/readMoney() to Qt5/KF5, best practise?

[Friedrich W. H. Kossebau]

Hi developers of finance apps & Calligra Sheets & Calligra Plan,

(please keep cross-posting to both ml for now)

I (not only with my Calligra developer hat on) would like to collect 
experiences and ideas for conversion of curreny values to and from 
strings when using Qt5/KF5, especially when porting from kdelibs4's 
KLocale.


PROBLEM

QLocale is rather limited (as of Qt 5.5):
- no currency string parsing method
- string formatting method toCurrencyString() does not allow
  to control precision

KLocale and its currency related methods seem the last blocker to get 
rid of kdelibs4support in Calligra in the Qt5/KF5 port. Plan uses them 
for handling the costs of resources, and Sheets for the currency 
formatted cells. And both limitations are a blocker.


APPROACHES

Long term ideally QLocale gets support in its API for that. So we 
developers of currency data handling software should organize and 
draft an API.

First and short term though, until some released & wide-spread Qt 
version has the improved QLocale, I am looking for a solution 
independent of QLocale.
Most obvious might be to duplicate all currency things from KLocale, 
which would also include duplicating the database with all currency 
formatting data. This is what I would plan to do if there is no better 
idea.
Especially the database duplication is painful though, I would like to 
avoid at least that if possible. 


QUESTIONS

How have developers of e.g. Skrooge & KMyMoney approached the issue of 
conversion of currency values to/from strings?

Do you know about any activities to improve QLocale here?

Seems that Calligra apps Plan & Sheets are the only KDE apps using 
KLocale::readMoney() ?
https://lxr.kde.org/ident?v=stable-qt4&_i=readMoney&_remember=1

But KLocale::formatMoney() might be used by KMyMoney, Skrooge, Kraft & 
others (did not check though if not custom code):
https://lxr.kde.org/ident?v=stable-qt4&_i=formatMoney&_remember=1

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

Re: Releasing 2.9.11

[Friedrich W. H. Kossebau]

Am Montag, 4. Januar 2016, 16:54:54 schrieb Jaroslaw Staniek:
> On 4 January 2016 at 12:15, Boudewijn Rempt  wrote:
> > On Mon, 4 Jan 2016, Jaroslaw Staniek wrote:
> >> Hi All,
> >> Are we ready to release 2.9.11?
> 
> How about tagging near 16 or 23 or 30 Jan?
> Do you expect any fixes by then?
> Kexi will have 2 fixes at least.
> 
> Next date that fits to my availability would be Feb 13th.

So if there is another 2.9.11, I will backport some fixes to 2.9 from master. 
One is for GrayF16ColorSpace, so Krita related. Though I do not know a real 
bug there, just a unit test catching wrong metadata about the format, cmp.
6a747ef0940c13a9ece91aa27a0a0c3560819ab3

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

Re: What's up with license cleanup?

[Friedrich W. H. Kossebau]

Hi Jarosław,

eek, good catch.

There is an additional file that needs fixing:
@Arjen:
libs/main/gemini/ViewModeSwitchEvent.h

Am Mittwoch, 23. Dezember 2015, 23:57:12 schrieb Jaroslaw Staniek:
> Hi,
> Please let me ask about the first thing because I use it (forked) in
> Kexi 3: libs/kundo2/kundo2commandextradata.*
> 
> @Dmitry: do you agree to relicense to LGPL?
> 
> Then BTW,
> @Dmitry:
> libs/pigment/KoCompositeColorTransformation.*
> 
> @Boud @Friedrich:
> *Debug*
> libs/version/CalligraVersionWrapper.*
> 
> Maybe it would be best if authors commit the 'fixes' themselves.

Fixed all the *Debug* files I added.
Left are *Debug* files in /libs, which had been added by Boud.

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

Re: kexi.git almost ready

[Friedrich W. H. Kossebau]

Am Sonntag, 20. Dezember 2015, 20:54:08 schrieb Jaroslaw Staniek:
> On 20 December 2015 at 14:53, Friedrich W. H. Kossebau <kosse...@kde.org> 
wrote:
> > Am Mittwoch, 16. Dezember 2015, 20:19:56 schrieb Jaroslaw Staniek:
> > Curious (no own opinion), any plans to also restore the branches? Or do
> > you
> > consider that legacy info which can be lost?
> 
> I don't see a reason. All the calligra/* branches stay in calligra.git.
> Calligra.git history won't be edited, just kexi/ dir and related will
> be removed using a commit.
> This is not different to how krita moved and everyone else can.

Ah, sure (guess I mixed up things with another unrelated project, pardon).

> > Is the patch needed to make it build somewhere available, so I can give
> > some build feedback on the state?
> 
> Pushed to master now:

Configures, builds, installs and starts here :)

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

Re: kexi.git almost ready

[Friedrich W. H. Kossebau]

Hi Jarosław,

Am Mittwoch, 16. Dezember 2015, 20:19:56 schrieb Jaroslaw Staniek:
> Dear All!
> I am almost ready with contents for kexi.git, split from calligra.git.
> Please be informed that the split is a planed reorganization of the
> structure of Calligra, not a split in the Calligra project.

Good job! Great to see work another milestone being reached.

> My local kexi.git is currently only 48MiB total thanks to a git
> cosmetic surgery like this [1].
> Fresh one, with only master branch.

Curious (no own opinion), any plans to also restore the branches? Or do you 
consider that legacy info which can be lost?

> Let's see if one week is enough to eventually have a working kde:kexi
> repo. The change can happen on the BIC Monday, Dec 21st. Or another
> Monday.

I would be okay with non-Monday here as well, after all this is moving a 
product at end of dep chain around, not breaking any APIs :) 

> Anyway, in one go kexi/ and other minor related subdirs will
> disappear from calligra.git and kde:kexi will become official.
> For building prior revisions of Kexi (<=2.9.x) we always use calligra.git.

Current scratch repo does not build due to buildsystem not yet adapted to now 
missing or renamed subdirs it seems.

Is the patch needed to make it build somewhere available, so I can give some 
build feedback on the state?

> Have fun!
> Comments?
> 
> [1] https://community.kde.org/Kexi/Porting_to_Qt%26KF_5#Git_surgery
> For those interested: 36 hours of computation in 3 stages. The SSD was
> quite hot :)

At least there was double use in heating, good timing with doing it in Winter 
(or some kind of) :)

Thanks for collecting the surgery info, that's spirit to copy from!

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

Re: KWPageManager::pages question

[Friedrich W. H. Kossebau]

Hi Thorsten,

Am Samstag, 5. Dezember 2015, 06:24:11 schrieb Thorsten Zachmann:
[snip]
> Is it ok to add that or is the comment wrong and I could use the sort inside
> cstester. I don't know if any other code depends on the pages being sorted

Looks like some code expects the pages ordered by page order, e.g.
KWDocument::updatePagesForStyle(const KWPageStyle )
KWOdfWriter::save(KoOdfWriteStore , KoEmbeddedDocumentSaver 
)
KWViewModeNormal::updatePageCache()

So fixing the implementation of KWPageManager::pages(...) to return the list 
sorted might be needed in general, yes.
Not sure though by what is should be sorted. pageNumber or pageId. The latter 
is what is used by KWPage compare operators currently.

Would need more investigation... but good catch for now at least.

And I would prefer a qSort over std::sort, at least for now for consistency in 
the code.
Given newer C++ standards etc. it might be time to reconsider the Calligra 
coding standards perhaps, e.g. Krita have a nice shot at it with 
https://community.kde.org/Krita/C%2B%2B11

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

New Year 2016 Words Sprint: January 23/24 2016, please register

[Friedrich W. H. Kossebau]

Hi,

more than enough people it needs to tango took part in the date poll for the 
Words sprint in Early 2016, good :)
(Someone tried to fake the votes, but that has been uncovered easily ;))

So given equality of the dates I threw the dice (with my favourite date on all 
sides), and our host also was fine with it, so this will be our sprint WE now:

January 23/24 2016 (the WE before FOSDEM)

Please now register and file your expected travel expenses you would like to 
get sponsored, so we can request support for you by the KDE e.V. for the 
sprint:

https://sprints.kde.org/sprint/296

Please do so until latest December 10th, that's when I will compile the 
support request to the e.V.

Accomodation will be done by our host, so you will not need to enter something 
for that. 

If you are interested to join the sprint, but have not participated in the 
date finding poll, do not hesitate to speak up now, it would be great to see 
more people!

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

First set of rename proposals for Calligra icons, all about tables (so mostly Sheets & Kexi) (was: Re: [Kexi-devel] Unused icons in kexi/pics/, which can be removed?)

[Friedrich W. H. Kossebau]

Hi everyone,

Andreas from the VDG has started to work on creating Breeze-styled icon 
variants for the icons used in Calligra, yay. Given many icons already created 
for Inkscape and LibreOffice there hopefully are lot of icons or at least 
parts that can be reused.

Which forces us to get more order in our icon usage. Thus all the commits with 
icon removals and the new script devtools/iconcheck/findunusedicons.py to see 
what is no longer needed. Good that we have that koIcon magic to get a good 
overview of used icons :)

Read more below...

Am Mittwoch, 11. November 2015, 13:41:25 schrieb Jaroslaw Staniek:
> OK, started something at:
> https://community.kde.org/Calligra/Icons/3.0

I collected all icons used for table manipulation & formatting and added them 
to that wiki page, with proposed new naming.
Given all/most of these icons are ending up in the Breeze iconset, we need to 
properly specify the semantics here.

Looking forward to comments on the proposed icon names, especially from Sheets 
maintainer(s) :)

Possibly we should also get input from non-Calligra developers or more icon 
creators once we are fine with the names?

Taking the table icons as test-drive, the other sets of icons will then 
follow.

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

Re: Calligrastage 2.9.8/Mac : dynamic_cast error message

[Friedrich W. H. Kossebau]

Am Dienstag, 27. Oktober 2015, 19:54:39 schrieb René J.V. Bertin:
> On Monday October 19 2015 00:05:35 Friedrich W. H. Kossebau wrote:
> > Please commit to calligra/2.9 and master. Can cherry-pick to master
> > myself, if you do not have that branch present.
> 
> Done (commit ff0f7766), and indeed please do the cherry pick to master
> yourself.

Will do.

> BTW, I noticed that `git describe` in the 2.9 branch returns
> "v2.9.7-151-g0b4834c", is that intentional?

Rather not. Thanks for the hint, 2.9.8 tag should appear soon.

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

Re: Review Request 125649: [OS X] install icon resources in app bundles where this doesn't happen automatically

[Friedrich W. H. Kossebau]

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

Ship it!


- Friedrich W. H. Kossebau


On Oct. 16, 2015, 4:28 p.m., René J.V. Bertin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125649/
> ---
> 
> (Updated Oct. 16, 2015, 4:28 p.m.)
> 
> 
> Review request for Calligra and KDE Software on Mac OS X.
> 
> 
> Repository: calligra
> 
> 
> Description
> ---
> 
> Builds on OS X currently generate icons for most Calligra applications, but 
> those are installed only for a happy few (Krita, Braindump and Kexi). The 
> other applications require an explicit install command of the generated 
> `.icns` file into the app bundle's Resources directory.
> 
> The attached patch takes care of that.
> 
> In addition, it corrects the picture source directories for calligragemini 
> and calligraauthor so those applications can have icons on other platforms 
> too, and replaces the `Q_WS_MACOS` token with the (IMHO) more appropriate 
> `APPLE` token.
> 
> 
> Diffs
> -
> 
>   cmake/modules/MacroCalligraAddBenchmark.cmake 9e7e282 
>   flow/part/CMakeLists.txt 58882f1 
>   gemini/CMakeLists.txt 85123fa 
>   karbon/CMakeLists.txt b574779 
>   plan/CMakeLists.txt ad39f57 
>   plan/workpackage/CMakeLists.txt f6eb20f 
>   sheets/CMakeLists.txt b0cc134 
>   stage/app/CMakeLists.txt 079bece 
>   words/app/CMakeLists.txt 1e73971 
>   words/part/CMakeLists.txt 9143176 
> 
> Diff: https://git.reviewboard.kde.org/r/125649/diff/
> 
> 
> Testing
> ---
> 
> On OS X 10.9 with KDELibs 4.14.12 and MacPorts 2.3.4 .
> 
> 
> Thanks,
> 
> René J.V. Bertin
> 
>

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

Re: Calligrastage 2.9.8/Mac : dynamic_cast error message

[Friedrich W. H. Kossebau]

Am Freitag, 16. Oktober 2015, 21:54:50 schrieb René J.V. Bertin:
> On Friday October 16 2015 01:17:50 Friedrich W. H. Kossebau wrote:
> > On my system with gcc version 5.1.1 it seems that does not result in a
> 
> Not, I've never seen this kind of error with gcc. Nor very often with clang,
> fortunately...
> > A workaround/fix might be to make KoSharedLoadingData a normally exported
> > class with implementation of constructor/destructor inside libflake?
> 
> It would seem so. I've had to do a similar fix with KDE PIM's ktimetracker;
> there, the issue was not a mysterious error message in the logs, but
> downright failure of a dynamic_cast.

By that error I assume it fails to do the dynamic_cast in Calligra as well, 
due to missing typeinfo? Just that the unsucessful cast might be error-
handled, so does not result in a crash.

Your patch not tested, but looks fine to me, especially this brings 
KoSharedLoadingData now on par with KoSharedSavingData :)

Please commit to calligra/2.9 and master. Can cherry-pick to master myself, if 
you do not have that branch present.

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

Re: Review Request 125649: [OS X] install icon resources in app bundles where this doesn't happen automatically

[Friedrich W. H. Kossebau]

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



words/part/CMakeLists.txt (line 191)
<https://git.reviewboard.kde.org/r/125649/#comment59763>

Actually this would not need an `if(APPLE)` as the macro only does things 
on platforms where it should.. And this might also be true for Windows.
Cmp. the other usages of `kde4_add_app_icon` which are unconditional.
No idea why it was disabled so far, perhaps left-over from when there were 
no icons yet.


- Friedrich W. H. Kossebau


On Oct. 15, 2015, 8:55 p.m., René J.V. Bertin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125649/
> ---
> 
> (Updated Oct. 15, 2015, 8:55 p.m.)
> 
> 
> Review request for Calligra and KDE Software on Mac OS X.
> 
> 
> Repository: calligra
> 
> 
> Description
> ---
> 
> Builds on OS X currently generate icons for most Calligra applications, but 
> those are installed only for a happy few (Krita, Braindump and Kexi). The 
> other applications require an explicit install command of the generated 
> `.icns` file into the app bundle's Resources directory.
> 
> The attached patch takes care of that.
> 
> In addition, it corrects the picture source directories for calligragemini 
> and calligraauthor so those applications can have icons on other platforms 
> too, and replaces the `Q_WS_MACOS` token with the (IMHO) more appropriate 
> `APPLE` token.
> 
> 
> Diffs
> -
> 
>   flow/part/CMakeLists.txt 58882f1 
>   gemini/CMakeLists.txt 85123fa 
>   karbon/CMakeLists.txt b574779 
>   plan/CMakeLists.txt ad39f57 
>   sheets/CMakeLists.txt b0cc134 
>   stage/app/CMakeLists.txt 079bece 
>   words/app/CMakeLists.txt 1e73971 
>   words/part/CMakeLists.txt 9143176 
> 
> Diff: https://git.reviewboard.kde.org/r/125649/diff/
> 
> 
> Testing
> ---
> 
> On OS X 10.9 with KDELibs 4.14.12 and MacPorts 2.3.4 .
> 
> 
> Thanks,
> 
> René J.V. Bertin
> 
>

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

Re: Calligrastage 2.9.8/Mac : dynamic_cast error message

[Friedrich W. H. Kossebau]

Am Donnerstag, 15. Oktober 2015, 22:43:14 schrieb René J.V. Bertin:
> Hi,
> 
> Running a quick test of CalligraStage 2.9.8 on OS X 10.9, I see this error
> in my system.log:
> 
> Oct 15 22:35:09 Portia.local calligrastage[80756]: dynamic_cast error 1:
> Both of the following type_info's should have public visibility.  At least
> one of them is hidden. 19KoSharedLoadingData, 23KoTextSharedLoadingData.
> 
> Demangling:
> 19KoSharedLoadingData -> "KoSharedLoadingData"
> 23KoTextSharedLoadingData -> "KoTextSharedLoadingData"
> 
> I've been seeing similar messages for some Akonadi classes, but have never
> been able to figure out neither how to fix the code, nor if anything
> actually doesn't work because of this.
> 
> Maybe someone here has an idea?

No idea, but curious now.

KoSharedLoadingData is a header only class in libflake, not tagged for symbol 
export, with virtual destructor.
KoTextSharedLoadingData is a normal class in libkotext with separate source 
file compiled into libkotext, with class tagged for symbol export.

Quick googling hints OSX/LLVM* see some issue here.
http://stackoverflow.com/questions/27878186/dynamic-cast-fails-depending-on-os-version

*Message seems to be from 
https://llvm.org/svn/llvm-project/libcxxabi/trunk/src/private_typeinfo.cpp

As you said you saw this with Stage, while there are also dynamic_casts 
between both in libkotext, there is also one in 
KPrPlaceholderTextStrategy::loadOdf().

On my system with gcc version 5.1.1 it seems that does not result in a 
problem, e.g. libcalligrastageprivate has the typeinfo for KoSharedLoadingData 
created locally (and gets the one for KoTextSharedLoadingData from the linked 
libkotext):

koder@klux:~> nm -C 
System/opt/calligra3/lib64/libcalligrastageprivate.so.15.0.0 | grep 
SharedLoadingData
 U KoTextSharedLoadingData::paragraphStyle(QString const&, 
bool) const
00326298 d typeinfo for KoSharedLoadingData
 U typeinfo for KoTextSharedLoadingData
000e8e10 r typeinfo name for KoSharedLoadingData

Possibly LLVM treats things differently here, e.g. by not creating the 
typeinfo locally for the header-only class. No idea if that is right or wrong.

A workaround/fix might be to make KoSharedLoadingData a normally exported 
class with implementation of constructor/destructor inside libflake?

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

Re: Review Request 125649: [OS X] install icon resources in app bundles where this doesn't happen automatically

[Friedrich W. H. Kossebau]

> On Oct. 15, 2015, 10:30 p.m., Friedrich W. H. Kossebau wrote:
> > `Q_WS_MAC` is not a cmake var, or? Seems someone accidentally used the c++ 
> > macro/define here, and noone ever noticed? :)
> > 
> > In Qt5/KF5/ECM worlds ecm_add_app_icon does the respective installation, 
> > right? So only the `Q_WS_MAC` fix will need porting to the master branch?
> 
> René J.V. Bertin wrote:
> No, Q_WS_MAC is not something that cmake provides by default, so I guess 
> you're right. 
> 
> Do calligragemini and calligraauthor get icons on Linux? For the former 
> it seems that that should only be the case if the icon .png file(s) is/are 
> already installed, but if that's the intended behaviour shouldn't my patch be 
> Mac-specific? Calligraauthor's `kde4_add_app_icon` call is commented out, was 
> that intended or should that patch *not* be Mac-specific?
> 
> I have no idea at the moment what has changed in KF5/ECM. If ECM provides 
> a function `ecm_add_app_icon` then it would make sense that it does all the 
> required work.
> Note however that the sole use of `kde4_add_app_icon` isn't enough. It 
> generates the icon file, and it adds the corresponding entry in the 
> application's `Info.plist`, but that's not always enough. I haven't yet 
> figured out why certain applications always got an icon, and why others 
> require explicit installation of the icon resource.

Yes, calligragemini has icons on linux, they are installed by the 
CMakeLists.txt in gemini/pics. And Author has icons as well.
For both it was "just" those kde4_add_app_icon that were broken or not active 
(they do nothing on linux IIRC, that's why not noone noticed so far. And 
Windows builds are only done for CalligraGemini, Krita & Kexi).

For `ecm_add_app_icon` see here for the sources, ll. 223-224:
https://quickgit.kde.org/?p=extra-cmake-modules.git=blob=modules%2FECMAddAppIcon.cmake
```
# Install the icon into the Resources dir in the bundle
set_source_files_properties(${_outfilename}.icns PROPERTIES 
MACOSX_PACKAGE_LOCATION Resources)
```
No idea what effect that has and if that is better than what is there in 
`kde4_add_app_icon`, but you might :)


- Friedrich W. H.


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


On Oct. 15, 2015, 8:55 p.m., René J.V. Bertin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125649/
> ---
> 
> (Updated Oct. 15, 2015, 8:55 p.m.)
> 
> 
> Review request for Calligra and KDE Software on Mac OS X.
> 
> 
> Repository: calligra
> 
> 
> Description
> ---
> 
> Builds on OS X currently generate icons for most Calligra applications, but 
> those are installed only for a happy few (Krita, Braindump and Kexi). The 
> other applications require an explicit install command of the generated 
> `.icns` file into the app bundle's Resources directory.
> 
> The attached patch takes care of that.
> 
> In addition, it corrects the picture source directories for calligragemini 
> and calligraauthor so those applications can have icons on other platforms 
> too, and replaces the `Q_WS_MACOS` token with the (IMHO) more appropriate 
> `APPLE` token.
> 
> 
> Diffs
> -
> 
>   flow/part/CMakeLists.txt 58882f1 
>   gemini/CMakeLists.txt 85123fa 
>   karbon/CMakeLists.txt b574779 
>   plan/CMakeLists.txt ad39f57 
>   sheets/CMakeLists.txt b0cc134 
>   stage/app/CMakeLists.txt 079bece 
>   words/app/CMakeLists.txt 1e73971 
>   words/part/CMakeLists.txt 9143176 
> 
> Diff: https://git.reviewboard.kde.org/r/125649/diff/
> 
> 
> Testing
> ---
> 
> On OS X 10.9 with KDELibs 4.14.12 and MacPorts 2.3.4 .
> 
> 
> Thanks,
> 
> René J.V. Bertin
> 
>

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

Re: Review Request 125649: [OS X] install icon resources in app bundles where this doesn't happen automatically

[Friedrich W. H. Kossebau]

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

Ship it!


`Q_WS_MAC` is not a cmake var, or? Seems someone accidentally used the c++ 
macro/define here, and noone ever noticed? :)

In Qt5/KF5/ECM worlds ecm_add_app_icon does the respective installation, right? 
So only the `Q_WS_MAC` fix will need porting to the master branch?

- Friedrich W. H. Kossebau


On Oct. 15, 2015, 8:55 p.m., René J.V. Bertin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125649/
> ---
> 
> (Updated Oct. 15, 2015, 8:55 p.m.)
> 
> 
> Review request for Calligra and KDE Software on Mac OS X.
> 
> 
> Repository: calligra
> 
> 
> Description
> ---
> 
> Builds on OS X currently generate icons for most Calligra applications, but 
> those are installed only for a happy few (Krita, Braindump and Kexi). The 
> other applications require an explicit install command of the generated 
> `.icns` file into the app bundle's Resources directory.
> 
> The attached patch takes care of that.
> 
> In addition, it corrects the picture source directories for calligragemini 
> and calligraauthor so those applications can have icons on other platforms 
> too, and replaces the `Q_WS_MACOS` token with the (IMHO) more appropriate 
> `APPLE` token.
> 
> 
> Diffs
> -
> 
>   flow/part/CMakeLists.txt 58882f1 
>   gemini/CMakeLists.txt 85123fa 
>   karbon/CMakeLists.txt b574779 
>   plan/CMakeLists.txt ad39f57 
>   sheets/CMakeLists.txt b0cc134 
>   stage/app/CMakeLists.txt 079bece 
>   words/app/CMakeLists.txt 1e73971 
>   words/part/CMakeLists.txt 9143176 
> 
> Diff: https://git.reviewboard.kde.org/r/125649/diff/
> 
> 
> Testing
> ---
> 
> On OS X 10.9 with KDELibs 4.14.12 and MacPorts 2.3.4 .
> 
> 
> Thanks,
> 
> René J.V. Bertin
> 
>

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

[Differential] [Commented On] D360: KoFileDialog rather belongs to kowidgetutils than kowidgetsThis way apps can use the class without larger deps of kowidgets

[kossebau (Friedrich W. H. Kossebau)]

kossebau added a comment.

Not sure I would have moved the main.cpp into the other file, but there is no 
policy in Calligra about such utils apps, so if you prefer it like that, keep 
it as you did now. (I prefer having entry points in a separate file, even do 
main.cpp files for plugins, but I know that this is my personal style only. And 
as long the util app is sharing the same folder with other stuff, the main.cpp 
could be conflicting, so...).

So with the request to have to the fix to KoPropertiesTest in a separate 
commit, this patch here seems fine to me to go in. Still untested and only 
partially code-reviewed, as before, with same reasoning :)


INLINE COMMENTS
  libs/widgetutils/tests/CMakeLists.txt:8 This is fixed in a separate commit, 
right? If not, please make this a separate commit, for improved clear scopes of 
the atomic changes by commits.

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

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

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

[Differential] [Accepted] D360: KoFileDialog rather belongs to kowidgetutils than kowidgetsThis way apps can use the class without larger deps of kowidgets

[kossebau (Friedrich W. H. Kossebau)]

kossebau accepted this revision.
kossebau added a comment.
This revision is now accepted and ready to land.

Agree on removal of i18n, not really needed IMHO, let's have translators only 
spend time on enduser facing strings :)
While moving filedialogtester, could you please move it into the subdir tests/, 
so the normal dir only contains product code?
As you just moved the KoFileDialog class files (and updated used export macro), 
I have not really looked into the code, only the CMakeLists.txt changes. Also 
not tested, assuming things work as before as kowidgetutils is a public dep of 
kowidgets :)

With filedialogtester moved down to subdir tests/, seems fine to me and good to 
ship.


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

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

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

Re: "Done" porting...

[Friedrich W. H. Kossebau]

Am Donnerstag, 17. September 2015, 17:54:41 schrieb Jaroslaw Staniek:
> On 17 September 2015 at 16:39, Boudewijn Rempt  wrote:
> > Hi,
> > 
> > I'm pretty square-eyed by now, but I've ported the big bulk of the
> > libraries, some of the plugins and krita to no longer depend on
> > kdelibs4support.

Thanks for all the work, Boud!

> - @friedrich modulariazation: move find_package and lib dependency
> down to place where they are really needed

Mh, can you give a short description what you are planning there? Sounds like 
it could run against the principles of the current product system.

Actually I planned to do change (well, improve) the system here to also note 
the external deps for each product, so that after the initial phase calculate-
all-internal-deps-wanted the external deps would be calculated from that, and 
then the phase check-external-deps would be done only for what is needed (and 
then would be followed by the calculate-products-that-can-be-built.)
So, what are you planning here?

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

[Differential] [Updated] D360: KoFileDialog rather belongs to kowidgetutils than kowidgetsThis way apps can use the class without larger deps of kowidgets

[kossebau (Friedrich W. H. Kossebau)]

kossebau added a comment.

Issue in any case: this patch misses to also move the test app, 
filedialogtester.

Then I wonder if we could first come up with a definition what the purpose of 
kowidgets and kowidgetutils is. And if perhaps we should split them up some 
more or reshuffle together with other libs.
Especially would I like to see a split between QWidget things and non-gui 
classes, so QtQuick solutions do not get trojan libs which come with QWidget 
stuff.

Other than that I would agree that KoFileDialog might be rather belong into 
kowidgetutils, due to not having a dep on other stuff in the Calligra libs, if 
that is the current difference between kowidgets and kowidgetutils.


REPOSITORY
  rCALLIGRA Calligra

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

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

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

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

[kossebau (Friedrich W. H. Kossebau)]

kossebau requested changes to this revision.
kossebau added a comment.
This revision now requires changes to proceed.

Hm, moving checking for required packages into the subdirs and thus after 
calculating which products can be built or, if internal dep, should be built 
breaks the concept of the current productset system. So for now I would like to 
veto this patch.

So let's see what you actually want to fix here. I see at least 2 problems 
where I agree that they should be handled:

- external deps is checked for even if none of the products that are built need 
it
- when explicitely requesting build of a certain app (e.g. by PRODUCTSET=kexi) 
a missing required external dep does not make the configuration fail, other 
than expected

Are these also your concerns? Any other? If so, I have something sketched in 
the back of my mind I could brush up and then propose as alternative and 
integrated solution.


REPOSITORY
  rCALLIGRA Calligra

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

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

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

[Differential] [Request, 173 lines] D364: Move KoFindToolbar to Words, it's only user

[kossebau (Friedrich W. H. Kossebau)]

kossebau created this revision.
kossebau added reviewers: boemann, deniskuplyakov.
kossebau added a subscriber: Calligra-Devel-list.

REVISION SUMMARY
  Nothing shares this widget. Can be still moved to a shared lib again,
  once another app wants to use exaxtly the same widget.

REPOSITORY
  rCALLIGRA Calligra

BRANCH
  moveKoFindToolbar

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

AFFECTED FILES
  libs/main/CMakeLists.txt
  libs/main/KoFindToolbar.cpp
  libs/main/KoFindToolbar.h
  libs/main/KoFindToolbar_p.h
  words/part/CMakeLists.txt
  words/part/KWView.cpp
  words/part/widgets/KoFindToolbar.cpp
  words/part/widgets/KoFindToolbar.h
  words/part/widgets/KoFindToolbar_p.h

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

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

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

[Friedrich W. H. Kossebau]

Am Montag, 14. September 2015, 10:25:06 schrieb Boudewijn Rempt:
> On Mon, 14 Sep 2015, Adam Pigg wrote:
> > Na, kreport and kproperty beat it :D
> 
> They're not in calligra anymore :P

Yay for first full porting :) Good work, Boud!

(well, for records koplugin and kowidgetutils were fully ported away from 
kdelibs4support already before, but that needed no serious porting, so out of 
competition as well, I agree ;) )

Cheers
Friedrich, defacto offline till end of week
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: [calligra] /: Unport words and stage

[Friedrich W. H. Kossebau]

Am Freitag, 11. September 2015, 08:26:41 schrieb Boudewijn Rempt:
> Git commit 43a5919cbadcd4b59f4a75448323ef70571209c0 by Boudewijn Rempt.
> Committed on 11/09/2015 at 08:25.
> Pushed by rempt into branch 'master'.
> 
> Unport words and stage

Ported again :)

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

Re: [calligra] /: Port libs from KUrl to QUrl

[Friedrich W. H. Kossebau]

Am Donnerstag, 10. September 2015, 09:41:44 schrieb Boudewijn Rempt:
> Git commit defb836a63608335988184e5ed0590588728f8be by Boudewijn Rempt.
> Committed on 10/09/2015 at 09:41.
> Pushed by rempt into branch 'master'.
> 
> Port libs from KUrl to QUrl

yay :) Keep it going!

> This means that several applications are back to unported status:
> 
> Sheets engine
> QtQuick components
> Karbon

Going to check the following tonight, if nobody beats me on it:
> Calligra Converter
> Thumbnailer
> Okular plugins

Cheers
Friedrich
who just at Randa assigned himself the task to write tutorials for how to 
setup a devel environment for qt5(/kf5) for android with hello world c++/qml 
examples for after lunch :) 
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

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

[Friedrich W. H. Kossebau]

Hi,

when master became Qt5/KF5-based, I updated the kde-build-metadata to point to 
2.9 for both the stable and the latest branch for qt4-based stuff (metadata 
expects those 2 variants). Because this was the pattern with all other 
projects that no longer do feature development against qt4/kdelibs4.

Which also results in 2 builds now done for 2.9:
calligra calligra-2.9 stable-qt4, building against all stable variants of kde4 
stuff
calligra calligra-2.9 latest-qt4, building against all latest variants of kde4 
stuff

Which is a problem, because it keeps CI busy now for double the time on new 
commits to 2.9 (and also means duplicated notifications). Which in turn also 
means delayed feedback on commits to master branch, as Calligra got it's own 
separate build slave on CI, to avoid denial-of-service for the other projects.

I would propose to only keep the first build and drop the second, as it should 
not really make that much difference, given that most other qt4-based projects 
Calligra uses are not moving a lot anymore as well.

This is possible, because given no other project currently relies on 
Calligra('s libraries), there is no need to also provide a latest-qt4 version 
build on CI whose products then could be used for other latest-qt4 builds.

I would request that change upcoming Tuesday, Sep. 15th, unless somebody 
objects meanwhile and can tell an important reason to keep building both 
against stable-qt4 and latest-qt4 versions of other KDE project. Is there any 
external dependency from KDE which still changes a lot in the qt4 version?

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

Re: Coding standard for qdebug in libs

[Friedrich W. H. Kossebau]

Am Samstag, 5. September 2015, 12:55:28 schrieb Jaroslaw Staniek:
> With increasing modularity it's quite important
> for our debugging needs to have logging categories.

Agreed.

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

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

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

When I looked into debug porting for libs/ last week (still need to complete 
end of next week, so anyone wants to take over meanwhile? no code yet written 
here), I wondered if installed headers better should not include any debug-
only headers at all.
But with publix/exported templates which need/better have debug statements 
that might be unavoidable. Still not really sure though, it somehow seems 
dirty to me :)

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

Re: Further 2.9.x release plan

[Friedrich W. H. Kossebau]

Am Montag, 7. September 2015, 18:55:56 schrieb Jaroslaw Staniek:
> Hi,
> How many releases would you see for the 2.9 series?
> Is it possible to deduce already?
> 
> And is October 7 for 2.9.8 a good fit for you?

For the things I oversee (Okular plugins, Plan, thumbnailer) I currently do 
not plan more work (unless grave bugs are reported) in 2.9, but instead 
completely focus on 3.0.

So any number of 2.9 releases you need for the other components of Calligra is 
fine with me. And Oct. 7th works for me as well, no further work scheduled 
right now for 2.9 for me.

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

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

[Friedrich W. H. Kossebau]

Am Montag, 31. August 2015, 12:19:32 schrieb Cyrille Berger:
> On Sunday 30 August 2015 17:30:22 Sven Langkamp wrote:
> > We started out offering endless choise for the users and gave them
> > everything. But at some point it became clear that in many cases it was
> > just overkill. We spend a huge amout of time to fix things like bugs that
> > showed up in Krita when a spreadsheet was insert. That's a feature that no
> > user ever needed. So over time we dialed back the available shapes until
> > we
> > have only simple geometry, paths and text.
> > The same happend with tools which felt often out of place and Krita, so we
> > made tools that wrapped around flake tools. To this day users are confused
> > by tools that don't behave like the rest of Krita.
> 
> To be honest, it was/is a problem for office application. The KOffice2 idea
> of one UI to fit them all, was a bad idea. We saw that in sheets that had a
> weird tool for editing cells, then words started to get a completely
> different UI. And I got unhappy with braindump because the tools didn't fit
> so well.
> 
> So in this end, a split between model and view in flake would be a good idea
> for office applications and krita. and would be needed for developing
> mobile UI. And would make it possible for me to provide the correct UI for
> braindump.

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

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

Re: Big reformat of sources before unfreeze of master (was: Re: Schedule to switch back to master for feature development)

[Friedrich W. H. Kossebau]

Am Freitag, 28. August 2015, 19:18:18 schrieb Friedrich W. H. Kossebau:
> Am Freitag, 28. August 2015, 15:48:39 schrieb Boudewijn Rempt:
> > On Thu, 27 Aug 2015, Friedrich W. H. Kossebau wrote:
> > > * after that:
> > >  2.9 only bugfixes, no more features
> > >  master unfrozen, so open for features and porting from kdelibs4support
> > 
> > I also would like to cleanup the coding style, still...

Does any of the non-Krita maintainers want to do a cleanup of the coding 
style?

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

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

Cheers
Friedrich

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

Re: Handling of splitted Calligra repos and API changes

[Friedrich W. H. Kossebau]

Am Montag, 31. August 2015, 02:29:29 schrieb Jaroslaw Staniek:
> On 31 August 2015 at 01:46, Friedrich W. H. Kossebau <kosse...@kde.org> 
wrote:
> > Am Sonntag, 30. August 2015, 23:21:59 schrieb Jaroslaw Staniek:
> >> On 28 August 2015 at 19:10, Friedrich W. H. Kossebau <kosse...@kde.org>
> > 
> > wrote:
> >> > Hi,
> >> > 
> >> > with KDb, KProperty and KReport, a few libs/frameworks have been
> >> > already
> >> > split off during the port of Calligra to Qt5/KF5.
> >> > 
> >> > And they pose a challenge that needs to be solved quickly:
> >> > traditionally we have had no ABI guarantuee in Calligra even in patch
> >> > releases and of course also not during development. Because sourcecode
> >> > of
> >> > all libs and libconsumers were in a shared repo, and any API changes
> >> > were
> >> > done in atomic commits both to the libs and libconsumers (because by
> >> > policy we require any commits to the repo to not break it's build).
> >> > 
> >> > With libs and libconsumers being split in separate repos the atomicity
> >> > no
> >> > longer is given.
> >> > 
> >> > Which results in problems:
> >> > * people might pull from repos missing part of API change commits
> >> > * current KDE CI triggered by commits will build repos without caring
> >> > for
> >> > 
> >> >   dependencies between commits, using products from previous lib builds
> >> >   with
> >> >   old API for the build of libconsumer with commit using newer API
> >> > 
> >> > * ?
> >> > 
> >> > No idea how to solve the KDE CI one perfectly. But for the problem of
> >> > pulling consistent states, what about the following rules with the
> >> > split
> >> > off lib repos:
> >> > * no ABI breakage in patch releases for released branches
> >> > * weekday of API breakage: a set day per week development branches can
> >> > get
> >> > 
> >> >   commits which involve API changes in the libs in separate repos
> >> >   still related commits should be pushed together in an as small
> >> >   timewindow
> >> >   as possible
> >> > 
> >> > No ABI breakage in patch releases might be a no-brainer, given that
> >> > targetted 3rd-party consumers would rely on that as well.
> >> > The second one would pick up something which seemed to work well enough
> >> > in
> >> > times where close kdelibs and kdeapps development was common, and where
> >> > people also did separate svn "pulls" for libs and apps. Pushing related
> >> > commits to all repos in small timewindows might not completely match
> >> > atomic commits as possible with subversion. But in the end we all pull
> >> > in
> >> > time ("fetch latest commits now") and not by branch state ("fetch
> >> > commits
> >> > until xyz id"), so in practice this might work as well still.
> >> > 
> >> > What do you think? Would this work for you as well?
> >> > 
> >> > IMHO we need to have an agreed solution here before Kexi-frameworks is
> >> > merged back, because it will force us into this situation (where Plan
> >> > currently does not depend on KReport, my respective patch waiting since
> >> > many weeks for someone to push this question for handling of the
> >> > API-break challenge and to find an agreed resolution ;) ).
> >> > 
> >> > ((While in the discussion this is only about those 3 libs for now... My
> >> > personal desire is to make the Calligra document libs more accessible
> >> > to
> >> > other apps, which partially do document creating/processing. For that I
> >> > would see some advantage to split off more libs into own repos as well.
> >> > In the long run I would like to see Calligra move out of it's own
> >> > corner
> >> > and integrate more with the normal KDE application scene.
> >> > But more on that once we have finally passed the port hurdle, are back
> >> > in
> >> > normal feature development and can start talking post-3.0 (where 3.0 is
> >> > now
> >> > the first real release) :) ))
> > 
> >  > to
> > depart from usual handling>
> > 
> >> Next, how to check versions. A single

Re: 2.9.7

[Friedrich W. H. Kossebau]

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

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

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

Re: Handling of splitted Calligra repos and API changes

[Friedrich W. H. Kossebau]

Am Montag, 31. August 2015, 12:46:30 schrieb Jaroslaw Staniek:
> Partial response, no time for more now.
> 
> On 31 August 2015 at 12:15, Friedrich W. H. Kossebau <kosse...@kde.org>
> 
> wrote:
> > Am Montag, 31. August 2015, 02:29:29 schrieb Jaroslaw Staniek:
> > > >> For people building largely by hand, I'd introduce a support for
> > > >> specific case: a
> > > >> find_package wrapper that checks if the dependency has an exact git
> > > >> revision. That's like an assertion that tells you that your deps are
> > > >> too old (or too new, or even from incompatible branch - use git to
> > > >> find out). (I already offer the git revision information for kdb.git,
> > > >> etc. and believe providing it even in --help for apps is a good thing
> > > >> in modern times).
> > > > 
> > > > Tagging a certain devel state with the main development branch sounds
> > 
> > like
> > 
> > > > an interesting solution. Just, how would that be integrated in
> > > > people's
> > > > workflow? How does the git revision info get from e.g. Calligra's
> > > > CMakeLists.txt into the commands that fetch stuff from those separate
> > > > repos, and then also make sure the certain version is checked out,
> > 
> > build
> > 
> > > > and installed?
> > > 
> > > When we build we have set up a list of dirs: builddir, source dir and
> > > prefix dir.
> > > So while building, the sourcedir is known and build-dependency
> > > checking can look into the sourcedir to know the required versions.
> > > (Actually similar tool could update the cmake file for me when I as a
> > > developer want to bump up the dependent versions; that's not needed
> > > for every commit though)
> > 
> > Under the line, that sounds like a complicated system to me, with the need
> > for
> > utils which are yet to be written.
> > More, it will only work for those who adapt to that system. What about
> > 3rd-
> > party apps that want to develop again master branch of kdb? But use qmake?
> > Or
> > some other custom build system?
> > 
> > What about using KProperty and KReport as testing ground for now for the
> > approach you are proposing?
> 
> ​+1 or look below
> ​
> 
> > > > Also having to adapt the revision info any time one works on the
> > 
> > external
> > 
> > > > repos (with changing commit ids) smells like a lot of painful work,
> > > > not
> > > > only because due to waiting for cmake to finish reconfiguring :/
> > > > 
> > > > So, interesting idea, but needs proof it stays the daily workflow for
> > 
> > me
> > 
> > > > :)
> > > 
> > > The idea addresses a case that may or may not be a corner case,
> > > depends on developer.
> > 
> > For the start, for now, in current Calligra master I would like to propose
> > to
> > apply the BIC-day approach.
> 
> I am all for known workflows that cause no stress or wtf moments.
> I understand developers want to be sure they have the "current" code.
> 
> ​
> ​The BIC days can work, the change from the above proposal would be then:
> use a year+week number or so instead of git revision or cross-repo tag
> name. The year+week number is a cross-repo too of course. It can be checked
> at cmake level that during development branch we have too old deps such as
> kreport/kdb/etc.

Sounds like that could work without getting in the way, good idea. Even with 
added value to have the buildsystem properly warn. So such tags would be kind 
of internal development releases of the repos :)
Would be some added maintenance though, who will care to add the tags every 
week? The maintainers of the repos? The person doing the BIC commits?

> It's also all about one more thing. Even given that API/ABI is carefully
> maintained, behaviour can change or fixes can appear in dependencies such
> as kreport.git. Sometimes a bug in Kexi gets in fact fixed by kreport.git
> commits only.

Sure. Just, the BIC-day thing is about being able to build the whole galaxy in 
a repo, and only the building. Because that is the minimum requirement to do 
development :) Which is also reflected in the policy to try to never have 
build-breaking commits.
Bugs in apps being only fixed in the libs is also something we have had with 
kdelibs + kdeapps, still the BIC-day helped in general. A small price to pay 
here when having to wait half-a-week in average until that fix can be expected 
with your fellow devs, but w

Re: Review Request 123554: Readd Braindump to build on frameworks

[Friedrich W. H. Kossebau]

> On Aug. 30, 2015, 9:49 p.m., Friedrich W. H. Kossebau wrote:
> > Hi Somsubhra.
> > Thanks for your patch. Sadly the old maintainer has no more interest in 
> > this application. And noone else is working on it. This is why noone took a 
> > look at your work all the time. (And I missed the email notice, with my 
> > general interest in Calligra).
> > 
> > As you might have read, we are looking for a new maintainer for Braindump. 
> > See e.g. 
> > https://frinring.wordpress.com/2015/04/17/like-braindump-adopt-it-for-the-qt5kf5-port/
> > 
> > So given you have shown interest in Braindump, by working on creating this 
> > patch, might you be interest to simply take over maintainership of 
> > Braindump?
> > Please reply quickly, as we are planning to remove Braindump completely in 
> > a few days otherwise (only discovered your review request now).
> > Best contact by email on the developer mailinglist of Calligra, see 
> > https://community.kde.org/Calligra/Contact for best ways to get in contact.
> > 
> > Cheers
> > Friedrich
> 
> Somsubhra Bairi wrote:
> Hi,
> Yes, I surely would like to take up the maintainership of Braindump.
> 
> Cheers,
> Somsubhra

Cool :) So with this information I will leave out Braindump from the upcoming 
removal day and keep it in master, for your to work on.

Now, maintainership means being active :) So please get in contact with 
Cyrille, the old maintainer, to agree on passing over and then please say 
"Hello!" to your fellow Calligra developers & maintainers on the calligra-devel 
mailinglist. Ideally also telling what kind of plans you have with Braindump in 
the future, e.g. which features you plan to add or on what platforms you want 
to make it run.

That mailinglist is also the place where we coordinate releases and all other 
stuff around Calligra development, so being subscribed there is needed (but you 
might know that already :) ).

Looking forward to your introduction email there soon :)


- Friedrich W. H.


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


On April 29, 2015, 7:13 a.m., Somsubhra Bairi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/123554/
> ---
> 
> (Updated April 29, 2015, 7:13 a.m.)
> 
> 
> Review request for Calligra.
> 
> 
> Repository: calligra
> 
> 
> Description
> ---
> 
> Readd Braindump to build on frameworks
> 
> 
> Diffs
> -
> 
>   CalligraProducts.cmake 5b15bbe 
>   braindump/braindumpcore/CMakeLists.txt 24f3854 
>   braindump/braindumpcore/State.h 5970280 
>   braindump/braindumpcore/StatesRegistry.cpp a611bf4 
>   braindump/plugins/stateshape/CMakeLists.txt 38c9c5e 
>   braindump/plugins/stateshape/CategorizedItemDelegate.cpp 4e7a802 
>   braindump/plugins/webshape/CMakeLists.txt 07b25ba 
>   braindump/plugins/webshape/WebShapePlugin.cpp 0e8c42e 
>   braindump/src/AboutData.h d3dadc4 
>   braindump/src/CMakeLists.txt 0aae217 
>   braindump/src/MainWindow.h d035630 
>   braindump/src/MainWindow.cpp b31df13 
>   braindump/src/SectionsIO.cpp b2d07b7 
>   braindump/src/StatusBarItem.h 9afba37 
>   braindump/src/View.h c3f2cf7 
>   braindump/src/View.cpp 58a05da 
>   braindump/src/import/DockerManager.cpp 3521ed5 
>   braindump/src/import/ToolDocker.cpp 090f0bc 
>   braindump/src/main.cpp c6c0c38 
> 
> Diff: https://git.reviewboard.kde.org/r/123554/diff/
> 
> 
> Testing
> ---
> 
> Braindump starts
> 
> 
> Thanks,
> 
> Somsubhra Bairi
> 
>

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

Re: Review Request 123943: Port KoDocumentEntry::name() and mimeTypes() to KF5

[Friedrich W. H. Kossebau]

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


Hi Peter, thanks for your patch. Sorry, seems everyone missed to notice it so 
far. Possibly because we were concentrated to look at phabricator.kde.org which 
Calligra was testing out as pilot contributor.
Next time please make more noise if noone reacts in a week :) E.g. by adding a 
ping to the review request.
The TODOs that your patch fixes have already been fixed with similar code. So 
may I please ask you to close this review request as discarded (only the author 
seems to be able to do it).

- Friedrich W. H. Kossebau


On May 30, 2015, 10:23 a.m., Peter Simonsson wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/123943/
 ---
 
 (Updated May 30, 2015, 10:23 a.m.)
 
 
 Review request for Calligra.
 
 
 Repository: calligra
 
 
 Description
 ---
 
 Getting the data from QPluginLoader::metaData() which contains the entries 
 from the desktop file.
 
 
 Diffs
 -
 
   libs/main/KoDocumentEntry.cpp f24a7ef 
 
 Diff: https://git.reviewboard.kde.org/r/123943/diff/
 
 
 Testing
 ---
 
 Verified name() output the Name entry value from the desktop file and 
 mimeTypes() the MimeType entry value.
 
 
 Thanks,
 
 Peter Simonsson
 


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

Removing Braindump, Calligra Active, MPP import filter on Sep. 2nd

[Friedrich W. H. Kossebau]

Hi,

noone has shown up with interest to keep Braindump  Calligra Active alive and 
care for porting them to Qt5  KF5.

So before we start with further porting  refactoring again after the freeze 
on master is melted, I would propose to remove both now in master and add them 
as some other entries to OBSOLETE.txt

Additionally I will also remove the FILTER_MPXJ_IMPORT for Plan (for importing 
MS Project files), as it is broken and noone has come around for all the time 
to fix it.

So last chance for anyone to jump in and take over any of them!

I will remove all on Tuesday, September 2nd otherwise.

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

Re: Review Request 123985: Port sheets' configure dialog to KF5

[Friedrich W. H. Kossebau]

 On June 2, 2015, 7:50 p.m., Tomas Mecir wrote:
  After testing, yeah, the plugin stuff doesn't work, please either port that 
  as well to the new API, or keep it commented out for now. Otherwise looks 
  good.
  
  Thanks!

Yes, problem with KPluginSelector and new Calligra plugins being incompatible 
tracked at https://phabricator.kde.org/T448.
The port of the buttons to Qt5 as done in this patch has been solved meanwhile 
by other commits.
So this review request might need to be discarded now. Peter, can you please do 
that?
Thanks for your effort. Hopefully your next patch will then make it into the 
repo :)


- Friedrich W. H.


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


On June 2, 2015, 4:08 p.m., Peter Simonsson wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/123985/
 ---
 
 (Updated June 2, 2015, 4:08 p.m.)
 
 
 Review request for Calligra.
 
 
 Repository: calligra
 
 
 Description
 ---
 
 Fix buttons and signals.
 ?eenable the plugin selector.
 
 
 Diffs
 -
 
   CMakeLists.txt a4e3f24 
   sheets/CMakeLists.txt c7567c4 
   sheets/part/dialogs/PreferenceDialog.h 543bf45 
   sheets/part/dialogs/PreferenceDialog.cpp 8b044a8 
 
 Diff: https://git.reviewboard.kde.org/r/123985/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Peter Simonsson
 


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

Re: Review Request 124630: Use DATA_INSTALL_DIR instead of INSTALL_PREFIX/share

[Friedrich W. H. Kossebau]

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


Hi Heiko. Please turn this into a bug to track this problem and close this 
review request, until there is a new patch this can be reviewed. That will help 
us tracking review requests which actually can be reviewed :)

- Friedrich W. H. Kossebau


On Aug. 5, 2015, 6:36 p.m., Heiko Becker wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/124630/
 ---
 
 (Updated Aug. 5, 2015, 6:36 p.m.)
 
 
 Review request for Calligra.
 
 
 Repository: calligra
 
 
 Description
 ---
 
 Allowing to configure the install location, which is helpful with a
 multiarch layout, where prefix might be something like /usr/arch but
 arch independent data should be installed to /usr/share/...
 
 
 Diffs
 -
 
   active/CMakeLists.txt 8fa0c6f1c04220f9178d0be1ea27b5c1428cd4d2 
   krita/data/profiles/CMakeLists.txt a2a997b30aa159a36369e3825a1c8962597f07c4 
   krita/data/profiles/elles-icc-profiles/CMakeLists.txt 
 f252e164e506f40780523a4a0b1b545257b64801 
 
 Diff: https://git.reviewboard.kde.org/r/124630/diff/
 
 
 Testing
 ---
 
 Checked that the affected files get installed into the desired location.
 
 
 Thanks,
 
 Heiko Becker
 


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

Re: Removing Braindump, Calligra Active, MPP import filter on Sep. 2nd

[Friedrich W. H. Kossebau]

Am Sonntag, 30. August 2015, 20:42:42 schrieb Jaroslaw Staniek:
 How about a blog entry and sending the info to more kde mailing lists?

Which would be a good idea. We should have even done that at the beginning of 
the port. And then see if someone shows up in all the weeks till now.
/me jumps into time machine...
*puff*smell of onions*piff*
/me returns

Et voila;
https://frinring.wordpress.com/2015/04/17/like-braindump-adopt-it-for-the-qt5kf5-port/
https://mail.kde.org/pipermail/calligra-devel/2015-April/013668.html

Hm, seems noone showed up in all the weeks till now.

WRT Calligra Active, PlasmaActive with the old architecture is dead. No idea 
what architecture there is with PlasmaMobile, if there already is one. But I 
assume anything Calligra Plasma Mobile should rather get a fresh restart.

And as much as I almost would use Braindump myself, with no developers caring 
for it it is just a millstone for those trying to drive the Calligra libs 
forward.

So moving it out of the working branch seems the obvious solution. 

Cheers
Friedrich

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

Re: Review Request 123554: Readd Braindump to build on frameworks

[Friedrich W. H. Kossebau]

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


Hi Somsubhra.
Thanks for your patch. Sadly the old maintainer has no more interest in this 
application. And noone else is working on it. This is why noone took a look at 
your work all the time. (And I missed the email notice, with my general 
interest in Calligra).

As you might have read, we are looking for a new maintainer for Braindump. See 
e.g. 
https://frinring.wordpress.com/2015/04/17/like-braindump-adopt-it-for-the-qt5kf5-port/

So given you have shown interest in Braindump, by working on creating this 
patch, might you be interest to simply take over maintainership of Braindump?
Please reply quickly, as we are planning to remove Braindump completely in a 
few days otherwise (only discovered your review request now).
Best contact by email on the developer mailinglist of Calligra, see 
https://community.kde.org/Calligra/Contact for best ways to get in contact.

Cheers
Friedrich

- Friedrich W. H. Kossebau


On April 29, 2015, 7:13 a.m., Somsubhra Bairi wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/123554/
 ---
 
 (Updated April 29, 2015, 7:13 a.m.)
 
 
 Review request for Calligra.
 
 
 Repository: calligra
 
 
 Description
 ---
 
 Readd Braindump to build on frameworks
 
 
 Diffs
 -
 
   CalligraProducts.cmake 5b15bbe 
   braindump/braindumpcore/CMakeLists.txt 24f3854 
   braindump/braindumpcore/State.h 5970280 
   braindump/braindumpcore/StatesRegistry.cpp a611bf4 
   braindump/plugins/stateshape/CMakeLists.txt 38c9c5e 
   braindump/plugins/stateshape/CategorizedItemDelegate.cpp 4e7a802 
   braindump/plugins/webshape/CMakeLists.txt 07b25ba 
   braindump/plugins/webshape/WebShapePlugin.cpp 0e8c42e 
   braindump/src/AboutData.h d3dadc4 
   braindump/src/CMakeLists.txt 0aae217 
   braindump/src/MainWindow.h d035630 
   braindump/src/MainWindow.cpp b31df13 
   braindump/src/SectionsIO.cpp b2d07b7 
   braindump/src/StatusBarItem.h 9afba37 
   braindump/src/View.h c3f2cf7 
   braindump/src/View.cpp 58a05da 
   braindump/src/import/DockerManager.cpp 3521ed5 
   braindump/src/import/ToolDocker.cpp 090f0bc 
   braindump/src/main.cpp c6c0c38 
 
 Diff: https://git.reviewboard.kde.org/r/123554/diff/
 
 
 Testing
 ---
 
 Braindump starts
 
 
 Thanks,
 
 Somsubhra Bairi
 


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

Re: Review Request 123955: get calligra frameworks to compile with qt 5.5 by including needed headers

[Friedrich W. H. Kossebau]

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


This has been commited meanwhile as c0453b985be60dd85f9c264f1d17455edd5a9bf1, 
so please close this review request, to help us manage open ones :)

- Friedrich W. H. Kossebau


On May 30, 2015, 11:04 p.m., Nerdopolis Turfwalker wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/123955/
 ---
 
 (Updated May 30, 2015, 11:04 p.m.)
 
 
 Review request for Calligra.
 
 
 Repository: calligra
 
 
 Description
 ---
 
 get calligra frameworks to compile with qt 5.5
 
 
 Diffs
 -
 
   filters/words/mobi/MobiFile.cpp 00922b06f995e54e3cbc1d8fd23334626711163f 
   libs/flake/KoGridData.h 19acb74dd69ba706d6ec26cdb394ba2840ad75d5 
   libs/flake/KoPathPoint.cpp 5ae455480075409d10db5cdb9d1b3692927346c2 
   libs/flake/KoPathShape.cpp b3d1d22038570519569bc70df96d7352669eace5 
   libs/widgetutils/KoProperties.cpp 24e0219079f76856ca00a4c7b576413785b528da 
 
 Diff: https://git.reviewboard.kde.org/r/123955/diff/
 
 
 Testing
 ---
 
 Compile with Release, and against QT 5.5
 
 
 Thanks,
 
 Nerdopolis Turfwalker
 


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

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

[Friedrich W. H. Kossebau]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Re: Handling of splitted Calligra repos and API changes

[Friedrich W. H. Kossebau]

Am Sonntag, 30. August 2015, 23:21:59 schrieb Jaroslaw Staniek:
 On 28 August 2015 at 19:10, Friedrich W. H. Kossebau kosse...@kde.org 
wrote:
  Hi,
  
  with KDb, KProperty and KReport, a few libs/frameworks have been already
  split off during the port of Calligra to Qt5/KF5.
  
  And they pose a challenge that needs to be solved quickly:
  traditionally we have had no ABI guarantuee in Calligra even in patch
  releases and of course also not during development. Because sourcecode of
  all libs and libconsumers were in a shared repo, and any API changes were
  done in atomic commits both to the libs and libconsumers (because by
  policy we require any commits to the repo to not break it's build).
  
  With libs and libconsumers being split in separate repos the atomicity no
  longer is given.
  
  Which results in problems:
  * people might pull from repos missing part of API change commits
  * current KDE CI triggered by commits will build repos without caring for
  
dependencies between commits, using products from previous lib builds
with
old API for the build of libconsumer with commit using newer API
  
  * ?
  
  No idea how to solve the KDE CI one perfectly. But for the problem of
  pulling consistent states, what about the following rules with the split
  off lib repos:
  * no ABI breakage in patch releases for released branches
  * weekday of API breakage: a set day per week development branches can get
  
commits which involve API changes in the libs in separate repos
still related commits should be pushed together in an as small
timewindow
as possible
  
  No ABI breakage in patch releases might be a no-brainer, given that
  targetted 3rd-party consumers would rely on that as well.
  The second one would pick up something which seemed to work well enough in
  times where close kdelibs and kdeapps development was common, and where
  people also did separate svn pulls for libs and apps. Pushing related
  commits to all repos in small timewindows might not completely match
  atomic commits as possible with subversion. But in the end we all pull in
  time (fetch latest commits now) and not by branch state (fetch commits
  until xyz id), so in practice this might work as well still.
  
  What do you think? Would this work for you as well?
  
  IMHO we need to have an agreed solution here before Kexi-frameworks is
  merged back, because it will force us into this situation (where Plan
  currently does not depend on KReport, my respective patch waiting since
  many weeks for someone to push this question for handling of the
  API-break challenge and to find an agreed resolution ;) ).
  
  ((While in the discussion this is only about those 3 libs for now... My
  personal desire is to make the Calligra document libs more accessible to
  other apps, which partially do document creating/processing. For that I
  would see some advantage to split off more libs into own repos as well.
  In the long run I would like to see Calligra move out of it's own corner
  and integrate more with the normal KDE application scene.
  But more on that once we have finally passed the port hurdle, are back in
  normal feature development and can start talking post-3.0 (where 3.0 is
  now
  the first real release) :) ))

snip part about release branches, seems general agreement and no reason to 
depart from usual handling

 Next, how to check versions. A single properly configured kdesrc-build
 can solve issues when people try to fetch individual repos and make
 human mistakes.
 During development you either use kdesrc-build configured to use the
 branch for the repos (e.g. master)

I see a problem here:
right now everony for the everyday development on the development branch (so 
not stable/release branches) does a git pull or git pull --rebase before 
pushing ones own commits. Because when your patch is ready to be pushed, you 
want to get it out and then do something else. Which you can do now.
Using instead kdesrc-build or similar tools every time will add cost more time 
during that process. And even some seconds already are annoying, when they do 
not improve your developing experience. Worse, if the tool detects a new 
commit in one of the repos and starts a rebuild of that, perhaps even a full 
because some central header was touched, you will lose even more time and be 
even more annoyed. No, I do not see me using something which checks all repos 
every time I do now a git pull. And very possibly also not anyone else.
On a certain day per week, where I can expect breakage, sure. But not 24/7.

We need a solution which does works with a simple git pull on only one of 
any of the involved repos, at least for 6 days in the week.

 For people building largely by hand, I'd introduce a support for
 specific case: a
 find_package wrapper that checks if the dependency has an exact git
 revision. That's like an assertion that tells you that your deps are
 too old (or too new, or even from

Re: Removing Braindump, Calligra Active, MPP import filter on Sep. 2nd

[Friedrich W. H. Kossebau]

Am Sonntag, 30. August 2015, 20:53:32 schrieb Boudewijn Rempt:
 On Sun, 30 Aug 2015, Jaroslaw Staniek wrote:
  How about a blog entry and sending the info to more kde mailing lists?
 
 What would that achieve? Blogging about karbon going unmaintained has
 had zero result. Worse... We have a patch for Braindump:
 
 https://git.reviewboard.kde.org/r/123554/
 
 But no-one to apply it.
 
 There are other KF5 patches on reviewboard, too:
 
 https://git.reviewboard.kde.org/r/123985/
 https://git.reviewboard.kde.org/r/123943/

Too bad, I missed that last one.

Answered all now, in any case.

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

Re: Review Request 124883: Fix compilation of PsCommentLexer.cpp on platforms where char is unsigned

[Friedrich W. H. Kossebau]

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

Ship it!


Indeed there might be more places where this could be a problem.
If only KDE CI also had builds for ARM :)
Do you have commit rights to KDE repos? Otherwise I could commit for you.

- Friedrich W. H. Kossebau


On Aug. 22, 2015, 7:53 p.m., Tom Hall wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/124883/
 ---
 
 (Updated Aug. 22, 2015, 7:53 p.m.)
 
 
 Review request for Calligra.
 
 
 Repository: calligra
 
 
 Description
 ---
 
 The C standard defines char to be either signed char or unsigned char. In 
 this case, the char is used to store negative values to signify categories of 
 characters as well as actual characters. Therefore it must be a signed char 
 and doesn't work on platforms where char is unsigned (e.g. ARM). In this 
 specific case, compilation of the file fails with:
  error: narrowing conversion of '-127' from 'int' to 'char' inside { } 
  [-Wnarrowing].
 
 There may be similar issues elsewhere where the char isn't inside initialiser 
 braces, so it compiles successfully, but silently truncates or wraps the 
 negative values.
 
 
 Diffs
 -
 
   filters/karbon/eps/PsCommentLexer.cpp 6487df6 
 
 Diff: https://git.reviewboard.kde.org/r/124883/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Tom Hall
 


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

[calligra] karbon/stencils: Merge branch 'frameworks'

[Friedrich W . H . Kossebau]

Git commit 86b1e17025e5ac3e1c83f520f86fa47441a637e1 by Friedrich W. H. Kossebau.
Committed on 29/08/2015 at 14:08.
Pushed by kossebau into branch 'master'.

Merge branch 'frameworks'

master is now Qt5/KF5-based, and the frameworks branch done  closed

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

# Conflicts:
#   libs/koreport/koreport_itemplugin.desktop
#   plugins/reporting/barcode/koreport_barcodeplugin.desktop
#   plugins/reporting/chart/koreport_chartplugin.desktop
#   plugins/reporting/maps/koreport_mapsplugin.desktop
#   plugins/reporting/web/koreport_webplugin.desktop

M  +0-0karbon/stencils/CMOS/gnd_h.desktop
M  +0-0karbon/stencils/CMOS/gnd_v.desktop
M  +0-0karbon/stencils/CMOS/nmos_h.desktop
M  +0-0karbon/stencils/CMOS/nmos_v.desktop
M  +0-0karbon/stencils/CMOS/pmos_h.desktop
M  +0-0karbon/stencils/CMOS/pmos_v.desktop
M  +0-0karbon/stencils/CMOS/vdd_h.desktop
M  +0-0karbon/stencils/CMOS/vdd_v.desktop
M  +0-0karbon/stencils/Cisco/wireless_transport.desktop
M  +0-0karbon/stencils/Cisco/wlan_controller.desktop
M  +0-0karbon/stencils/Cisco/woman.desktop
M  +0-0karbon/stencils/Cisco/woman_blue.desktop
M  +0-0karbon/stencils/Cisco/woman_gold.desktop
M  +0-0karbon/stencils/Cisco/woman_red.desktop
M  +0-0karbon/stencils/Cisco/workgroup_director.desktop
M  +0-0karbon/stencils/Cisco/workgroup_fcis.desktop
M  +0-0karbon/stencils/Cisco/workgroup_switch.desktop
M  +0-0karbon/stencils/Cisco/workgroup_switch_voice-enabled.desktop
M  +0-0karbon/stencils/Cisco/workstation.desktop
M  +0-0karbon/stencils/Cisco/www_server.desktop
M  +0-0karbon/stencils/Cybernetics/sine.desktop
M  +0-0karbon/stencils/Cybernetics/sum.desktop
M  +0-0karbon/stencils/Flags/china_hong_kong.desktop
M  +0-0karbon/stencils/Flags/china_macao.desktop
M  +0-0karbon/stencils/Flags/china_prc.desktop
M  +0-0karbon/stencils/Flags/china_roc.desktop
M  +0-0karbon/stencils/Flags/libyan_arab_jamahiriya.desktop
M  +0-0karbon/stencils/Gane_and_Sarson/alt-entity.desktop
M  +0-0karbon/stencils/Gane_and_Sarson/collection.desktop
M  +0-0karbon/stencils/Gane_and_Sarson/data_store.desktop
M  +0-0karbon/stencils/Gane_and_Sarson/entity.desktop
M  +0-0karbon/stencils/Jigsaw/collection.desktop
M  +0-0karbon/stencils/LST/cn_subsystem.desktop
M  +0-0karbon/stencils/LST/collection.desktop
M  +0-0karbon/stencils/LST/convert_subsystem.desktop
M  +0-0karbon/stencils/LST/decider_subsystem.desktop
M  +0-0karbon/stencils/LST/decoder.desktop
M  +0-0karbon/stencils/LST/distributor_subsystem.desktop
M  +0-0karbon/stencils/LST/encoder.desktop
M  +0-0karbon/stencils/LST/timer.desktop
M  +0-0karbon/stencils/Lights/ACL.desktop
M  +0-0karbon/stencils/Lights/Blacklight.desktop
M  +0-0karbon/stencils/MSE/small_extension_node.desktop
M  +0-0karbon/stencils/MSE/tacsat.desktop
M  +0-0karbon/stencils/Map/Corner1.desktop
M  +0-0karbon/stencils/Misc/collection.desktop
M  +0-0karbon/stencils/Network/dat_external.desktop
M  +0-0karbon/stencils/Network/disc.desktop
M  +0-0karbon/stencils/Network/flash.desktop
M  +0-0karbon/stencils/Network/genmonitor.desktop
M  +0-0karbon/stencils/Network/modularswitch.desktop
M  +0-0karbon/stencils/Network/monitor.desktop
M  +0-0karbon/stencils/Network/patch-panel.desktop
M  +0-0karbon/stencils/Network/pc_bigtower.desktop
M  +0-0karbon/stencils/Network/pc_miditower.desktop
M  +0-0karbon/stencils/Network/pc_minitower.desktop
M  +0-0karbon/stencils/Optics/dfb_laser.desktop
M  +0-0karbon/stencils/Optics/dfb_laser_vert.desktop
M  +0-0karbon/stencils/Optics/edfa.desktop
M  +0-0karbon/stencils/Optics/edfa_vert.desktop
M  +0-0karbon/stencils/Optics/fibre.desktop
M  +0-0karbon/stencils/Optics/fibre_vert.desktop
M  +0-0karbon/stencils/Optics/lpg.desktop
M  +0-0karbon/stencils/Optics/lpg_vert.desktop
M  +0-0karbon/stencils/RDP/collection.desktop
M  +0-0karbon/stencils/Racks/equipment_10u.desktop
M  +0-0karbon/stencils/Racks/equipment_11u.desktop
M  +0-0karbon/stencils/Racks/equipment_12u.desktop
M  +0-0karbon/stencils/Racks/equipment_1u.desktop
M  +0-0karbon/stencils/Racks/equipment_2u.desktop
M  +0-0karbon/stencils/Racks/equipment_3u.desktop
M  +0-0karbon/stencils/Racks/equipment_4u.desktop
M  +0-0karbon/stencils/Racks/equipment_5u.desktop
M  +0-0karbon/stencils/Racks/equipment_6u.desktop
M  +0-0karbon/stencils/Racks/equipment_7u.desktop
M  +0-0karbon/stencils/Racks/equipment_8u.desktop
M  +0-0karbon

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

[Friedrich W. H. Kossebau]

Am Donnerstag, 27. August 2015, 09:57:32 schrieb Boudewijn Rempt:
 For Krita, and I hate to say this, it probably makes sense to fork our
 shared libraries. The office-apps maintainers can then strip out all the
 krita-specific stuff, and for Krita, we can strip out the stuff that only
 makes sense for office applications.
 
 I also think that it makes sense for Krita to integrate the karbon plugins
 and tools, and maybe the karbon filters. I honestly don't see any future
 for karbon as a separate application. You cannot build a good vector drawing
 application without a dedicated maintainer, and Karbon has been officially
 unmaintained since April 2013 already.

Oh dear, for quite some time I have feared this proposal to happen, to split 
off Krita + fork off shared libs into an own project and repo. Sadly I could 
not collect enough arguments why that would be an insane idea and only that. 
From a pragmatical point of view, I see more advantages than disadvantages as 
well for all parties, if I am honest, given the current interest of all people 
involved in contributions. There are more and more who only are interested in 
one app and not the whole Calligra suite, which is just reality and thus fine 
and nothing to blame someone for. And if one only has interest in one app, 
shared goods with other apps cannot be dealt with in the needed manner.
((Ideally those people should be made interested in the whole Calligra suite 
:) But given the current state of most apps that's a mission to fail sadly 
currently))

But: such a split would conflict a lot with my motivation for why I have 
joined the Calligra project and spent quite some time on mainly cleaning up 
Calligra code so far :(

I have been appealed by the vision of a component-based system, where one 
potentially could assemble a custom UI per usecase and create rich composed 
documents with all kind of content. Like I could when I was a kid and blank 
sheets of paper were what I had as canvas, and the working shell was by my 
real-world desktop setup. E.g. with pencils and stickers always in reach on my 
private desktop, depending on my mood of the day, to do whatever mix of 
content on the sheet of paper as I liked.

When then I had my first computer, I was mainly attracted by the virtual 
sheets those enabled. Where things could be undone or reshuffled (no need to 
restart with a new sheet when some text line mistakenly hit the sheet border 
too early or had a typo or when some item was forgotten in the structure and 
no more space was available).
I loved Geoworks, Amipro, and especially Corel Draw, as those gave me many of 
the composing freedoms one had with a real sheet and then all the amazing 
options coming with virtual objects. (And I miss them, so far I found no real 
FLOSS replacement)

Writing reports during education and work I experienced additional challenges, 
how to best do big structured documents and also automatically integrate 
things generated from data, like calculations, diagrams, graphs or tables. 
Doing this with the wordprocessors available to me was not easy, escaping to 
TeX (or Lyx) only satisfied me to a certain degree.

Which is the other aspect of Calligra that appealed me, having Kexi, Sheets 
and a report generation library as part. So I envisioned one day this should 
end up with being able to have not only classic line  bar diagrams, but e.g. 
whole flow charts being generated, with custom shapes dynamically powered by 
data from databases or cell ranges in sheets. 
One would edit the database table in some UI made from Kexi components or some 
cell ranges in a UI made from Sheets components and see the document update in 
realtime. Perhaps even be able to sync changes back from the shapes (e.g. when 
resizing some element interactively). (Actually I kept Plan alive for now 
mainly for the reporting stuff, to have another use case around).

Connected with this, I also share Jarosław dream about document-wide 
theming/styling, where all components in the document are bound to the same 
styling system, and any custom component plugin could link into it. So e.g. 
colors and fonts in diagrams would be coupled to those of the complete 
document, for a consistent look.

Next, when I wrote the print exporting functionality in Okteta, a hex 
editor, I would have liked instead to render into some document system, where 
one could edit the template (think footer/header/title/styles) or and more 
(actually I once did a hexeditor Shape plugin, that could at least render :) 
). There are many applications which render/export content to documents, just 
think of all the science app in KDE Edu, like Labplot or Cantor. But 
usually with hardcoded templates. This seems poor to me, we could do better 
especially in the Free and Libre Software world, where collaboration should be 
easier than in that other buy-only-our-products lock-in world.

Which brings me back to Krita. So, with real world sheets I preferred pencils 

Handling of splitted Calligra repos and API changes

[Friedrich W. H. Kossebau]

Hi,

with KDb, KProperty and KReport, a few libs/frameworks have been already split 
off during the port of Calligra to Qt5/KF5.

And they pose a challenge that needs to be solved quickly:
traditionally we have had no ABI guarantuee in Calligra even in patch releases 
and of course also not during development. Because sourcecode of all libs and 
libconsumers were in a shared repo, and any API changes were done in atomic 
commits both to the libs and libconsumers (because by policy we require any 
commits to the repo to not break it's build).

With libs and libconsumers being split in separate repos the atomicity no 
longer is given.

Which results in problems:
* people might pull from repos missing part of API change commits
* current KDE CI triggered by commits will build repos without caring for
  dependencies between commits, using products from previous lib builds with
  old API for the build of libconsumer with commit using newer API
* ?

No idea how to solve the KDE CI one perfectly. But for the problem of pulling 
consistent states, what about the following rules with the split off lib 
repos: 
* no ABI breakage in patch releases for released branches
* weekday of API breakage: a set day per week development branches can get
  commits which involve API changes in the libs in separate repos
  still related commits should be pushed together in an as small timewindow
  as possible

No ABI breakage in patch releases might be a no-brainer, given that targetted 
3rd-party consumers would rely on that as well.
The second one would pick up something which seemed to work well enough in 
times where close kdelibs and kdeapps development was common, and where people 
also did separate svn pulls for libs and apps. Pushing related commits to 
all repos in small timewindows might not completely match atomic commits as 
possible with subversion. But in the end we all pull in time (fetch latest 
commits now) and not by branch state (fetch commits until xyz id), so in 
practice this might work as well still.

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

IMHO we need to have an agreed solution here before Kexi-frameworks is merged 
back, because it will force us into this situation (where Plan currently does 
not depend on KReport, my respective patch waiting since many weeks for 
someone to push this question for handling of the API-break challenge and to 
find an agreed resolution ;) ).

((While in the discussion this is only about those 3 libs for now... My 
personal desire is to make the Calligra document libs more accessible to other 
apps, which partially do document creating/processing. For that I would see 
some advantage to split off more libs into own repos as well. In the long run 
I would like to see Calligra move out of it's own corner and integrate more 
with the normal KDE application scene.
But more on that once we have finally passed the port hurdle, are back in 
normal feature development and can start talking post-3.0 (where 3.0 is now 
the first real release) :) ))

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

Big reformat of sources before unfreeze of master (was: Re: Schedule to switch back to master for feature development)

[Friedrich W. H. Kossebau]

Am Freitag, 28. August 2015, 15:48:39 schrieb Boudewijn Rempt:
 On Thu, 27 Aug 2015, Friedrich W. H. Kossebau wrote:
  * after that:
   2.9 only bugfixes, no more features
   master unfrozen, so open for features and porting from kdelibs4support
 
 I also would like to cleanup the coding style, still...

Ah, right. Hm, how do we get that into the schedule? I guess it would be soon 
then, were this should happen, after the merge to master of frameworks and 
Kexi-frameworks and before lifting the freeze.

Which other big branches are still there that would need to be in before such 
a reformat? When will the animation branch go in?

Ff you have a branch which might otherwise suffer from, shout quickly!

Camilla, you also looked into that reformatting, no? Could you collect further 
experiences how to do that?

Notes from plans for reformatting before port start are here, if anyone 
searches:
https://community.kde.org/Calligra/Schedules/3.0/Porting_Plan#Reformatting

Time to update that page a little in general :)

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

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

[Friedrich W. H. Kossebau]

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

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

Okay, task for you then :)

Cheers
Friedrich

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