Research on doing a Plug-in for embedded help in CB
> Question: What's so wrong about only HTB being opened inside C::B?
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 any case, 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.
My goals (wishes) for the plugin was/are:
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 xCHM which uses that library. It was programmed for Linux only, but some months ago a Mac port appeared. There isn't in Windows (on MinGW).
But I took the source and after some (heavy?) modifications, I could compile it, and finally run it on MinGW, with very few glitches. :D
But then I discovered: xCHM 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, xCHM have pieces of code that will help a lot.
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)
- wxWebKitCtrl (Mac)
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 wxWebKitCtrl 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.
DevHelp support
http://developer.imendio.com/wiki/Devhelp
It's a CHM-like format but OpenSource, used mostly for Linux APIs. Not a priority, but something to have in mind.
PDF support
Probably a tough 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).
Conclusions
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, the best thing wxWidgets developers can do with wxHtml, is reimplementing all the KHTML API, which is a lot lightweight than Mozilla. And it's the first and only (yet) OpenSource HTML layout engine to pass the CSS Acid2 test.
-- Takeshi Miya
