Graeme Geldenhuys schrieb:
On 8 February 2012 22:36, Hans-Peter Diettrich wrote:
See my note on the difference between context sensitive help and (offline)
documentation.
"context sensitive help" relates to application help too, not just
source code / framework help.
In our fpGUI based software from work, and most Windows software, if
you are in a edit field in some dialog in your application, and you
press F1, you get show the help for that edit field. This is know as
"context sensitive help" too! Now if that specific edit field doesn't
help it's own help, then normally it defaults to the current dialog
(as a whole) help.
Right, it's up to the GUI designer to add the proper HelpContext(sic!)
to every GUI element, so that F1 can *find* the related information.
It's also up to the designer to *provide* that information. All that for
*every* application, not only for the IDE.
Now from my little experience on Mac OS X, it is nearly as bad as
Linux apps. Also Mac apps think you have a permanent internet
connection, because most offline help is just skeleton help. You need
internet access to get the full help. Again, pointless!
There exist pros and cons. Internet based help is always up-to-date, no
need to update a local help base every now and then, and it allows for
immediate feedback to the content providers - what does not mean that
this chance is really taken by the maintainers ;-)
It's a cumbersome feedback procedure, when every user has to file an bug
report on missing or insufficient help items or documentation. With a
chance that such a request is delayed until some future version, because
the according guru is busy with more interesting invention of new
features :-(
Currently I can imagine only one way, to raise the chances for
documentation improvement: the responsible developer should be blamed in
every place in the documentation, where he is the only person that can
provide better content. And these blames should not be simply removable,
as happened in the past. Remains the problem of telling the name of the
responsible, which has to be left to the Lazarus team; in a company the
QC staff would do that, but we don't have such a powerful institution
yet :-(
DoDi
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
