Re: [crossfire] [Crossfire-cvs] CVS commit: client
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I do not agree on this change, those informations are not so verbose and have no reason to make users afraid of as they are not visible by default. Normal users don't start game in console and those starting in console want basic messages about what is happening. Moreover, this is pretty usefull to ask on irc a user to dump us content of help - bugreport when trying to support him. It's easier to ask player to go to a menu entry then ask him to go in consle mode, and it works crossplatform Crossfire CVS repository messages. a écrit : > Module Name: client Committed By: mwedel Date: Sun Jul 2 03:19:43 > UTC 2006 > > Modified Files: client: ChangeLog client/common: misc.c > > Log Message: common/misc.c: Make default log level 2 when not in > debug mode. Normal users probably don't want all the INFO log > messages, and it never makes a good impression about > stability/quality if a program spews out lots of errors or other > messages. MSW 2006-07-01 > > > -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFEp7ZlHHGOa1Q2wXwRAsHYAJwNpQ3aGDts/IfYbJdPYeGvX6VFEACeJoky wxfJo+dw4uAaI3ySSS6aYYI= =fnnG -END PGP SIGNATURE- ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] [Crossfire-cvs] CVS commit: client
tchize wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > I do not agree on this change, those informations are not so verbose > and have no reason to make users afraid of as they are not visible by > default. Normal users don't start game in console and those starting > in console want basic messages about what is happening. Moreover, this > is pretty usefull to ask on irc a user to dump us content of help - > bugreport when trying to support him. It's easier to ask player to go > to a menu entry then ask him to go in consle mode, and it works > crossplatform Given (IIRC) that the client does not currently register itself with gnome of KDE, I'd expect most people to actually run from the command line. Any my experience is that very few programs will dump out all that information by default. And one problem in doing so is that it can be harder to see real error messages. Probably the correct solution is to add a -V or --version option to the clients which dump out that information - that is what most all other applications do. It hides the information people don't need by default, but still provides a way to get that information in case of bug reports, etc. > > Crossfire CVS repository messages. a écrit : > >> Module Name: client Committed By: mwedel Date: Sun Jul 2 03:19:43 >> UTC 2006 >> >> Modified Files: client: ChangeLog client/common: misc.c >> >> Log Message: common/misc.c: Make default log level 2 when not in >> debug mode. Normal users probably don't want all the INFO log >> messages, and it never makes a good impression about >> stability/quality if a program spews out lots of errors or other >> messages. MSW 2006-07-01 >> >> >> > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.1 (GNU/Linux) > > iD8DBQFEp7ZlHHGOa1Q2wXwRAsHYAJwNpQ3aGDts/IfYbJdPYeGvX6VFEACeJoky > wxfJo+dw4uAaI3ySSS6aYYI= > =fnnG > -END PGP SIGNATURE- > > > ___ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] [Crossfire-cvs] CVS commit: client
> Given (IIRC) that the client does not currently register itself with > gnome of KDE, I'd expect most people to actually run from the command line. > > Any my experience is that very few programs will dump out all that > information by default. And one problem in doing so is that it can be > harder to see real error messages. > It sounds like backward thinking to me. That most people have to run the game from the command line (and thus, see all what the client can spit out) seems to be the point to solve, and not the messages provided. Moreover, if the error messages are hard to spot, then make them more obvious (add stars around them, write a couple of !!!, shift them, add blank lines before and after them, etc). I'd also underline that the error messages targetted at the player shouldn't only go to the console, but also be clearly visible from the GUI itself in the first place whenever possible. In such a case, the player would logically first report the short error message he/she saw in a dialog box. Then, if details are needed, he/she can sends the whole content of the console messages. Sounds a much better way to make at least common errors easier to spot for the player than completely hiding what's basically useful information. > Probably the correct solution is to add a -V or --version option to the > clients which dump out that information - that is what most all other > applications do. It hides the information people don't need by default, > but still provides a way to get that information in case of bug reports, > etc. > The question is: which informations are needed by default ? I think the "Info" should have an obvious meaning: provide a couple of informations that *may* be useful in several cases, debugging being one of them. If some informations are judged superlfluous at the default level of log (typically, what's required only for debugging/post-mortem analysis) then those should be put back in the "Debug" log level, which would appear only when the verbosity is explicitely increased. Finally, I don't get why this change was done in the first place - I've so far never heard anybody bothered by the amount of log messages provided in the console; besides that, there are relatively few messages displayed, even at the "Info" level. So not only does the change of the default verbosity level in the client sound detrimental to me, but it solves a problem that didn't even exist in the first place. > > > Crossfire CVS repository messages. a écrit : > >> Module Name: client Committed By: mwedel Date: Sun Jul 2 03:19:43 > >> UTC 2006 > >> > >> Modified Files: client: ChangeLog client/common: misc.c > >> > >> Log Message: common/misc.c: Make default log level 2 when not in > >> debug mode. Normal users probably don't want all the INFO log > >> messages, and it never makes a good impression about > >> stability/quality if a program spews out lots of errors or other > >> messages. MSW 2006-07-01 > > > > -BEGIN PGP SIGNATURE- > > Version: GnuPG v1.4.1 (GNU/Linux) > > > > iD8DBQFEp7ZlHHGOa1Q2wXwRAsHYAJwNpQ3aGDts/IfYbJdPYeGvX6VFEACeJoky > > wxfJo+dw4uAaI3ySSS6aYYI= > > =fnnG > > -END PGP SIGNATURE- > > > > > > ___ > > crossfire mailing list > > crossfire@metalforge.org > > http://mailman.metalforge.org/mailman/listinfo/crossfire > > ___ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire -- Yann Chachkoff --- GPG Key 2006: http://keyserver.veridis.com:11371/export?id=-43113965597490782 Fingerprint : C224 F1F9 9025 4FC7 987D 05BB FF66 D413 A3B4 01A2 --- "They misunderestimated me." - George W. Bush pgphImGpG7EyP.pgp Description: PGP signature ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] [Crossfire-cvs] CVS commit: client
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 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. I'm not even sure if the reporting of rcsid information has ever proved useful - I can't recall any bug reports where that has been provided. Most useful bit of information that users can provide is the overal version number of the client they are using, not the version information of the specific files. A lot of this is also perception. While perhaps no official complaints registered, I don't think it puts a good perception on the program. All that said, thoughts on how to fix this: 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. 2) The log level should not be a compiled in default - one should be able to specify it via command line (-loglevel 0) or whatever. In that case, if user has a bug, we can always say 'run with -loglevel 0' and provide us the output. This is more useful in all cases, as by default, old log level was 1 so we couldn't get debug level output without requesting the user to recompile (which doesn't work when it is prebundled). This should be pretty easy to do I think. How do those remedies sound to people? ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] [Crossfire-cvs] CVS commit: client
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. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] [Crossfire-cvs] CVS commit: client
One thing which may make sense is different default levels based on if it is a precompiled binary vs something checked out from CVS. I still stand by that the precompiled binaries should be less verbose on problems - we're putting this out there as this is quality software, so it should act like it. Perhaps even the official source code releases should also be more quiet. However, if running from CVS, then having all sorts of error messages is fine. I'm not sure if there is any way of automatically doing this detection logic in the build environment itself. I suppose the file can be changed just prior to release. Maybe the best method is also an ability to pass it in via command line/CFLAGS (-DLOGLEVEL=...) ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] [Crossfire-cvs] CVS commit: client
Maybe a ./configure --release= :) Mark Wedel wrote: > One thing which may make sense is different default levels based on if it > is a > precompiled binary vs something checked out from CVS. > > I still stand by that the precompiled binaries should be less verbose on > problems - we're putting this out there as this is quality software, so it > should act like it. Perhaps even the official source code releases should > also > be more quiet. > > However, if running from CVS, then having all sorts of error messages is > fine. > > I'm not sure if there is any way of automatically doing this detection > logic > in the build environment itself. I suppose the file can be changed just > prior > to release. Maybe the best method is also an ability to pass it in via > command > line/CFLAGS (-DLOGLEVEL=...) > > > ___ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > > ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] [Crossfire-cvs] CVS commit: client
Tchize wrote: > Maybe a ./configure --release= > :) I really like that idea, except for one issue. People compiling from source releases typically wouldn't do that, so I think that what would be better than including that in the ./configure, would be having a simple script that could be run as part of the release process. Alex Schultz ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] [Crossfire-cvs] CVS commit: client
Alex Schultz wrote: > Tchize wrote: >> Maybe a ./configure --release= >> :) > I really like that idea, except for one issue. People compiling from > source releases typically wouldn't do that, so I think that what would > be better than including that in the ./configure, would be having a > simple script that could be run as part of the release process. Updating the version number requires the update of the configure.ac script (then it builds the correct package, etc). Likewise for the rpmspec file. However, doing something like ./configure --debuglevel=0 does work, because the rpmspec, which at least is used for rpm building, does have the configure line it uses, so modifying that to include the debug option works just fine and dandy. I'll look at doing that. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] [Crossfire-cvs] CVS commit: client
maybe add in the configure script something like (pseudo code) if -e "./CVS" then cvs-date=date_of_"./CVS" that won't give a version number, but it does include a clue about the version used. On Wed, 2006-07-05 at 09:54 -0600, Alex Schultz wrote: > Tchize wrote: > > Maybe a ./configure --release= > > :) > I really like that idea, except for one issue. People compiling from > source releases typically wouldn't do that, so I think that what would > be better than including that in the ./configure, would be having a > simple script that could be run as part of the release process. > > Alex Schultz > > ___ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] [Crossfire-cvs] CVS commit: client
Mark Wedel wrote: > Alex Schultz wrote: >> Tchize wrote: >>> Maybe a ./configure --release= >>> :) >> I really like that idea, except for one issue. People compiling from >> source releases typically wouldn't do that, so I think that what would >> be better than including that in the ./configure, would be having a >> simple script that could be run as part of the release process. > > Updating the version number requires the update of the configure.ac script > (then it builds the correct package, etc). Likewise for the rpmspec file. > > However, doing something like ./configure --debuglevel=0 does work, because > the rpmspec, which at least is used for rpm building, does have the configure > line it uses, so modifying that to include the debug option works just fine > and > dandy. > > I'll look at doing that. That was easier than expected, so I put in a --with-logevel=x configure options. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] [Crossfire-cvs] CVS commit: client
Let's just do what Wim Villerius suggested: if we find a .CVS, use it as version number, else use version number read from a simple VERSION file. This all can be calculated at very begining of configure script, before defining version number :) Mark Wedel wrote: > Alex Schultz wrote: > >> Tchize wrote: >> >>> Maybe a ./configure --release= >>> :) >>> >> I really like that idea, except for one issue. People compiling from >> source releases typically wouldn't do that, so I think that what would >> be better than including that in the ./configure, would be having a >> simple script that could be run as part of the release process. >> > > Updating the version number requires the update of the configure.ac script > (then it builds the correct package, etc). Likewise for the rpmspec file. > > However, doing something like ./configure --debuglevel=0 does work, because > the rpmspec, which at least is used for rpm building, does have the configure > line it uses, so modifying that to include the debug option works just fine > and > dandy. > > I'll look at doing that. > > ___ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > > ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] [Crossfire-cvs] CVS commit: client - info level
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Most distros provide a shortcut menu to client, moreover, windows users don't use the console and it would be very difficult to have them running a program from console to pass log argument. I ran it in info mode just to check, all i got is 30 lines of info telling user mainly about client modules version and server communication. This is not so much, i remember games like half-life or UT dump pages of messages in console and nobody is afraid of this. And i don't see where this make errors difficulut to find. By user? When user has program running like he wants, am pretty sure it doesn't read console! By developper? developper will need at least an info level to see what's wrong most of the time. Seriously, I don't want to fight on this point, this is pretty trivial and i have othere things to do. This is my last mail on this subjectn do what you like. I have never seen a player on irc being afraid of those messages and i have seen several time it proves usefull to detect version of client / detect kind of server the user is playing on. Usefull informations are provided on info level while not slowing client and not invading user. There was no point removing that behaviour. There is no gain in removal and there is informations lost. Greetings, Tchize Mark Wedel a écrit : > tchize wrote: > > I do not agree on this change, those informations are not so > verbose and have no reason to make users afraid of as they are not > visible by default. Normal users don't start game in console and > those starting in console want basic messages about what is > happening. Moreover, this is pretty usefull to ask on irc a user to > dump us content of help - bugreport when trying to support him. > It's easier to ask player to go to a menu entry then ask him to go > in consle mode, and it works crossplatform > > >> Given (IIRC) that the client does not currently register itself > with gnome of >> KDE, I'd expect most people to actually run from the command >> line. > >> Any my experience is that very few programs will dump out all > that information >> by default. And one problem in doing so is that it can be harder >> > to see real >> error messages. > >> Probably the correct solution is to add a -V or --version option > to the >> clients which dump out that information - that is what most all >> other applications do. It hides the information people don't >> need by > default, but >> still provides a way to get that information in case of bug > reports, etc. > > > Crossfire CVS repository messages. a écrit : > >> Module Name: client Committed By: mwedel Date: Sun Jul 2 03:19:43 >> UTC 2006 > >> Modified Files: client: ChangeLog client/common: misc.c > >> Log Message: common/misc.c: Make default log level 2 when not in >> debug mode. Normal users probably don't want all the INFO log >> messages, and it never makes a good impression about >> stability/quality if a program spews out lots of errors or other >> messages. MSW 2006-07-01 > > > ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire > ___ crossfire mailing > list crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFEqDjdHHGOa1Q2wXwRAqCsAKC98YV4k/5tWZMbolb2E7egpZGkmACeJDh1 838DvvJQbVxXYeMf07BS13M= =ZSSC -END PGP SIGNATURE- ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] [Crossfire-cvs] CVS commit: client - info level
Hello. > Most distros provide a shortcut menu to client, moreover, windows > users don't use the console and it would be very difficult to have > them running a program from console to pass log argument. I ran it in Actually, Windows client does get console. Shortcut runs app, and you see the console still. Nicolas ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
