Karbon: Enable multi page capability
ClosedPublic

Authored by danders on Apr 9 2019, 6:40 AM.

Details

Summary

Since odg spec supports multiple pages, I feel karbon also needs to support it.

The main things that has changed:

  1. Since multiple pages is supported, adding/copying/deleting pages is now possible.
  2. The page background color is now set with a tool in the tool box. The entry for background color in the Settings dialog is superflous and has been removed.

Ported to use pageapp classes.

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

  • Save/load
  • Layers docker and all layer operations
  • Grid, guides, rulers and zoom
  • Event handlers
  • Printing
  • Show page margins has been moved to pageapp

In general, import/export needs review to determine how to
handle multiple pages when e.g. exporting to a format that
does not support pages.

Known bugs:

  • "Separate paths" command:
    • Execute command, the shape disappears.
    • Undo crashes. Note: Afaics this code is not touched so probably a libs bug.
  • Snap to grid does not work
  • Number of recent files does not work properly
Test Plan

I am not an avid user of karbon, so would be nice if some that where could test.
Also, do not have all types of different format docs for filter testing.
Some that work are pdf, svg, jpg and karbon files.

Diff Detail

Repository
R8 Calligra
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.
danders requested review of this revision.Apr 9 2019, 6:40 AM
danders created this revision.

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

This takes care of the page backround issue we have been discussing.
The change is that the color is now saved to the odg document (as it should be, imo).
Since the svg export filter does not save background color, there is no change here.

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

rjvbb added a subscriber: rjvbb.Apr 9 2019, 8:31 AM
(Sorry for the inconvinience, I've never been very friendly with arc/phab)

Understandable ;)

Did you go the "official" route, committing your changes to a local branch and then using arc diff to create a review request? You probably should have used --update revision_id .
I always use uncommitted changes myself, either going through the Purpose/KDevelop plugin to upload a diff to phab, or using the web interface. That approach has its own quirks and inconveniences but ones I prefer.

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

rjvbb added a comment.Jun 4 2019, 10:34 PM

code wise looks good

Apparently it tastes good too, better than the 2 previous versions? ;)

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

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.

OTOH, if one looks at karbon as an *svg* editor, the current background color implementation makes much more sence,
since svg is meant to be embedded in an environment outside of the svg doc itself like screen, html, odg, etc.

This leads me to two possible paths to take:

  1. Karbon as odg editor means this patch goes in.
  2. Karbon as svg editor means swicth to svg as native format and add odg export/import.

(One could of course also keep karbon as svg editor and add a calligradraw app, but well, probably a bit of work...)

danders updated this revision to Diff 59256.Jun 6 2019, 12:33 PM

Add dependence on LIB_KOPAGEAPP

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.

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

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?

Yes, exactly that.

anthonyfieroni accepted this revision.EditedJun 20 2019, 7:52 AM

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.

This revision is now accepted and ready to land.Jun 20 2019, 7:52 AM
danders updated this revision to Diff 69152.Nov 1 2019, 10:07 AM

Handle removing pages from a pageapp properly

danders updated this revision to Diff 69262.Nov 4 2019, 12:28 PM

SvgImport: Add the new layer to the page

danders updated this revision to Diff 69263.Nov 4 2019, 12:36 PM

KarbonView: Add slot to handle replaceActivePage

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

Just for the record: The pdf filter goes through the svg filter and as since svg does not know about pages, all but first page is lost.
We need a new pdf->odg filter that can handle the pages.

This revision was automatically updated to reflect the committed changes.