On Sun, Jul 25, 2010 at 7:39 AM, Michael Richter <ttmrich...@gmail.com>wrote:
> Looking more into the skinning issue, it looks to me like the file skins.c
> contains a bunch of stuff that could be generated trivially from a script of
> some sort. Is there any interest in me making the skinning system more
> flexible so it's easier to add a new skin by basically just checking in
> three files under a new directory? The idea would be something like this:
>
> <fossil source root>
> | ...
> +- skins
> | |
> | +- skinname1
> | | |
> | | +- skininfo.txt
> | | |
> | | +- style.css
> | | |
> | | +- header.html
> | | |
> | | +- footer.html
> | |
> | +- skinname2
> | ...
>
> Then inside src would be a utility like translate that walks over all the
> subdirectories of ./skins, grabs the explanatory information from
> skininfo.txt, grabs the style, header and footer code and builds skins.c
> exactly as it is now (but with more skins, naturally) before translate is
> run on it and fossil as a whole is built.
>
Please do so.
If the translator is written in C (ex: translate.c, makeheaders.c,
mkindex.c) then that would be best. Simply integrate the translator into
the makefile. If the translator requires a script language, which might not
be installed on the target machine, than arrange for the translator to be
run separately and the output file (skinsdata.c?) checked in to the Fossil
repository, just as the "makemake.tcl" script generates the "main.mk"
makefile.
Fossil already links against zlib. So you might as well compress the
content and store it as
an array of unsigned chars. That will help keep the standalone executable
smaller as we accumulate more skins.
For development purposes, it would be nice to have a command-line option to
force the use of one of your skin folders:
fossil server -skin skins/test-skin-one
That way, designers could edit the CSS, header, and footer files in the
specified directory and immediately see the result simply by clicking the
"Reload" button on their browser, without having to go through a recompile
process.
Another idea would be to write a read-only virtual table for SQLite that
allowed us to read the skins using SQL statements. That way, the
user-defined skins stored in the repository database and the built-in skins
compiled into the code could be managed all by the same SQL statements in
the display logic.
Please check-in your changes into a branch for the time being. We'll move
them over to the trunk once we settle on a final solution - we'll probably
need to iterate a few times first.
>
> The advantage to this system is that people can add new skins easily,
> without any C hacking, by simply providing four files under a subdirectory
> of ./skins:
>
> - skininfo.txt provides the name of the skin, a brief description and
> (optionally) the name of the author.
> - style.css, header.html and footer.html just do what their respective
> sections in skins.c do.
>
> A further advantage is that people unfamiliar with C won't accidentally
> insert subtle, hard-to-catch bugs.
>
> --
> "Perhaps people don't believe this, but throughout all of the discussions
> of entering China our focus has really been what's best for the Chinese
> people. It's not been about our revenue or profit or whatnot."
> --Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra.
>
> _______________________________________________
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
>
--
---------------------
D. Richard Hipp
d...@sqlite.org
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
