I saw filters does not compile when it compiles Karbon only, i should correct that, but i have much time now.
Edit: I investigate and it works correctly, i mislead APP_KARBON and KARBON.

In D20400#475648, @danders wrote:

In D20400#475477, @anthonyfieroni wrote:

Now we have insert page, but we don't exports them :) If you think that's ok for now go for it.

If you mean export to svg here, afaics there are no page element in svg. Have I missed it?

In D20400#475477, @anthonyfieroni wrote:

Now we have insert page, but we don't exports them :) If you think that's ok for now go for it.

Now we have insert page, but we don't exports them :) If you think that's ok for now go for it.

Add dependence on LIB_KOPAGEAPP

I have been pondering why we disagreed so much on the background color, and I *think* I have an answer.
My take is it's because we have not been talking about quite the same thing:
I have looked at karbon as an *odg* editor, since it uses odg as its native file format.
Since odg is wysiwyg nothing outside the doc should in any way affect the way it is presented, hence a background that is not saved to file doesn't make sence.

Apparently it has a problem, when we compile only Karbon, as i done now, KoPAView is in pageapp, which is not compile-able in Karbon, right?
Full cmake command

cmake .. -DCMAKE_INSTALL_PREFIX=/usr  -DCMAKE_INSTALL_LIBDIR=lib -DKDE_INSTALL_PLUGINDIR=/usr/lib/qt5/plugins -DKDE_INSTALL_USE_QT_SYS_PATHS=ON -DBUILD_TESTING=FALSE -DPACKAGERS_BUILD=true -DBUILD_UNMAINTAINED=TRUE -DPRODUCTSET=APP_KARBON

code wise looks good

Someone test it, code wise looks good, i plan to test it soon.

In flavor of D20400

In flavor of D20400

First of all, thanks for the work. Some things are passing through my mind, especially regarding classical Hangul and half-completed Hangul characters.

Second ping for this.

(Sorry for the inconvinience, I've never been very friendly with arc/phab)

Ooops, this didn't work as expected. This should have been a revision of D19327.
There is only small changes:

1. Updated commit message.
2. In karbon/ui/KarbonFactory.cpp: Loading of the calligra/pageapp tools.
3. In karbon/data/karbon.rc: Removal of the "format" menu (not used) and adding the "format_pagelayout" action to "settings" menu (where it was originally).

Ping, how about this one? The behavior change, or lack of it, should be mostly visible around qgraphicswidget_p.h -> attributeToBitIndex() & setAttribute().

If memory serves, we'll need to do a fair bit of work to get the DropBox code to work properly again. DropBox has turned off the V1 API support, and we'll need to work against the V2 stuff now, which... Well, it might be trivial, but i have no time to look at it, i'm afraid. Be really good to get it back, though.

Yes, looks sane, I'll deal with it.

I think this should be ok

Ping this looks sane, anyone ?

In D19912#435067, @pvuorela wrote:

In D19912#435058, @danders wrote:

Strange indents, could you fix it?

That's what I commented on the summary. On some parts rtf-qt uses plain spaces for indentation and those parts look good. Then in the same file other methods might have a hard tab or a hard tab followed by spaces. If you really want, I can try to retain the old whitespace, but it's indentation-wise more or less broken already anyway :) Alternatively could run astyle for the subdirectory, though maybe best done as separate commit.

Yes, sorry, as you say better done separatly.

The directory README also states "Temporary local copy of Brad Hards' rtf-qt library.", though as upstream hasn't had changes since 2011, it seems like a permanent one by now.

Probably.

In D19912#435058, @danders wrote:

Strange indents, could you fix it?

Strange indents, could you fix it?
Otherwise ok.

Eliminated one unintended #ifdef SWINDER_XLS2RAW removal from the patch.

Updated to remove also WA_StaticContents in addition to earlier WA_InputMethodEnabled.

In D19216#421689, @rjvbb wrote:

That is actual a valid point, although in say Krita with transparent pixels a checkerboard is shown.

Heh, I've had the opportunity to work closely with professional infographists so I picked up a thing or two about using applications like Illustrator and InDesign :)

How to indicate a transparent area of an object is yet another subject, with a related but not identical purpose.

That said it might make more sense for this "testing background" to be part of the document and not a general setting - if the use case is as you say then the testing background would also be different for different projects

True. I was reacting to *re*moving a setting completely, not to moving it to a more appropriate context.

That is actual a valid point, although in say Krita with transparent pixels a checkerboard is shown.

In D19216#421654, @rjvbb wrote:

