[crossfire] [Crossfire-cvs] CVS commit: client

[Tchize]

Mark Wedel wrote:
>   General quick thoughts:
>
>   I removed them as I believe (rightly or wrongly) that software presented for 
> general end user consumption should not be producing debug or information 
> messages - it should only print error messages.  I'd almost be tempted to say 
> that the default log level should even go one step higher, so that warnings 
> should by default not be printed - only print error or above
>   
 From info to critical is everything that might concern user, every 
thing below is of concern to developpers.
>   Off the top of my head, I can not think of any other unix/linux programs that 
> produce a list of the rcsid versions of all the files when started.  I'm sure 
> there are exceptions, but I think it is better of we behave like most other 
> programs.
>   
This was (probably wrongly) introduced because i couldn't find a better 
way to identify version when it comes to cvs build clients. However, 
these informations can probably go in debug level. At least, the version 
number of client should be increased in cvs just after each release. 
(example: set 1.9.1, commit, tag cvs, release, set to 'post 1.9.1', commit)
>
> 1) Within the client itself, this information should be presented in the GUI. 
> For the gtk client, I'm going to modify the bug report page to include this 
> information.  For the gtk2 client, I'll make an about page that also includes that.
>
>   If in fact most people are running the client from a launcher and not seeing 
> the messages, then they aren't doing any good (that seems like counter argument 
> - no one will see the messages, so having them there doesn't harm anything).  So 
> having an in-client way to display them is better.
>   
help -> bug report, there is already everything needed there to provide 
information for a bug report, that is copy of log messages and a link to 
sourceforge tracker...
btw, a 'fork at begin, watch for dying of client process, expose a bug 
report window' might be interresting too, but quite more cumbersome to 
make :)
> 2) The log level should not be a compiled in default 
>   
agree, but info level should be the default.