Re: ANNOUCE: gTrouble - New project [summary]



Well I should probably summarize the discussion so far, and thank
people for all the feedback.

There are still a couple of things I'm not clear on.

The first thing is to mention the most common type of feedback - why
not use xml, and take advantage of libxml.
If people feel this is the right idea, then that's fine. I must
reiterate that sgml/xml are not subjects in which  I am knowlegable.
I picked sgml, 'cos that's what DocBook uses, and its familiar to me
through writing help for my apps. Having read up on xml/sgml, I have
to agree that xml is perfect for my needs, and I would have little use
for the greater breadth of sgml.

The second thing is not to restrict to just troubleshooting, but to
encompass any kind of interactivity, such as howtos. This was the
original intention, I just didn't explain it well.

The third thing is the gnome-help-browser. I had and still have _no_
intention of modifying the existing codebase. This was the reason my
announcement was initially for a separate app. I did not consider
Gnome2, or creating a new help-browser, but am thinking about it now.
On this subject, some questions:

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).
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 like the idea of separate files. DocBook for plain help, xml for
  interactive help.

So would it be helpful for us to create an xml syntax/dtd for
interactive help, which other programs/environments to use, and create
an interface to it in the new help-browser?
Is there an existing syntax we can use without restricting
flexibility. (Don't forget my previous example was most basic).

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 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'm keen to write code. I see a real gap here, which I feel needs
filling. I lack experience with markup languages, and need guidance in
this respect, I initially only thought about sgml as a file format for
storing instructions in, but I'm now thinking it should be more than
that, but unsure how this should be done.

Please send guidance! These are my new goals (possibly over-optimistic)

General:
o Available to non-Gnome environments
o Easy syntax for guide-writers
o Flexible, with built-in functions/tests
o Accessible from gnome-help-browser-2
o Possibly separate from conventional help, in xml format?
o Self contained files, seperated on a per-app or per-topic basis.

Finer details:
o Persistance of answers between guides
o Reference to earlier answers to determine actions.
o Feedback to developers if certain conditions are satisfied? ie
  sending the results by mail to someone.
o Default guides for common topics (application installation).

o I'll think of more stuff, if folks think I'm making sense so far...

I'm quite surprised noone has suggested the front-end should look like a
little paper-clip in a box ;)

Tom.
-- 
            .-------------------------------------------------------.
    .^.     | Tom Gilbert, England | tom@tomgilbert.freeserve.co.uk |
    /V\     |----------------------| www.tomgilbert.freeserve.co.uk |
   // \\    | Sites I recommend:   `--------------------------------|
  /(   )\   | www.freshmeat.net www.enlightenment.org www.gnome.org |
   ^^-^^    `-------------------------------------------------------'



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]