Integrate re-worked WikiCalendarMacro in new trunk (based on WikiTicketCalendarMacro)

Thanks for appreciation of my work on WikiTicketCalendarMacro.

I was thinking about this before, but not mentioning it, since someone may think it as takeover of WikiCalendarMacro to promote WikiTicketCalendarMacro. That said I can certainly think of a miniature mode for WikiTicketCalendarMacro that has the features of WikiCalendarMacro, for at least the following reasons/advantages:

• even greater versatility of WikiTicketCalendarMacro (feature bloat's always luring there)
• better support by concentrating on just one of two indeed very similar Trac plugins

There is even a chance to get improvements done in WikiCalendarMacro into WikiTicketCalendarMacro.

From a first glance I think the incorporation of WikiCalendarMacro would be more challenging then switching CSS. WikiCalendarMacro behaves quite differently i.e. with regards to display adjacent months days and days with milestones. Anyway, I just take it as a task try to come up with a solution, if it could be done with reasonable resources. So let's take a closer look at the source and current tickets.

I'm coming back from triaging seven open tickets for WikiCalendarMacro right now: #64, #289, #562, #578, #6527, #6636, #7232

There is definitely something to learn for WikiTicketCalendarMacro, and I'll go on with this task as feedback on my request for testing and comments is flowing back to that tickets.

Replying to hasienda:

I'm coming back from triaging seven open tickets for WikiCalendarMacro right now: #64, #289, #562, #578, #6527, #6636, #7232 There is definitely something to learn for WikiTicketCalendarMacro, and I'll go on with this task as feedback on my request for testing and comments is flowing back to that tickets.

Thanks for the work triaging those!

The WikiCalendarMacro, like the WikiTicketCalendarMacro before you did all the work to bring it up to its present state, was very poorly maintained for a long time, so I don't think you should feel bad about replacing it with your very well maintained macro! I'd consider such a replacement to be a great advantage.

Another thought I had initially was that, maybe two macros would be preferred, but perhaps they can share some common code base if a plugin was made? The other alternative, which I think you were describing, is to merge the features of the two macros into a single macro. I'd be interested to know if you think the former is a possibility, since it might feed into another idea I have for another plugin ...

I have some similar ideas for bundling together a set of macros that perform queries on Trac. I'm still working out a proposal for this and its a long-term project, but what I have so far is on QuerySystemPlugin? page.

The central idea I had is that there are a collection of macros that many people would want because they represent a natural extension to an existing Trac macro (TicketQuery in the case of the QuerySystemPlugin? proposal). Rather than downloading and installing 5+ macros that were written by different authors, have a plugin that - installs all of these, provides a set of macros with a consistent use of permission checks, and allow each macro in the plugin to be disabled via Trac.ini if the admin doesn't want that particular functionality.

Just thought I'd toss that idea out there.

Replying to rjollos:

Thanks for the work triaging those!

You're welcome.

The WikiCalendarMacro ... was very poorly maintained for a long time, so I don't think you should feel bad about replacing it with your very well maintained macro! ...

Well, certainly there is an advantage by throwing in all the experience gained within the last months in WikiTicketCalendarMacro development.

Another thought I had initially was that, maybe two macros would be preferred, but perhaps they can share some common code base if a plugin was made? The other alternative, which I think you were describing, is to merge the features of the two macros into a single macro. I'd be interested to know if you think the former is a possibility, since it might feed into another idea I have for another plugin ...

Oh, yes. There's of course the possibility to have several macros in one, even in the single file AFAIK. And preserving the macro name would give best backwards-compatibility with existing content, no need to change a single wiki page on update. So forget about the other way, was thinking just too complicated. WikiTicketCalendarMacro code is already modularized, this would be just another step.

I have some similar ideas for bundling together a set of macros that perform queries on Trac. I'm still working out a proposal for this and its a long-term project, but what I have so far is on QuerySystemPlugin? page.

Hey, a macro collection, what a nice idea! The install-one-get-five effect gets +1 from me, definitely a good thing to do. So go, buy the glue to bring them together. ;-)

