Why don't you redirect the output, e.g. run okular as follows

$ okular file.pdf >/dev/null 2>/dev/null

Disable any KDE debug output using `kdebugdialog`; please note that not all the output comes from okular itself, but from the kde libraries for example (the part between / and : will give you the name of the related debug area in kdebugdialog).

I suppose I thought it might be reasonable for kde apps not to clutter up my shell by default when handling normal everyday situations.

There seems to be some shift in thinking that goes like this - in the olden days people cared about the cluttering up people's shells but for some reason this doesn't matter anymore - here is my bug report - it is antisocial for applications to treat stdout and stderr to this sort of nonse.

There seems two problems:
(1) far too much crap is being printed to stdout and stderr
(2) there is no good reason in this particular case for the application to get quite so upset.

By default, KDE applications compiled in release mode should not produce debug output. I don't know what openSUSE does, but for sure complaining about "anti-social" attitudes and act as anti-social reopening this bug report do not go together.

Picking up the output lines you pasted:
> okular(11121)/kdeui (kdelibs): Attempt to use QAction "" with KXMLGUIFactory! 

this has been fixed in some KDE 4.6.x releases.

> Error: PDF file is damaged - attempting to reconstruct xref table... 
> Error: Couldn't find trailer dictionary 
> Error: Couldn't read xref table 

this "continual whining" is just the poppler library reporting that the PDF file that changed is not properly open as such -- mostly because it is being recompiled or the latex generation failed. I do not see anything wrong with this.
(and even if it is not coming out from any KDE component, in recent versions of okular + recent/stable poppler-q4 this goes to the same okular debug stream.)

> okular(11121)/kio (KDirWatch) KDirWatchPrivate::removeEntry: doesn't know 

most probably due to the above.

Also, you write:
> Please either make okular silent at the shell or include a command line option
> to do the same.

... which has been answered already: make sure your KDE applications are compiled in release mode, or use `kdebugdialog` to disable the debug outputs of KDE components, Okular included.

The reason that there is something wrong with this is because this is "normal" it happens all the time while people are using the software and it is disruptive and irritating.

Unwanted behaviour in normal use = bug hence bug report

I already explained you there is no bug, and there are multiple ways to avoid debug output.
Please do use one of them, and stop reopening this bug report.

I think we'll have to disagree on whether or not it is a bug then, I think it is because it is unwanted and unintended behaviour in response to normal use that is actually a pain in the arse.  

Your argument must be "it is intended and ok to clutter up my shell with useless and unwanted behaviour during normal use" and you seem to regard cluttering up a shell as ok whereas I don't.

Since I assume nothing is going to be done, do as you wish with the report.

My argument is that there are multiple ways to NOT have debug output, and apparently you don't care about any of them (although you asked for one when opening this report).

> Since I assume nothing is going to be done, do as you wish with the report.

You're right, there's nothing to be done, what you initially asked is already doable.

Take an example, "ls" and assume that ls produce loads of pointless debugging nonsense on stderr everytime you ran it - this would be a bug and it would be one that you could easily fix by redirecting standard out. It wouldn't be an acceptable state of affairs though and the reason why is because it is used from a shell and it would be  cluttering up the shell.

I (and many others) use okular from a shell, this nonsense is cluttering it up pointlessly.

The only difference I can see here is the attitude of the maintainers and I think this is probably to do with the attitude to the shell - I presume that attitude that it is fair game to pointless stream out nonsense to the shell is that you really don't think this is a problem, perhaps because you don't really think people should use these tools from a shell.

(In reply to comment #9)
> I (and many others) use okular from a shell, this nonsense is cluttering it up
> pointlessly.

And I already told you why it is caused and how it can be disabled, right? Please do READ what I said.

> The only difference I can see here is the attitude of the maintainers

... or actually, the continuous pointlessy talking by a reporter which is unable to read what other people tell you, most probably because he (the reporter) does not want those solutions.

And, for the N-th time, please STOP changing the resolution of this bug to your liking.

(In reply to comment #9)
> The only difference I can see here is the attitude of the maintainers and I
> think this is probably to do with the attitude to the shell - I presume that
> attitude that it is fair game to pointless stream out nonsense to the shell is
> that you really don't think this is a problem, perhaps because you don't
> really think people should use these tools from a shell.

Please be polite to the developers. This is just pointless trolling.

David, I share your sentiment about debug output and have filed similar bugs
for various KDE components in the past. 

In this case, though, I think Pino explained to you what's going on why this
output is not Okular's fault. Some of the sources are deeper in KDE libs and
have already been fixed -- or if it's still there in an up-to-date KDE then it
should be filed with kdelibs.

Other output is from Poppler, the PDF rendering library, and is a genuine error
output -- I frequently see it happen when a PDF I'm viewing gets deleted and
regenerated during a latex recompile. Since you use 'ls' as an example, see
what it prints when you give it the name of a non-existent file as an argument.
I bet it's something along the lines of "ls: cannot access bla: No such file or
directory"

Lastly, more generally, some of the fault may lie with your Linux distribution.
KDE can be configured to different levels of printing debug information, and
most of that should be turned off when released to end users (major errors
excepted). Sometimes it's released still turned on, although you can turn it
off yourself with a GUI tool called kdebugdialog. Try it. It wont' fix
everything, though: some pieces of KDE do not follow the rules and use printing
functions that cannot be turned off that way. File bugs for those components,
but Okular is clean in that respect.

kdebugdialog has everything turned off, yes I know I can suppress the output by redirection but it is still annoying and unnecessary. I don't understand why this is not "wontfix"...

David, the back-and-forth with the bug status is ridiculous, I think you changed it something like four or five times. Reopening it once, I can understand, but when Pino explains to you why he doesn't think this is an *Okular* bug, then it's INVALID.

If you turned everything off with kdebugdialog, then please file separate bugs with 'kdeui' and 'kio' about the KXMLGUIFactory and KDirWatch messages, those are valid bugs.

FWIW, finer-grained control than with kdebugdialog is possible via .kde/share/config/kdebugrc. I don't know the full details of its syntax, but it allows turning off not just debugging output (level "info"), but also more severe warnings and errors.