khal
khal copied to clipboard
Discussion: filter calendar widget
Hi,
I'd like to propose a feature and also offer to implement it. The idea is to filter events or whole calendars from the day highlighting in the calendar while keeping the agenda untouched.
For that matter I would introduce a calendar-level config filter_from_highlighting that can either be a boolean or a string and defaults to False
- when set to
Truethe whole calendar would not be considered for day highlighting. A usecase would be birthday calendars that I myself want to be featured in the agenda in a prominent color (thus preventing me from just setting an empty calendar color) but don't want to show up in the calendar widget. - when set to a string it would considered to be a (python-re-style) regex that filters events from the calendar whose title matches the regex. For example on my business calendar I would use the regex
"(^Daily)|(^Away:)"which would filter both my Scrum dailies and away-notifications from colleges so a day in the calendar would only be highlighted in the color of the business calendar if I really have a meeting.
I had a deep dive into the relevant code parts yesterday. So I have a fair idea what I am getting myself into (including changes to sqlite schemata) and how to attack that problem.
Would that feature be interesting for you? Any changes you would suggest?
However as I already observed in a merge request the code implementing the day highlighting is pretty much duplicated for ikhal and khal calendar. So before making it even more complicated I would like to refactor it into a single code base for both usages that is actually testable and decoupled from the "dirty business of really applying the colors".
the config field could also be just string where ".*" is equivalent to True (filter all) and "" to False (filter none). Not sure about that one.
ok my comment about having to refactor some color managing code is not relevant anymore. I had a deeper look and I don't even have to go into that part of the code (the comment is IMHO still valid though)
this is how I'd go about this:
- add a boolean flag
filter_from_highlightto the sqlight event table (increasing the db version) - add the checks outlined in the initial comment to
khalendar.update(),khalendar.force_update()andkhalendar.new()and store the result infilter_from_highlight(changing the respective functions inbackend) - add boolean flags to
backend.get_floating_calendars()andbackend.get_localized_calendars()that cause the query to search only for events withfilter_from_highlight = False - tell
khalendar.get_calendars_on()to provide that flag
That should unlock the basic functionality. I am pretty happy with that. We have the performance hit only where it's needed and when it's needed. The changes are rather small and not too complex.
However to display config changes right away I'd also need to:
- add a string field
filter_from_highlightto the sqlight calendar table - store the respective config value there (
khalendar._db_update()) - tell
khalendar._needs_update()to compare the value stored in the cache to the value in the config. If they differ the calendar needs an update (to recompute the boolean flags in the events)
This should trigger a full update of a calendar whenever its filter value changes.
Sounds good?
ok that was dirtier than I thought. But works and cleans up the calendar nicely