On 11/6/12, Peter Koželj <[email protected]> wrote:
> Hi,
>
:)
> I would need to add some white-labeling support to Bloodhound. At the same
> time I would also use the feature to change or remove some of the Trac
> references throughout the application. The credits to the Trac and relation
> description between Bloodhound and Trac needs to stay but there are
> numerous points where Trac references serve no real purpose but to
> potentially confuse new users. So this is I plan of what I intend to do or
> is at least worth discussing:
>
> 1. Add ability to rename Bloodhound label in ui by changing configuration
> file (white-labeling equivalent of i18n file) This same configuration would
> be used for replacing Trac references where we would see fit. Personally I
> would only leave the reference to Trac in Apps/About Bloodhound
>
Why not just sections in trac.ini itself rather than a separate file ?
Having many config files/sources will make things a bit difficult ...
afaics . In the end there should always a way to make such configs fit
into INI file structure .
> 2. Use the configuration for labeling in generated content (email
> notifications) configurable
>
What are the options available now to get similar things done ?
> 3. Make footer text configurable by the same configuration file
>
This is possible already by editing trac.ini
[project]
footer = Lucy in the Sky with Diamonds
afaicr installer script customizes the footer in default installations
, but /me not sure .
> 4. Trac version is referenced on all pages, as already said it should be
> removed or moved to About page. Code wise references to Trac version happen
> on multiple places, sometimes to hardcoded Trac version sometiemes to a
> “calculated” one. We need to fix that.
>
We need to handle this in a consistent manner . Could you please
mention examples ?
> 5. Various readme files reference Trac as dependencies. This should be
> examined more closely. Given that forked Trac version is bundled with BH it
> seems that any dependencies on Trac as external project are not only
> unnecessary but actually wrong! There is no white labeling features planned
> for this
I thought we were already stating that we distribute a custom copy of
Trac , with references to the exact Trac version (relative to svn
repos) incorporated into vendor branch .
> 6. Plugins Kindly ask all plugin authors to take advantage of the new
> white-labeling configuration file if it exists, offer white-labling feature
> back to Trac.
>
IMO that request should be addressed to end users ... but maybe I'm
missing something .
> 7. Documentation (wiki) is full of Trac references,
Yes , Trac-devs did the whole thing
;)
> pages themselves
> contain "Trac" in there name and in addition to that many of the links
> contain "Trac" in text as well. And all of this very inconsistent applied.
>
We envisioned to migrate default wiki pages onto Guide/ folder (see #85)
> But there is an even bigger issue with documentation. With BH gaining new
> features the Trac documentation will be less and less relevant and may even
> become misleading at some point.
If we will evolve together with Trac then for a reasonable time a
relevant % of the Trac guide will be valid .
> I would at least remove "Trac" in links
> until Trac documentation is replaced by Bloodhound documentation
>
> We could also remove "Trac" from the wiki page names. In fact there is some
> code in bloodhound_dashboard/bhdashboard/admin.py
> that implies that somebody was already thinking along that lines. Can
> someone elaborate?
#85 ;)
> 8. Some of the Trac references appear in the names of the tools and
> programming constructs of the Trac itself.
> These do not need to be white-labeled but it would be nice if we could
> rename them more neutrally. This include:
>
> o TRAC_ADMIN premission
Hard to modify as references to this permission name are scattered all
over trac and plugins code .
> o trac-admin CLI command
> o cleartracd CLI command
yep
> o error handling: TracError is displayed in error report that user sees
>
This one could be «solved» by adding in trac.core something like
{{{
#!py
class NewNameError(Exception):
... TracError code
TracError = NewNameError
}}}
--
Regards,
Olemis.
Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/
Featured article:
