Hi, Daniel Egger <degger@xxxxxxx> writes: >> The biggest advantage is that we can expect a working >> browser on almost every box that GIMP gets installed to. > > But a browser doesn't necessarily sport the navigation features one > would like to have, or a global find function. Also a browser is meant > for viewing documents on the whole screen while a help browser is > typically used concurrently to the application it tries to help the > user with. You are right but do we really want to depend on the helpbrowser alone? I could live with this but it would mean to drop one of the requirements we set up for the help system until now. Being able to read the help pages using a traditional browser has always been considered a necessity. If we want to get away with that, we should have a good reason. > I'm not mapping filenames (neither XML nor HTML) but entities and or ids > in XML files wherever they might appear. Basically one can add id > attributes to arbitrary tags and use them as crossreference or link > targets. So if you have one file referencing all other files (in the > gimp-help module) specifying entities and then you call those entities > a processor can cache the skeleton of the whole documentation tree and > have all ids in memory thereby knowing where the specified (in GIMP > source) id can be found in the jungle of XML files. This way I can > (re-)structure information however I like and they will be always found. Since XHTML is XML as well we can do the very same thing with HTML pages. Of course the concept I proposed wasn't limited to linking to toplevel HTML pages but it would include a mapping from unique identifiers to anchors in a set of HTML pages. This technique is usually referred to as XLink. > OTOH using filenames which are loaded means that one has to teach the > XML processor exactly how the *output* are to be named which is a > feature which: > a) not all XSLT-processors support > b) works only with a fixed structure because the layout (chapters, > sections, paragraphs) determine where the content will be located; > the choosable filename (in the XML files) is a hint at best where > it should place the HTML files. The XSLT processor would of course also generate the mapping table. Thus the HTML pages can have arbitrary names and can be arranged in an arbitrary directory structure. This structure can also be changed without changing anything in the GIMP. GIMP only points to some ids and uses a simple XML file to map these ids to XLinks into a set of XHTML pages. This mapping is part of gimp-help and thus completely under control of the gimp-help crew and can be generated based on the DocBook/XML sources. Now where is your problem with this concept? >> But of course we don't want to stick to the old system, that is >> not the point. The idea was to make GIMP refer to unique identifiers >> and to have a file that specifies how these identifiers map to HTML >> filenames (and anchors into HTML pages). > > I understand but still think that using that unique identifiers directly > on the XML files is more wise. You obviously did not understand me. > Have you ever tried yelp? If not, please do it... I did but yelp is quite complex and I don't think we have the time and resources to reimplement it as our help-browser. We could of course depend on yelp and use it but it will pull in a whole bunch of other dependencies. Sven