No, the canvas is part of the document and must never be themed. The canvas background is as much part of your drawing as any line you put on it.

This hasn't been sitting right with me and I finally realised why.

That statement is true when you work with a real canvas and draw/paint/whatever directly onto that. If you take a grid paper the grid will become part of your art, but does Karbon print the grid which you can have it show (except possibly via an option)?

In drawing applications, the canvas is NOT part of your art, but simulates the canvas you'll be printing on. It's a backdrop layer that sits behind/below the lowest layer you can draw on. If you plan to print on a coloured piece of paper, or one with a canvassy texture, you'll probably want to adapt your virtual canvas so you can incorporate the physical canvas properties into your design. But you don't want that virtual canvas to print as that would be a waste of toner at best...

That is actual a valid point, although in say Krita with transparent pixels a checkerboard is shown.
That said it might make more sense for this "testing background" to be part of the document and not a general setting - if the use case is as you say then the testing background would also be different for different projects

That's not to say that the virtual canvas should not be exportable at all: you'd want to be able to include it when generating a PDF (SVG, JPG, etc) format version for use in on-screen only presentations. Of course you could just add a backdrop layer in that case.

I'm not aware that Karbon has the equivalent of a slide/page design feature where you can define how each page will look. That could look be used to be achieve what I describe here but in Karbon that layer should probably not be printed by default (just like it isn't in presentation apps, IIRC).

No, the canvas is part of the document and must never be themed. The canvas background is as much part of your drawing as any line you put on it.

no

Can we get a conclussion to this?
@Camilla Have you come up with any more unit tests?

totally agree about not theme'ing canvas

In D19216#417502, @rjvbb wrote:

Canvas color:
I don't quite see what it is for. You can set a background color for the canvas but it is only for the views, it is not printed.

A custom canvas colour feature doesn't strike me as odd, nor that it isn't printed (printing it WITHOUT setting a dedicated option would seem wrong to me).

What about when you use an inversed theme, isn't a custom canvas colour required then if you want to see your black line art on a light (white) canvas?

No, the canvas is part of the document and must never be themed. The canvas background is as much part of your drawing as any line you put on it.

Canvas color:
I don't quite see what it is for. You can set a background color for the canvas but it is only for the views, it is not printed.

In D19216#417288, @rjvbb wrote:

This would indeed be great to have; even a page selector when importing a multi-page document would be an improvement (the Adobe Illustrator version I've use had that; IIRC it would just leave all other pages of the document alone).

You should also test with PDF documents; in my experience Karbon 3.1 works well enough with them.

Yes, pdf docs work, it is almost 100% handled by poppler.

...

A lot of code was duplicated between pageapp and karbon
and has been removed from karbon:

Shouldn't that be a separate change - or does multi-page support come automatically with this change?

Well, my initial thought, but there was going to be quite a few intermidiate solutions mainly because
the KoPACanvas cannot be subclassed, so I decided to do everything in one go.

This would indeed be great to have; even a page selector when importing a multi-page document would be an improvement (the Adobe Illustrator version I've use had that; IIRC it would just leave all other pages of the document alone).

Thanks for the review, I will work next on libs/{pigment,version,widgetutils}.

Hmm, maybe wait with pigment, according to rempt, only krita actually used it.
I haven't looked into it, but if that is the case probably we should dump it.

In D19132#416519, @danders wrote:

Ok, I can't say I have scrutinized every change, but...
Could you give a heads up when you continue with other parts or else there may be merge problems.
I'm working on karbon and pageapp atm, so please keep off :)

Ok, I can't say I have scrutinized every change, but...
Could you give a heads up when you continue with other parts or else there may be merge problems.
I'm working on karbon and pageapp atm, so please keep off :)

Fix build

• Revert foreach modifications
• Fix some forgotten 0 as nullptr instances

There is an issue with Qt's foreach, however if the author would be so nice as to check that this version using C++11 iteration does not break building on Windows, then it can go in... Though, yes, it most certainly wants testing, and i don't currently have a functioning windows build system. 2890f2a929034d613c4b4a8f3e6ad77c23162d41 is one of the commits which did the q_foreach/for loop change previously, to see what actually got changed.

Hmmm. wasn't it somethng with ms windows and for loops, leinir?
Also, I think there may be detachment issues with them, clazy can tell.
There is a qAsConst() solution but that is not supported in the qt version we need to support.
If there are issues, maybe drop the for loops for now.

This was accepted, but was it also committed yet?

In D18994#412049, @leinir wrote:

A quick note that you kind of got the name of the suite wrong in a few places, it's called Calligra, not Callibra :)