Modify

Opened 4 years ago

Closed 17 months ago

#7564 closed task (fixed)

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

Reported by: rjollos Owned by: hasienda
Priority: normal Component: WikiCalendarMacro
Severity: normal Keywords: migration
Cc: rjollos Trac Release: 0.11

Description (last modified by rjollos)

I had previously adopted both the WikiCalendarMacro and WikiTicketCalendarMacro. Seeing as how hasienda did such a nice job with this macro, I wonder if it is even worth having the WikiCalendarMacro, which appears to represent just a subset of the functionality.

There are several open bugs for the WikiCalendarMacro: /query?status=!closed&component=WikiCalendarMacro&order=priority

Considering the possibility of just removing the WikiCalendarMacro page and redirecting to WikiTicketCalendarMacro ... comments?

Attachments (0)

Change History (18)

comment:1 Changed 4 years ago by rjollos

  • Description modified (diff)

comment:2 Changed 4 years ago by hasienda

  • Keywords miniature mode added
  • Type changed from defect to task

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.

comment:3 Changed 4 years ago by hasienda

  • Summary changed from Is there any point to having the WikiCalendarMacro as well to Research and work towards incorporation of WikiCalendarMacro features

comment:4 follow-up: Changed 4 years ago by 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.

comment:5 in reply to: ↑ 4 ; follow-up: Changed 4 years ago by rjollos

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.

comment:6 in reply to: ↑ 5 Changed 4 years ago by hasienda

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. ;-)

comment:7 Changed 4 years ago by rjollos

  • Cc rjollos added; hasienda removed
  • Owner changed from rjollos to hasienda

comment:8 Changed 4 years ago by hasienda

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

comment:9 Changed 4 years ago by hasienda

(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.

comment:10 Changed 4 years ago by hasienda

  • Component changed from WikiTicketCalendarMacro to WikiCalendarMacro
  • Keywords migration added; miniature mode removed
  • Status changed from new to assigned
  • Summary changed from Research and work towards incorporation of WikiCalendarMacro features to Integrate re-worked WikiCalendarMacro in new trunk (based on WikiTicketCalendarMacro)

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, ...

comment:11 Changed 3 years ago by hasienda

(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

comment:12 Changed 2 years ago by hasienda

(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.

comment:13 Changed 2 years ago by hasienda

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.

comment:14 Changed 2 years ago by hasienda

(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.

comment:15 Changed 2 years ago by hasienda

(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.

comment:16 Changed 2 years ago by hasienda

(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.

comment:17 Changed 17 months ago by hasienda

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

comment:18 Changed 17 months ago by hasienda

  • Resolution set to fixed
  • Status changed from assigned to closed

(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.

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'reopened'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.