Richard Frith-Macdonald wrote:
On 25 Feb 2006, at 04:37, Sheldon Gill wrote:
Richard Frith-Macdonald wrote:
On 23 Feb 2006, at 01:04, Gregory John Casamento wrote:
[snip]
So, only four categories rather than six ... even so, I think
NSWarnLog() is hardly ever used ... I think it's really, really hard to
assign some messages to particular categories ... for anything which is
not a fatal error and is not clearly for debugging purposes, it's
horribly different to classify, because what is appropriate usually
depends on the audiance/user and what they are trying to do with the
library.
I think its actually much easier to classify than you thing. The audience to
consider is "run-of-the-mill" user running a packaged installation. After all,
this is the target audience in the end for just about everyone.
In my experience, most such end users only want logs containing bad things they
really need to know about. Less, rather than more.
Power users and developers have the savvy to up their logging level. They can
also be presumed to understand more detail/technical info.
However, an audit would be good ... I suspect a number of NSLog() calls
should be NSWarnLog() or even NSDebugLog()
Basically what I'm getting at. Problem is, at the moment there isn't any rule
or guideline about how to classify such messages.
The problem we have with NSWarnLog() is that it is being used for information
level messages rather than warning/alert level messages. It should be more like
GSInfoLog() to be clear. I'd expect most packaged installs to have such
messages off.
In my view there are lots of messages which need to be sorted. I would rather
change them after we have some general agreement on categorisation.
What I was referring to in an earlier email is the idea that in some
circumstances (a normal install) missing resource files are a real
oddity and mean that the program won't behave as expected ... which may
well constitute a failure, but in other circumstances (deliberately
installed without resources as a standalone library) you could assume
that the lack of locatable resources was intentional, so any program
using the library presumably expects the changed behavior and it is not
a failure. Thinking more about it, this is probably not a good idea to
infer from library location.
Great. With you on that.
Regards,
Sheldon
_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev