Seems good.

Seems good.

Looks good to me.

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.

KarbonView: Add slot to handle replaceActivePage

SvgImport: Add the new layer to the page

Handle removing pages from a pageapp properly

Remove duplicated cmake definition.

I think add should be conditional.

This looks like a nice and useful collection of changes to me.

Update image size reading conditions

Thanks here also @dcaliste. This is all a bit confusing I agree and deserves some explanation. I've added in something along the lines you suggested, which I think helps (your insight that the scaling has to match the font DPI really makes it clear).

Thanks @dcaliste, this is an excellent suggestion and much better naming. I've updated the diff to make the changes you suggested.

Removed whitespace changes.

@davidllewellynjones, I hadn't time yet to test the patch, but the idea and implementation is already looking great in my opinion. Maybe, just one remark after looking at the proposed additions: not saving the formale, but the values should not be named read-only. Indeed, maybe in the future, we would like to be able to "inspect" the content of a cell, even on portable devices. Being able to read the formulae should then be possible, even if not for modification. I may suggest the following naming changes (functionality to load by values to help loading time is great) :

• MSOOXML_IMPORT_READ_ONLY -> MSOOXML_IMPORT_BY_VALUES or MSOOXML_IMPORT_VALUES_ONLY
• MSOOXML::readonlySpreadsheet() -> MSOOXML::byValuesSpreadsheet() or MSOOXML::valuesOnlySpreadsheet()

Whitespace adjustments

I've made some suggestions and have a couple of queries, but they're all very minor.

The patch looks fine, thank you.

Well, after reading the difference between the logical and physical DPI values: https://stackoverflow.com/questions/16561879/what-is-the-difference-between-logicaldpix-and-physicaldpix-in-qt (see the first answer), using the logical value is consistent with the hard coded "arial 10" font metric some line above.

In D24852#553906, @boemann wrote:

All I'm saying is removing it completely is probably just as wrong as leaving it in. Maybe you could come up with some if case

All I'm saying is removing it completely is probably just as wrong as leaving it in. Maybe you could come up with some if case

In D24852#552012, @boemann wrote:

I think this will break those headings that actually should have numbering, so i think further investigation is needed with such cases

Seems it was indeed the only physicalDpi, though not too many logical either. Not trivial to follow, but seems sane and the screenshots are thorough. I'll approve if no-one objects shortly.

I think this will break those headings that actually should have numbering, so i think further investigation is needed with such cases

Looking good to me.

As far as I'm concerned you may push to rtf importer at your own discretion

Fixed set value from "true" to expression " ! hasValue || ( hasValue && value != 0 ) "

Looks simple enough to me too - someone please push

How can we push this forward?

Let's commit this, it's fair small patch but it covers some unwanted crashes.

Long as that works on linux, that ought to do the trick, yes :) (probably ought to have been there to start with anyway)

I can't test, but it should be fine.

Something tells me there's going to be problems on windows if this gets done... since that is the precise reason that code exists in the first place: https://phabricator.kde.org/R8:c1866b590bd6103fdf118558834104be2737cca4

Test plan:

Sorry, made a mistake with arc… This differential revision is already D23492.

And even rendering now better, no idea what happened.

Having a bit strange rendering for TextDocumentImpl.cpp changes here, but the raw diff looks good now. Trust all good :)

In D23617#523417, @anthonyfieroni wrote:

That makes sense but none handle that schemes or should be responsible for that?

Thank you pvuorela pointing out other places for this construct. I've updated the patch with a fix for the faulty loops for spreadsheets and presentations also.

That makes sense but none handle that schemes or should be responsible for that?

The idea is that the template protocol gets caught by the components, which marks the file as new, resets the filename and so on (the way you would expect a template to work). Doing it this way just opens the template as a file, and requires the user to manually do the save-as thing... Unless you are trying to actually edit the template, this isn't the solution... Create file will be something similar.

Fix a bunch of crashes :)

Oh dear, yes, took a moment. Well spotted indeed!

Indeed that doesn't look like a good loop, if triggered once, nothing affecting the break out condition inside of it. But isn't the same thing happening also at the beginning of this method, and actually same kind of construct being there in spreadsheet and presentation impls too?

Well spotted. Yes, this is frankly from before i quite understood how smart pointer types worked, so... yeah, my bad, and thanks for sorting this :) As you say, there's plenty of more stuff to do, including some semi-basic interaction issues...

In D23202#513068, @vkrause wrote:

see https://cgit.kde.org/kcalcore.git/tree/src/CMakeLists.txt#n138 - seems to work here

Version header backward compatibility addressed in D23204.

see https://cgit.kde.org/kcalcore.git/tree/src/CMakeLists.txt#n138 - seems to work here

In D23202#513056, @vkrause wrote:

This isn't wrong, but I'm surprised it's needed, we explicitly install headers in the old location too, for compatibility?

This isn't wrong, but I'm surprised it's needed, we explicitly install headers in the old location too, for compatibility?

Because i was away for a short vacation i coudnt commit this one but
@dfaure committed same thing :) with 0c5430697bdcf41a45046107b28014e40c49a11a
So i think we need to discard this review

In D22545#498239, @usta wrote:

i will just commit this to master or do i need to xommit to a branch then merge it to master ?

i will just commit this to master or do i need to xommit to a branch then merge it to master ? (i have been away from kde about more then 6 years)

btw For such small fixes we don't usually require review