(In [9637]) WikiTicketCalendarMacro: Split plugin/macro code into several modules, refs #7564.

(In [9668]) WikiCalendarMacro: Pulling trunk in from WikiTicketCalendarMacro, refs #7564.

After separate development for some years lines of these plugins are crossing again, as I do aim at bundling both to join the best from both branches.

Next step is to incorporate WikiCalendarMacro functionality. So let's move this ticket over there.

Afterwards we'll follow with all the other stuff: remaining tickets and wiki docs for WikiTicketCalendarMacro, maybe more repository cleanup/merging, moving old stable releases for WikiTicketCalendarMacro into a named branch in WikiCalendarMacro repo space, ...

(In [10203]) WikiCalendarMacro: Merge in WikiCalendarMacro code for a combined release, refs #7564.

This is by no means an atomic changeset but a huge, crazy code clash. Both macros had rather different approaches regarding class definitions for CSS styles, so I had to partially change core logic to allow the creation of some WikiCalendar specific HTML tags. While the CSS changes are not final, the first goal of a regression-free product is reached, or at least close enough for the visual presentation of both macros.

Short summary of changes:

• include full embedded macro documentation for WikiCalendar
• use 3-section-navigation from WikiTicketCalendar with both calendars now
• combine CSS style definitions
  • remove dedicated subfolder 'css' from htdocs - too much for just on file
  • move CSS namespace wikiTicketCalendar to wikitcalendar
  • reuse/merge identical/similar definitions, unify CSS class names (started)
• some lessons learned from WikiCalendar styling
  • move formatting from HTML to CSS (started, day numbers and subpages)
  • use multiple classes per HTML tag (started with day numbers)
• fix an overwrite of marco name in milestone code

(In [11557]) WikiCalendarMacro: Try header localization according to user pref, refs #7564 and #9568.

Calendar headers are localized according to user preference, if the server has suitable locales installed. Unrelated micro-improvement: CSS tooltip text is slightly magnified now.

That latest improvement has been tested exclusively on a GNU/Linux system. You'll need the requested locales installed on your server. Here is my rather extensive setup:

$> locale -a
C
de_DE@euro
de_DE.iso885915@euro
de_DE.utf8
en_GB.utf8
en_HK
en_HK.iso88591
ja_JP.utf8
POSIX
ru_RU.utf8
zh_CN.utf8
zh_TW.utf8

Due to known issues with locale support in Python testing, especially on Mac and Windows systems, is pretty much welcome.

(In [11748]) WikiCalendarMacro: Add wiki page template preselection to WikiCalendarMacro too, refs #7564.

After reading the wiki documentation lately it looked like a regression, that the keyword argument base was missing from WikiCalendarMacro.

(In [11749]) WikiCalendarMacro: Add WikiTicketCalendarMacro options to wikicalendar section, refs #7564.

If a wikicalendar configuration section is found, all options from the old, now depreciated wikiticketcalendar section get overwritten internally.

You may want to rename the old section, and the required option name change ticket.due_field.name --> ticket.due_field.name will be done automatically.

(In [11800]) WikiCalendarMacro: Fix regression introduced in [11749], refs #7564.

Moving from wikiticketcalendar towards wikicalendar config section I forgot to modify the second place with independent access to configuration: WikiCalendarTicketProvider.

(In [12841]) WikiCalendarMacro: Move and tag old singe-file macro version, refs #7564.

(In [12842]) WikiCalendarMacro: Releasing current, tested macro package as final product, closes #64, #578, #6636, #7564, #7653, #8818, #9568, #9718 and #9719.

After a long time one of the oldest Trac hacks (see changeset [53]) is united with its ambitious fork WikiTicketCalendarMacro for convenience. While maintaining separate wiki pages for both macros, upstream development continues together in the source:wikicalendarmacro/trunk branch.