Daniel Egger wrote:
Am Mon, 2003-07-21 um 17.23 schrieb Sven Neumann:
You want us to include an XML renderer in the help-browser? That
doesn't sound like a simple solution.
Why not? Why should DocBook be more difficult to render than HTML? It doesn't necessarily have to be a DocBook renderer, it could also be a live translator. Maybe we can utilize yelp for it?
What is tricky about 'xsltproc $xmlfile > $htmlfile'? OK, I have to
admit I don't much experience with the DocBook XML issues you
encountered when working on gimp-help but since I played with this
stuff for developer.gimp.org I cannot follow this argument. Perhaps
I need to take a closer look at gimp-help2 first...
The problem is that once you created the HTML, it's fixed including the
filenames because the links point to it. Getting <insert your favourite
xslt processor here> to spit out HTML files with the "correct" names in
the granularity we want is close to impossible; I had to reorder
gimp-help quite a bit to make it possible at all. Your
developer.gimp.org experience is probably limited to either one single
HTML file or files whose names don't matter except for index.html.
However at the moment we need the filenames because the help browser
picks up the files by loading a prespecified path.
This scheme is not only hard to maintain but also broken by design; I'm
quite confident there are still mislinked help files and we didn't
notice in GIMP 1.2.
the attribute rewritter that we used on mgo is the easiest way to keep all of the urls straight that i found. this is not me saying it is easy, it is me saying it is easiest.
i spent some quality time with docbook; olink, ulink and kin. docbook was not written for gimp. Not the gimp as i understand it at least.
gimp should write his own documentation. shoot, if we write the dtd properly, gimp can write his own docbook; i will not
- The docs need to be kept in sync with the GIMP Source which is a
tedious work.
volunteer to write the layout for this however, as i am old and my life is already too short. gimp does not slide easily
into docbook. but spewing xml from one place to another is easy stuff. at least Helvetix made it seem so, and i have not
scared him away yet, as near as i can see.
perhaps the wiki is already up and working for this sort of thing. or, maybe you would rather get some space on sourcforge
How would your solution avoid this problem?
Instead of specifying filenames in the GIMP XML entities are specified to reference the wanted section. So both the help internally AND the GIMP are using exactly the same mapping to the files thereby avoiding annoying synchronisation problems.
Also the documentation can be shipped *as is* without risking wreckage every time the stylesheets or the processor or the GIMP or the content changes.
But I would perhaps make sense to setup the framework and encourage
people to contribute help for gimp-2.0.
Good idea.
or yahoo.
Eeek on a wiki is easier to read than in your software. I had a hard time seeing gimp-1.2 help, as i did not want to run the
We could setup some text that is displayed for all missing pages
and that explicitely encourages people to write help on this topic.
Didn't work for GIMP 1.2 so I doubt it will here. We haven't received a single contribution for the help in whatever form; maybe the "Eek" scared people off or something...
full browser and never managed to have all of the pieces together
to build the gtk browser.
When i looked at what you were doing to try to contribute, I looked at the sgml template and all sense of reason and purpose escaped me. I don't think it was prof and syngin, i think it was terrible terrible sgml markup.
I feel like what i must wait until after camp to work on was answering all of these troubles. If I am somewhat incoherent at times, I can very easily blame trying to fit what I know into crappy templates that were not made with what i know in mind.
My plugin template was made to get information from the registry of the plugin and use it on a web page. It can be used in a help document also.
I cannot do this alone though. Seriously, if I am incoherent about this stuff, there is a good chance that the review of the current software caused this. I blame docbook. And docbook was better than sgml. help!
carol
