osimons wrote:
On Mar 26, 7:29 pm, Noah Kantrowitz <[EMAIL PROTECTED]> wrote:So it appears I have been out-voted on this, so I will return to using the previous loadpaths hack for theming. This does come at a cost though, we need (for whatever definition of "need" we normally use for in-version API stability) to not change the data structures passed to layout.html. I will try to set things up in ThemeEngine to make it transparent when we re-split layout/theme. --NoahI see the need for a themeing hook, but wonder if we could somehow scale it down? I too use styles, but without some support I'm forced to put my <py:def>'s in a common site.html, and make sure to delete all the site.html files in new projects - if not they will of course be picked first in the loadpath. It would be really nice for a plugin to provide a theme.html to add custom look definitions. What if we reverted (moved things back in layout.html and macros.html), but kept the theme.html include in layout.html without such a file being provided by Trac? That should mean no worries for default installations, but a possibility for plugins to provide custom <py:def>'s in a theme.html to manipulate layout?
For anything beyond trivial themes this would be unhelpful. You would first need to undo the chrome elements added by default (navbars, etc) and then readd them yourself. This would make things even slower.
--Noah
signature.asc
Description: OpenPGP digital signature
