Re: ANNOUCE: gTrouble - New project [summary]
- From: Miguel de Icaza <miguel nuclecu unam mx>
- To: Tom Gilbert <gilbertt tomgilbert freeserve co uk>
- Cc: Gnome list <gnome-list gnome org>
- Subject: Re: ANNOUCE: gTrouble - New project [summary]
- Date: 24 Sep 1999 12:54:18 -0500
> o Would it be desirable for the Gnome2 help-browser to read DocBook sgml
> directly? Is this a useful feature, or just a gimmick? (It would
> simplify the compilation/installation of help).
It would be lovely.
Personally, I think we should use a subset (if I understand correctly,
this is just a matter of making the SGML "correct") that is compatible
with an XML parser.
So, I would like to see something that can render DocBook in graphics
mode and hopefully in text mode too. For example, Solaris 7 man pages
are in DocBook format.
> o Although the help-browser would provide an interface to both types
> of help, should/could the two types of data be integrated?
> Should app-developers write one sgml file including both types of
> help, or should the interactive help be stored separately from the
> plain html help?
I would keep two sets of files. Because the "gtrouble" files would
contain the perl (or the test code you thought about), and they could
just link to each other.
> Or should we create a library for the rendering of the xml, and the
> running of built-in tests, and allow other environments to use this?
> How far do we go? Is this worthwhile?
I think that by splitting the "parser" for this stuff from the actual
visual representation we would be able to deliver the GUI and text
mode editions of this tool by using different front ends.
I personally like this idea a lot.
And I also believe that creating such infrastructure is *key* to the
future of Free Unix systems. We had discussed something like this
before, but because we lacked the time, it was left on the "things to
do" folder.
> (I really want to supply a library of tests for guide-writers, its much
> easier to check the existance of a file / query an rpm automatically
> than ask user to go looking for it. Others may think this is not a
> necessary feature.)
I sustain that Perl would be a better replacement.
> Please send guidance! These are my new goals (possibly over-optimistic)
i am over optimistics ;-).
--
miguel@gnu.org
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]