Not too impressed with the quality of F14 at this time

[Richard Ryniker]

> > I don't think GUI apps should be logging seemingly alarming messages
> > like this to stdout if they aren't actually a problem. If the
> > possibility that the referenced shared library isn't there is expected
> > and normal, then attempts to load it should fail silently.
> 
> Well, that's arguable. Many developers prefer apps to be 'chatty' and
> report things like this for informational purposes. It's a design
> choice, really.

OK, let's argue.  Well, I pretty much agree with you, Adam, but this is a
case where the actual wording of the message is an issue.  If the message
is informational, noting a condition that is acceptable and expected in
some normal circumstances, change:

  Gtk-Message: Failed to load module "atk-bridge": libatk-bridge.so: cannot
  open shared object file: No such file or directory

to something like this:

  Gtk-Message: Warning: proceding without module "atk-bridge":
  libatk-bridge.so: cannot open shared object file: No such file or directory

You may claim a change like this is simply application of whitewash to
disguise the real problem.  This is true.  Nevertheless, should we not
strive to make messages as clear as practical for the greatest number of
Fedora users? Even one message changed to remove confusion could benefit
thousands of users.

It would be nice to have a system-wide facility that associates a value
from a standard scheme of severity codes with messages.  Then, the same
message text might be issued in different circumstances, where the
severity code denotes the reason for the message:

  Debug
  Information
  Minor warning (some function may be unavailable, but correct operation is
      expected)
  Warning (unusual condition, results may not be what is intended)
  Minor error (results may be incorrect)
  Error (results are likely to be incorrect)
  Severe error (operation cannot continue)
  Fatal error (application terminates)
  System error (multiple applications terminate)

I know of some non-linux systems that employ message schemes like this.
They have probably been studied for linux in the past.  I suspect many
would agree they have value, but fear the magnitude of the task to
implement one for linux with so many sources for code and so many other
things more exciting or urgent to do.