Warning: long post, read carefully 
In the past I thought of rewritting it, but for integrating help files (CHM, HTML, HTB) inside C::B. However after some experimentations it turned out that wxHtml is not suited for the task, it doesn't know anything about CCS and complex HTML, so it could open only HTB files, not CHM, nor any other type.
I happen to working on precisely that. What's so wrong about only HTB being opened inside C::B? It's platform agnostic. Having it working seamlessly inside C::B would both promote the format and give C::B a robust cross-platform help system.
It's almost ok, but there are two problems: there are little few books on this format. All of them can be getted from
http://htmlhelp.berlios.de/books/htb.php(I note the ones we could use: wxwidgets, libstdc++, gdb, gcc, make).
The other problem is that all the rendering through wxHtml is html in very basic form. That means for example, that the C::B SDK documentation is out (doxygen/doxys can't generate html
so basic to work on wxHtml).
In case you want, I have an implementation of wxHelpController that can be embedded in a window, so the help can be rendered in a C::B EditorBase instead of an outside window. However I think that an external window option should exist, some users couldn't like having the help embedded in C::B.
As you may know, wxHelpController can only open in it's own renderer HTB files, not CHM, nor any other.
But my goals (wishes) for the plugin was/are:
-HTB support
-CHM support
-HTML support (local files and online)
-DevHelp support (it's popular enough on linux)
-PDF support
-Man pages support
-Info pages supportNow, one by one:
-HTB support: This should be the most easy to implement, and also the most likely to have first (if any).
It will requiere to use the reimplemented wxHelpController I have and adapting it so the embedded/external option can exist.
-CHM support: This is one of the most important for me, because there's plenty of free CHM books everywhere. It's very comfortable to use it.
Now, the problem relies on that CHM is a MS format. But fortunately it's already reverse enginered, and it exists a program called wxCHM which uses that library. It was programmed for Linux only, but some months ago a Mac port appeared. There isn't in Windows as the author wasn't interested (with rights, if Windows can read CHM natively
).
But I took the source and after some (heavy?) modifications, I could compile it, and finally run it on Windows, with very few glitches.
But then I discovered: wxCHM uses as render wxHtml, and kinda reimplements all the wxHelpController window interface.
Which is not good (using wxHtml as render), because most (almost all) CHM books out there uses CSS and HTML code that wxHtml can't cope with.
However, wxCHM have pieces of code that can be used without problem.
-HTML support: This is were I left frustrated. HTML is the most important format for obvious reasons. wxHtml can't render almost any page online well. And almost all API documentations have an HTML (downloadable or online) version.
And here the choices are very little: wxMozilla (Windows, Linux), wxIE (Windows), and wxSomethingMac (Mac, can't remember it's name).
The choice I would made would be wxMozilla, but it seems that it doesn't work well on Mac yet.
Using different APIs, like using wxMozilla in linux, wxIE on windows and wxSomethingMac on mac could be done, but writting for 3 different APIs to do the same thing, I don't know if it's worth the effort.
But the single most important problem I have with wxMozilla (which uses an embedded gecko) is the huge (relative) dependacy it will add. It will take a lot of resources regarding compile time and executable size, which I couldn't decide if it was the effort or not.
So I gave up at that point on this matter.
-DevHelp: It's a CHM-like format but OpenSource, used mostly for Linux APIs. Not my priority, but something to have in mind.
-PDF support: Probably a though one, not easy to do, unless there is a wx PDF friendly library.
I think the best approach here would be the same as is now: calling Acrobat Reader or whatever, because there are almost always PDF readers installed on any platforms, so it
shouldn't be a concern like the other formats (except HTML), that are available most of times in only one platform.
So not important for now.
-Man pages and Info pages support: This is low on the priority list also. But given the simple these formats are, we could write a parser for them that displays them in the HTML window. Note that I've spent a lot of time searching for
any Man or Info pages reader for windows, but there is nothing (yes I was surprised to know that, but no, there isn't a man nor info win32 port yet, neither any other program can open them).
Well, that's enough. My conclusions are that the single most important problem right now is wxHtml incompetence. And I've reading some wx-devel lists saying that everyone is aware of the poor render of wxHTML, and that they were looking for using already existant implementations at some future (even with more than one backend in the same platform).
If you ask me, I think the best implementation wxHtml could have is reimplementing all the KHTML API, which is a
lot lightweight than Mozilla. And it's the first and only (yet) OpenSource implementation to pass the CSS Acid2 test.
Hope that adds a bit (
) of info on the matter.
PS: Do you think this should be in the Wiki?
Regards,
Takeshi Miya
