[fossil-users] Skins
The skins available in the default build of fossil seem to be mislabelled. When I select the one labelled plain grey, no logo, I get a plain grey theme with a big lighter-grey box that occupies 3/4 of the top (left-aligned) with a logo in the middle. khaki, no logo is what it says on the box. Black white, menu on the left is as well, except it doesn't mention not having a logo. It doesn't have a logo, however. Also, weren't there more skins than these three contributed? Zed Shaw referred to a wedding white that I've seen mentioned before but I'm not seeing it. I'm sure there were others. -- 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
[fossil-users] HTML Wiki but Still [] Links And No verbatim?
I seem to have stumbled onto a logical contradiction in the fossil setup and was wondering if folks could help: 1. Turn HTML wiki markup on in the Admin. Now verbatim and nowiki don't work because everything is HTML. 2. Put some python code in expecting it to get left alone [1,2,3,4]. 3. Find out that, no, fossil still interprets [] as wiki links, even in HTML mode. 4. Check mate! HTML mode doesn't know what verbatim or nowiki is, and [] still work as wiki so you can't put code in your docs. Am I just daft and not seeing how this is done? Basically, if I say it's HTML then please fossil, stop helping me. I can do an a href just fine. Or, even in HTML, let me tell fossil to leave sections alone with nowiki. -- Zed A. Shaw http://zedshaw.com/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Thanks To Peter Krantz for Plain Wedding
On Sun, Jul 25, 2010 at 05:09, Zed A. Shaw zeds...@zedshaw.com wrote: I've tweaked a few little things here and there but overall a very nicely done. Thanks again Peter. A modest contribution. Thank you for creating some of the stuff I have been using over the years. If the markup could be extracted from the Fossil C source I would be happy to clean up some more stuff as well. I am afraid to dive into it in the current form as I have very little experience with C. If themes were self contained in some way (markup fragments, css, images) it would be a lot easier to contribute themes. Regards, Peter ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Skins
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. 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
Re: [fossil-users] Skins
On Sun, Jul 25, 2010 at 13:39, Michael Richter ttmrich...@gmail.com wrote: 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: That would be brilliant! As you say it would allow people like me to contribute without messing up the software itself. Is there a way to move the other markup fragments apart from header and footer to external files as well? /Peter ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Skins
I guess your proposal is related to the ticket I filed here: http://fossil-scm.org/index.html/tktview?name=49395d4e70 Although it looks like the proposal is moving towards a templating system I believe it will make changes easier. Right now people have to submit patches of C code for trivial UI changes. If HTML fragments can be assembled into C files in a pre build step (maybe even the HTML that currently isn't in a skin like the stuff in report.c, attach.c and others) the source would be a lot easier to read. regards, Peter ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Skins
On Sun, Jul 25, 2010 at 7:39 AM, Michael Richter ttmrich...@gmail.comwrote: 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
Re: [fossil-users] Skins
On Sun, Jul 25, 2010 at 07:39:28PM +0800, Michael Richter 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: I think that'd work at first, but just to be clear, this means that you can only change the look of a fossil site by recompiling the binary right? A more useful solution would one that doesn't require a recompile. -- Zed A. Shaw http://zedshaw.com/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Proposed Change To Wiki vs. HTML
Alright so I'm going through the code for wiki_convert and thinking about the problems I've been having with using HTML for wiki, but having that setting bleed into all inputs in the system. I think I have a simple solution, but let me know what people think: 1. The setting to use HTML for the wiki should be constrained by whether anonymous or nobody can input into that area. So even though I check HTML for wiki, if anonymous can input wiki, then wiki syntax is used. 2. In wiki_convert where the renderer.state is being setup, you'd have a flag of something like ANONYMOUS_ALLOWED that'd come from the security system by the caller. 3. That flag would then disable the WIKI_USE_HTML flag if it this flag is set. This would then prevent people from shooting themselves in the foot, and tends to do what people think happens with HTML as wiki. It's assumed that this means, HTML for wiki where it's safe to do HTML. I'd be willing to work up the patch on this if people think that's a good way to do it After that I'd like to make the wiki_convert stop interpreting wiki links when HTML is on. -- Zed A. Shaw http://zedshaw.com/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Proposed Change To Wiki vs. HTML
I really, really do not like the Use-HTML-Wiki switch and I rue the day that I ever allowed that into the code. I have no desire to make the situation worse by making the Use-HTML-Wiki switch even more complicated. What Use-HTML-Wiki really comes down to is yet another wiki mode. Everybody (me included) has their own idea of what markup wiki should follow. Popular requests include Creole and Markdown. It seems to me that the Use-HTML-Wiki flag and the suggested improvements below are really just alternative wiki modes. When I first started writing Fossil, I did not understand how contentious an issue the choice of wiki markup would become In an effort to keep the peace, I am willing to consider enhancements to Fossil that support varying wiki modes, providing that those enhancements are carefully designed and thought out and do not become a pile of confused and discombobulated switches and options that slowly grow by accretion. The formatting options should be easily described on one 8.5x11 piece of paper. Anything more complicated than that is to complicated. A proposal: Five wiki modes: (1) For backwards compatibility, we must support Fossil wiki (including the safe subset of HTML). (2) In addition, some people request unfiltered, pure HTML so that they can edit documents using HTML editors. I proposed to also add formatters for (3) Creole and (4) Markdown. Finally, we add (5) plain text - no markup at all. No further options or modes are permitted. Zero. Nada. For embedded documentation, file that end in .html or .htm are rendered as pure HTML with no interpretation and with no header or footer added. File that end in .wiki are rendered using Fossil wiki. Files that end in .creole or .markdown are rendered using their respective formatters. Files ending in .txt are rendered as plain text. All wiki files and plain text files have the standard headers and footers added. For tickets, wiki, and check-in comments, each repository has global rendering mode setting which defaults to Fossil Wiki but which can be changed to one of Pure HTML (with no [...] interpretation, so slightly different from the current Use-HTML-Wiki flag) or Creole or Markdown or Plain Text. All check-in comments are always rendered using the global rendering mode. Wiki and Tickets are rendered using the global rendering mode, but there are special markups that can be specified once near the top of the document to determine the renderer used for the entire document: creole markdown html plaintext fossilwiki These rendering-mode selection markups can only appear once and must be the first text other than whitespace to appear in the document. It is not possible to include multiple markup styles in the same document. It is not possible to automatically translate from one style to another. The Use-HTML-Wiki flag will go away (to be replaced by the pure-HTML global rendering mode). The document rendering modes are the same for all users, except user will have to have a special permission flag in order to be able to edit pure HTML wiki or tickets. User's without necessary permission will not be allowed to begin editing documents in pure HTML mode and if they try to change the rendering mode as part of their edit, their change will not be accepted. No other modes. No other customization options. No other flags or switches. Will such an enhancement come closer to meeting peoples needs? On Sun, Jul 25, 2010 at 4:43 PM, Zed A. Shaw zeds...@zedshaw.com wrote: Alright so I'm going through the code for wiki_convert and thinking about the problems I've been having with using HTML for wiki, but having that setting bleed into all inputs in the system. I think I have a simple solution, but let me know what people think: 1. The setting to use HTML for the wiki should be constrained by whether anonymous or nobody can input into that area. So even though I check HTML for wiki, if anonymous can input wiki, then wiki syntax is used. 2. In wiki_convert where the renderer.state is being setup, you'd have a flag of something like ANONYMOUS_ALLOWED that'd come from the security system by the caller. 3. That flag would then disable the WIKI_USE_HTML flag if it this flag is set. This would then prevent people from shooting themselves in the foot, and tends to do what people think happens with HTML as wiki. It's assumed that this means, HTML for wiki where it's safe to do HTML. I'd be willing to work up the patch on this if people think that's a good way to do it After that I'd like to make the wiki_convert stop interpreting wiki links when HTML is on. -- Zed A. Shaw http://zedshaw.com/ ___ 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
Re: [fossil-users] Proposed Change To Wiki vs. HTML
On Sun, Jul 25, 2010 at 05:47:56PM -0400, Richard Hipp wrote: For embedded documentation, file that end in .html or .htm are rendered as pure HTML with no interpretation and with no header or footer added. File that end in .wiki are rendered using Fossil wiki. Files that end in .creole or .markdown are rendered using their respective formatters. Files ending in .txt are rendered as plain text. All wiki files and plain text files have the standard headers and footers added. Actually, none of this is necessary if you solve this one simple problem: .html will not have the header and active login state of a user, so I have to use wiki, but wiki then has its own set of problems. So, another proposal is just let me say that .html should get templated and wrapped in the header/footer gear. All these formats then become moot because you can generate html into fossil from them using various publishing tools, and then let fossil style them and put the header and login state on them. Then leave wiki turned on for all the inputs and wiki pages. What you think? .html gets styled? Or, another extension like .thtml? -- Zed A. Shaw http://zedshaw.com/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Proposed Change To Wiki vs. HTML
On Sun, Jul 25, 2010 at 04:13:47PM -0700, Zed A. Shaw wrote: Actually, none of this is necessary if you solve this one simple problem: .html will not have the header and active login state of a user, so I have to use wiki, but wiki then has its own set of problems. Ok, so I've been able to simulate what I'm trying to do, and I really think this solves the problem of all the different wiki formats out there. Take a look at this: http://mongrel2.org/doc/tip/docs/manual/book.wiki Now, that's the mongrel2 book that I've started, but what's important is this is generated from a set of TeX files. TeX isn't a wiki format at all, it's just a typesetting format, but the key is that I'm able to craft a very nice PDF and produce the documentation with one make command. What the above link does is put the documentation into the mongrel2.org site so that it fits the overall setup, and people get their login state links above. Without the ability to craft an html document set and have the fossil look applied, I'd have to jank around with my own headers and try to emulate the existing site. No matter what I did I wouldn't be able to get the login state into the generated html. The significance of this is that you can turn on Wiki just like normal. Leave the wiki format the way it is, but tell people to *user their own site generator* just like I did. They generate the site in whatever the hell they want. TeX, Sphinx, Webby, Dexy, some lame ass perl, Creole, Markdown, Textile who cares. What does matter, is if they put into the /doc/tip and end it with .html (or something similar) then fossil will render it within the fossil site's look, and leave it alone. It's not wiki, it's not html, it's *templated* html. If we had that then you'd have all the problems solved in one smooth move. Wiki stays as is, people who want different wiki generate content, headers get applied along with login state links, and everybody is happy. What you think? -- Zed A. Shaw http://zedshaw.com/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
