Author Topic: Help bug (may be)  (Read 15925 times)

takeshimiya

  • Guest
Re: Help bug (may be)
« Reply #15 on: February 19, 2006, 07:46:16 pm »
20 help items aren't unreasonable. You've obviously not used something like Documancer before.

Never assume anything. :wink:

Offline Game_Ender

  • Lives here!
  • ****
  • Posts: 551
Re: Help bug (may be)
« Reply #16 on: February 19, 2006, 10:54:41 pm »
Never assume anything. :wink:
...and you code will be more extensible, robust, and long lasting.

takeshimiya

  • Guest
Re: Help bug (may be)
« Reply #17 on: February 20, 2006, 03:40:40 am »
Never assume anything. :wink:
...and you code will be more extensible, robust, and long lasting.

I agree with Thomas that it doesn't make sense rewrite the plugin only for that.

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.
The only real solution was to use wxMozilla or wxIE (in Windows), but it'll add a huge dependency. I don't discard it yet, but that dependency kinda turned me off.

Offline AkiraDev

  • Multiple posting newcomer
  • *
  • Posts: 71
Re: Help bug (may be)
« Reply #18 on: February 20, 2006, 09:51:05 am »
Quote
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.

takeshimiya

  • Guest
Re: Help bug (may be)
« Reply #19 on: February 20, 2006, 01:17:03 pm »
Warning: long post, read carefully :P

Quote
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 support


Now, 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. :D

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 (:D) of info on the matter.

PS: Do you think this should be in the Wiki?

Regards,
Takeshi Miya
« Last Edit: February 20, 2006, 01:24:34 pm by Takeshi Miya »

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: Help bug (may be)
« Reply #20 on: February 20, 2006, 04:38:05 pm »
To explain why I called adding more than 20 items "unreasonable" in the first place, look at what you get when you right click in the editor:



I have only 5 help files listed, now imagine there were 30... the menu would fill the entire screen! Maybe you feel differently, but to me, having many choices is not a good thing.

Anything beyond 5-6 choices starts getting irritable, and anything beyond 10 will start to seriously hinder your work.

Of course if you never right-click in the editor (and use "Find declaration/implementation", for example), then this does not matter an awful lot. :lol:
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline duncanka

  • Multiple posting newcomer
  • *
  • Posts: 53
Re: Help bug (may be)
« Reply #21 on: February 20, 2006, 06:39:27 pm »
To explain why I called adding more than 20 items "unreasonable" in the first place, look at what you get when you right click in the editor:

...

On that subject :)...why is this not done using a submenu?  The Export functions had the same problem, so they were (quite sensibly, IMHO) switched to a submenu in the File menu.

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: Help bug (may be)
« Reply #22 on: February 20, 2006, 07:22:55 pm »
That would at least prevent excessive pollution of the main popup :)

Makes the lookup function yet more complicated, though.
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

takeshimiya

  • Guest
Re: Help bug (may be)
« Reply #23 on: February 21, 2006, 09:16:46 am »
That would at least prevent excessive pollution of the main popup :)

Makes the lookup function yet more complicated, though.

I thought the same when I requested the "uncluttering the contextual menu" some months ago.

The best solution I'm thinking right now is put an option to change between both, which defaults to like it's now, but power users can choose to become it a submenu.

Anyways, it looks like a natural thing with the ActionsManager. :)

takeshimiya

  • Guest