Wireshark-dev: Re: [Wireshark-dev] Win32: The best way to solve dependencies for user-guide.chm
Sebastien Tandel wrote:
hmmm ... IMHO, if you want to keep "things simple as much as possible
for newbie developer", it's better to let people download the html user
guide and they won't need an internet connection either.
Ok, one step back:
It's about having "Help" buttons at the appropriate places in the
dialogs, which will open the appropriate help page AUTOMATICALLY and
without any further user installation/configuration. The setup should
install the help content, without any additional user intervention -
that's the first and primary goal!!! --- Which is already implemented,
but currently switched off.
The download method you'll suggest will end up in: You'll have to
explain our users where to get these docs, where to unzip these files
into so the Wireshark help system find these docs and so on. Hmm, not
very user friendly in my eyes - and I guess only very few people actual
do it.
It's basically about making it more probable that user's actually use
the help content. I know that there's need to improve the User's Guide,
but that's a different story, too long to be told here ...
Why this wish of distinction between unix/win32 platforms with
.chm/.html?(sorry if there was already a discussion about that)
The .chm file is the "natural" Win32 way (look-and-feel) to do this -
opening a web browser is only the second best choice. In fact the .chm
way has even one big advantage in the everyday life:
If you open several help topics with the browser/html method, you'll end
up in a lot of open browser tabs/windows - that's annoying, but I don't
know a way to prevent this.
The .chm file help viewer just opens the new page in the same viewer -
which is usually what you want to have. BTW: It's this calling of the
help viewer from within WS that requires the htmlhelp.c / .lib.
I think the HTML based help systems of KDE and/or GNOME do it in a
similar way - a tighter integration of WS with these desktop
environments would be good as well - unfortunately I don't see anyone
going to implement it.
Regards, ULFL
