On 5/29/06, cedric GEMY <radar.map35@...8...> wrote:

Working in SVG can be a good point for many examples we could use in manual or tutorials. But in this case, if we want to show a screenshot of a windows for example, we should embed it in a SVG file. Why not.

Let the user choose is not necessarly the best. Is a user wants some help, he don't want to spens time to understand how the help browser works ;)

I think we should do the choice for him, at least by default; Advanced user could change.

That's right, I can handle it. You should be warned, however, that as far as I know, there are two practical ways of embedding html in a custom component. One is through mozilla gtkmozembed and the other is gtkhtml; both would represent additional dependencies.

Actually, i was going this way by the knowledge i get from my Gimp

Manual contribution. We (I and Roman Joost) were trying to have a common approach to simplify actions for contributors and to make it easier to contribute. Yep, documenting is also a long and hard job.

Yes, I agree.

Moving xsl processing to the program sounds great to me.

How could i try your browser ? I could give you feedback on how i could

use it ans may work together on it, this way.

No problem. The biggest trouble I foreesee right now is the part of compiling the cpp code, I'm not that good with Automake, so I will provide two short shell-scripts for compiling and linking, until something better can be done.

About Yelp, i'm not sure it is available for windows. But i'm sure it is

using GTK libraries, so that they will be necessary even on KDE. How is build yours.

Cedric (IRC = pygmee)

As I noted earlier, the program is made using pygtk, a GTK binding for Python. Inkscape is already (strongly) dependent on Gtk, and almost on Python, but pygtk would be another dependency (perhaps the help browser can be kept as an optional part, too). Then a few lines of C++ code make possible the interaction of python+gtk with the Inkscape svg viewer widget. All that can be re-coded completely in C++, but that difficults development a lot, and would end up in poorer results for the same ammount of work. Content info is represented by a tree, which nodes are added to that tree from Contributor objects. Each node encapsulates a key, the title of the document, an uri, the see-also stuff and a list of keyword phrases for indexing. Contributor objects are responsible of gathering entries from different sources. So, a Contributor might know about the tutorials, and other Contributor might be responsabilized of scanning the extensions directory for documentation of individual extensions.