[dokuwiki] Re: Plugin and Theme integration
- From: Michael Klier <chi@xxxxxxxxxxx>
- To: dokuwiki@xxxxxxxxxxxxx
- Date: Wed, 28 Feb 2007 14:04:56 +0100
Martin Gill wrote:
> Actually, the problem here is that some plugins (e.g. notes) define their
> own colours and there's no easy central way to deal with those changes.
>
> If all colours were stored in the same manner (e.g. a php array/map) then
> it would be possible to edit this map via the wiki, or even just have a
> "final" config file in the config folder that would override values.
>
> E.g. Notes has a bright red colour defined as colors['note1']. I want a
> dark red, so all i need to do is read up in notes what colours it sets,
> and then add colors['note1'] to my override config and change the value
> before it's used. And yes, a local.style.ini could be used here for this.
>
> No need to edit or merge files, hunt around for the files. Just replace
> the value with a new one.
FWIK there are only a few plugins where custom colors come into play
(notes/box can`t remember the other ones ;-)) the way you mean. And
regardless of using your method or the style.ini way, in the end you
have the same problem, there`s actually no way to force plugin/template
authors to use these systems (which makes a style manager rather
useless). So IMHO, introducing another method would simply change
nothing to the situation. I understand your point of view, it`s hard for
users without CSS knowledge to customize the style of the wiki or to
even find the place where to make changes and it would be much more
end-user friendly to have an admin plugin doing that.
And in regards to the admin plugin: You would be able to see which
colors belong to which plugin. But, you don`t know what part of the
plugin CSS is affected, which would be desirable IMO. That would require
some sort of style metadata provided by the plugin to make it work with
a style manager (not thinking about translations a.s.o), which then
would make developing the plugin CSS even more complicated. Per plugin
style.ini sounds feasible, and integrating that won`t be that hard,
_but_ then there should be some sort of "best practise" guidelines for
plugin developers (note to self: needs to be updated in the wiki), to
make them use semantic names for their own replacments and using the
default template replacments whenever possible (that still won`t keep
them from not following them though ;-)).
Just my 2c
Best Regards
Michi
--
Michael Klier
mail: chi@xxxxxxxxxxx
www: http://www.chimeric.de
icq: 206179334
jabber: chi@xxxxxxxxxxxxx
key: http://downloads.chimeric.de/chi.asc
key-id: 0x8308F551
Other related posts:
