[Kde-pim] KHolidays regions

[John Layt]

On 3 June 2014 19:26, Allen Winter <winter at kde.org> wrote:
> On Tuesday, June 03, 2014 08:49:51 AM Justin Eberlein wrote:
>> I noticed on the community.kde.org page that one of the goals is to "split
>> the existing holiday files up into civil and religious files". I've
>> actually already started this. I'm a fairly devout Catholic, and
>> admittedly, one of the first things I did when I discovered I could make my
>> own holiday regions was add the liturgical calendar. In other words, I
>> added a title to every single Sunday of the year, a few holidays above
>> that, and some rules for what overrides or moves what.
>>
>> If you want to add holiday regions like that, I'm more than willing to
>> help. If I polished it up a bit, I'd be willing to submit my custom file
>> for inclusion in the official database. And I'm familiar enough with
>> religious calendars that I could easily modify it for other Christian
>> denominations, as well as figure out what a similar file could look like
>> for non-Christian religions.
>
> As I was involved in writing those design goals I'm very glad to see someone
> who wants to help make this happen.
>
> We would need a developer to join in and make the necessary code changes,
> both in kholidays library and also in the clients (KOrganizer).

I was working on this some time back, but was never able to come up
with a solution I was happy with, I was constrained both by the old
file format and the old class api, then got distracted by other things
including the new file format which would be more flexible.

There were two types of categories I wanted to add that would have
separate enums and api methods:
* Holiday Class, e.g. Civil, Religious, Commemorative, Name, etc.
* Holiday Type, e.g. National Day Off, Regional Day Off, School Day Off, etc.

I was still trying to figure out how to split or combine these and how
to name them.  Would you allow a holiday to be tagged with multiple
Classes and multiple Types, or only a single one of each?  Would Type
have a hierarchy, i.e. National Day Off implies Regional and School
and Financial days off, or would we have to list every applicable Type
for every holiday?  Or would we just merge Class and Type in the files
and allow multiples of all tags, then split them later in the api?  Do
we have a single Religious Class, or do we need a Class for each
religion to allow people to choose which they want?  For Public /
Statutory holidays do we have that as a Class as well as a Type, or is
that just redundant?  What happens if a National Day Off is for a
Religious holiday and a user chooses not to show Religious holidays?

There was also the option of having global level files that were not
associated with a particular country, i.e. all Catholic holidays in
their own global file, all Jewish Orthodox holidays in their own
global file, etc, which would save duplication of them in each country
file.  Of course, some of these holidays are more important in some
countries than others, so could also stay in their country files, but
that could cause duplication issues.  Also not all the global files
would be available in all the languages, so again the national file
would need to keep the key days.  Other global files could be Name
Days, Astronomical Events, etc.

I thought of 3 possibles ways to implement categories in various forms:
* Modify the file format to replace the two "color" fields with the
two category fields, one field for a single pre-defined Holiday Type
keyword, one for a list of one or more pre-defined Holiday Class
keywords.  This would involve modifying the file parser written in
bison/flex which is always a tricky process.
* Repurpose the "stringcolor" field to have 1 category only allowed
per holiday.  Currently this field has valid values of various colors,
but also the value "weekend" which is the only value we now use to
mean it is a day off.  We could fairly easily change the allowed
values to be the category names instead of colors, with "public" being
the special case that means a day off.  Again that's a change to the
file parser, albeit a lot simpler.
* Split regional files into multiple files, each representing a single
category for that region, with an extra tag in the filename to
indicate the category, e.g. have holiday-us-en_us-public,
holiday-us-en_us-religious, etc.  This would be a quick and easy
solution as the file parser doesn't need to change, and would be great
for some Classes with lots of holidays (name days, saints days, etc)
but is rather simplistic, and produces a lot of files which will be
harder to manage.

Another problem was how to represent this in the gui, there would need
to be some way for people to choose what categories to display.  The
multiple files option was the easiest, they would each show up as a
separate holiday region in the existing widget to be turned on or off,
no changes required.  The other options however would require a way of
selecting from a list of the available categories for a region (a
combo-box with tick-boxes inline next to the items?).

In the end, I think I was working towards a combination of options 1
and 3, modify the file format to cater for multiple Class and Type
tags to allow for maximum flexibility, but also add an otherwise
meaningless variant keyword to the file name to allow for global level
or category files, e.g. holiday-xx-en_us-catholic.  Implementing the
latter should be very straightforward for anyone, but messing with the
file format is not so easy so someone else may prefer to do the
simpler option 2.  That said, I'm tempted to try the full solution
again myself, I may even have code somewhere...

John.
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/