Suggestion: Make "WhatsThis" 100% complete for next release

Gunnar Schmi Dt gunnar at schmi-dt.de
Fri Feb 13 12:44:02 GMT 2004


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

On Friday 13 February 2004 00:43, Kurt Pfeifle wrote:
> Daniel Molkentin wrote:
> > On Thursday 12 February 2004 22:39, Aaron Seigo wrote:
> >>>Also, it would be cool if the documentation could somehow "include"
> >>> these help texts. Duplication could thus be avoided.
> >
> > QWhatsThis allows hyperlinks, khelpcenter supports juping to
> > subsections. I think that's what we want. Move longer explanations to
> > the docs
>
> Why? If there are longer ones, they seem to be required. Once you decide
> you need help and click the WhatsThis, your workflow is interrupted
> anyway. You've consciously decided you need to read up a bit. So if an
> explanation takes 100 words instead of 10, so be it. Likely you'll not
> klick often on it. And if you leave it alone, it leaves you alone.
>
> [...]

IMHO there is a difference between a good What's This-texts and a good 
documentation. The What's This text is mostly used if you are unsure about 
one user element while the documentation is used when you have no clue at 
all what the dialog is about or if the What's This text does not provide 
the information you need.

To give an example:
In KMail you can define filters. One filter action is to pipe the mail 
through a shell command. Regarding the input field where you can input the 
command I would expect to find the following help:

i. The What's This-text should tell the user that he can type in any shell 
command that reads the mail on the standard input and outputs the 
(possibly modified) mail again on the standard output. For substitutions 
(where you can feed header entries to parameters of the command) the 
What's This-text should refer to the manual.

ii. The manual should at least contain all the information found in the 
What's This-text plus additional information about which substitutions are 
performed on the command in order to include parts of the mail in the 
actual command. From a good documentation I even expect a number of 
examples for commonly used commands (in the case of a mail filter one 
example would be to pipe the mail through a spam checker)

Gunnar Schmi Dt
- -- 
Co-maintainer of the KDE Accessibility Project
Maintainer of the kdeaccessibility package
http://accessibility.kde.org/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD4DBQFALMaXsxZ93p+gHn4RAqmsAJ9U4MbY8diA32mfF7fJw95EYQJ8UACXai2F
e5F9mBFyCFl/PCw5UcHmKQ==
=7Lm1
-----END PGP SIGNATURE-----




More information about the kde-core-devel mailing list