As a nobody, my opinion on the rightfullness to split or not the repository is of no interest. But what I like in the proposition of @leinir is the target to separate the "engine" from the UI (_i.e._ the widgetery). As an example (hopefully not outdated), the "find" classes, the one to search and replace, are deeply liked to the widgets that control them. It makes it impossible to reuse these class in a UI different from the original one.

Thanks @winterz for review.

Rename mistake in header declaration (incidence -> notebook).

Ping ! Do you have any remarks on this matter of created date set ?

Add in the test another ICS data to ensure that existing CREATED and LAST-MODIFIED flags are kept.

The patch is not necessary the ideal one, but I would like to start a discussion on this matter. Currently, when calling ICalFormat::fromString(), all created incidences feature a created() and a lastModified() properties. They either come from the values read from the ICS data string, or they are set to the current date time by Incidence::recreate() from Incidence constructor.

I like the idea of trying to move away from the monolythic release. Not that my opinion matters much, but I'm willing to help in the endeavor. I'll try to participate in tasks in that direction as much as my free time will allow it.

Is there something wrong with these tests ? The assumptions tested are not correct ? Is this a coding standard issue ?

@pvuorela as you prefer, anyway, it's a question of taste, I find it myself easier to follow if the information is on one variable only. But your solution is good also, the file is small and is kept small so easy to follow.

Just a suggestion to avoid adding a variable which meaning may be redundant with the state of an already existing one. Otherwise LGTM.

There actually is no bug in KCalendarCore regarding this topic of exceptions for a local time event. We had to fix various ones in SailfishOS ancient version of KCalCore and we have added tests for this. I'm happy to see that the tests are passing in KCalendarCore out of the box, and since we crafted these tests, I'm proposing to add them here.

Thanks for the review and having found the issue. Commited.

@vkrause see https://phabricator.kde.org/D25367 for a patch ensuring a fallback to the system time zone if invalid.

Here is the patch to ensure that a calendar cannot be created with an invalid time zone.

@vkrause sorry, I misunderstand by looking at the current code of kitinerary… Before it was with a QTimeZone(), but systemTimeZone() is actually working. Patch is coming to ensure that systemTimeZone is used when creating a MemoryCalendar from an invalid time zone argument.

I added systemTimeZone() there to work around this issue.

I've open this Qt bug : https://bugreports.qt.io/browse/QTBUG-80146

Indeed, such snippet is segfaulting on the second toTimeZone() call:

@vkrause Oups, that's bad. I'm giving a look. Sorry for the introduced issue but thanks for reporting :/

@winterz thanks for the tests, it's greatly appreciated. I'll give a look to the bugs you mentioned to see if there is some report already about floating time issues with timezone.

@mlaurent I agree. That is the point of my opening sentence "take the opportunity of this patch to discuss the consequences here". I'm wondering how codes using KCalendarCore are currently handling floating time events incoming from iCal data during a sync operation for instance. Looking at the code, I guess that they are ignoring the floating property and display the event in the current time zone. What happens when they are travelling to another time zone ? What happen when they upsync again this event to a remote server ? Didn't any users already notice that floating time events are not kept floating after up sync ? Am I completely wrong and I'm missing something here that make possible to handle floating time events with the current code ?

@winterz thanks for looking at this. I'm sorry, I forgot to talk about the context. Indeed, I've no bug related to this. This is coming for the work I'm doing to port from the ancient Meego-era KCalCore code in SailfishOS to the latest upstream. One of the work in the transition in SailfishOS is to replace KDateTime by QDateTime. Doing this, I notice that the ClockTime spec of KDateTime does not exist anymore. This spec is currently used to store floating time events. So I wonder, how are they doing upstream ? And the best way to look at this, in my opinion, was to look at the reading of iCal floating time in icalformat_p.cpp. That's how I notice that floating times were converted into current system time zone, which is fine at the moment of reading the iCal data, but leave no way to store the event as a floating date (so viewing this event after a time zone change like travelling, will actually display the event at the wrong time) and worst, sending back this event to a server in a sync process will loose the floating date information and will attach this event to a specific time zone. Thus the patch.

Correct wrong indentation.

I think that tests are still passing properly, but this change may have unexpected consequences. I would like to tqke the opportunity of this pqtch to discuss if it's a valid approach for floating date time input. Thank you.

Great, thanks for the review, I'll push it later today or tomorrow.

Would you please review this patch for time zone proper handling in MemoryCalendar ? The block deletion in rawEventsForDate() is in my opinion justified by the fact that when looking in the cache, we're looking for events that are neither multidays nor recurrent. So testing the end date for such one day only events has no point. What do you think ?

@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()

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.

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

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.

Thank you all for the review.

Thank you @leinir for your review. I've not disappeared, but I'm still thinking about a way not to expose the impl object from Document class, while not cluttering the Document API with methods like setBackgroundColor(), setPageCache() or any other future canvas methods that I may think about.

Sorry, I was not clear in my description, I'm not setting the paper background color, but the item background color, i.e. the small area around and between the pages. In most desktop application it is light grey. But when using the KWCanvasItem in another context, it would be nice to be able to set this color. It's kind of desktop color if you prefer.