On Mon, May 20, 2002 at 09:50:03PM +0200, Eric Pouech wrote:
this patch fixes a set of issues: 1/ large fonts could be picked up if no decent registry content was found (thanks to Sylvain Petreolle and Andi Mohr for the bug reports) 2/ better error messages in case of failure (even if I'm sure Andi will not like them... feel free to be more verbose)
Yep, true. (and I forgot to tell you before :-)
Why is the "missing font" message a WINE_WARN ? IMHO this should clearly be a WINE_ERR, as it's a user warning, it's not only of interest to developers.
Andreas Mohr andi@rhlx01.fht-esslingen.de writes:
Why is the "missing font" message a WINE_WARN ? IMHO this should clearly be a WINE_ERR, as it's a user warning, it's not only of interest to developers.
Warnings should be WARN, only errors should be ERR (makes sense uh?) We already have way too much noise being printed by default. Ideally it should be possible to always display the error messages because you would only get one when there is really a fatal error. As it is now, if you want a user-friendly install, you have to pipe all the output to /dev/null (like we do in Crossover) if you don't want to scare your users with dozens of meaningless errors. That's not good.
On Mon, May 20, 2002 at 01:54:31PM -0700, Alexandre Julliard wrote:
Andreas Mohr andi@rhlx01.fht-esslingen.de writes:
Why is the "missing font" message a WINE_WARN ? IMHO this should clearly be a WINE_ERR, as it's a user warning, it's not only of interest to developers.
Warnings should be WARN, only errors should be ERR (makes sense uh?) We already have way too much noise being printed by default. Ideally it should be possible to always display the error messages because you would only get one when there is really a fatal error. As it is now, if you want a user-friendly install, you have to pipe all the output to /dev/null (like we do in Crossover) if you don't want to scare your users with dozens of meaningless errors. That's not good.
That's not good, yes. And it's even worse if people don't know where to look at in order to find out "why this bloody wineconsole doesn't work" (to just express how people would react).
This WINE_ERR is *required* IMHO. Convincing me otherwise will be hard. Like you said, piping to /dev/null is possible, so why *not* use an ERR ?
Besides, like you said above, "only errors should be ERR". This is not only an error, it's a *critical error*, as it aborts the whole program... If that's not an *ERROR*, then I really don't know what an error looks like.
This mail had perfect timing, BTW. I just had the same wineconsole abort on my other desktop box about one minute ago...
Why let Wine print user messages at all ? It's not required, as Wine fails for endusers most of the time anyway ;-)
Again, simply giving a WARN to such a critical abort is underrated.
--- Andreas Mohr andi@rhlx01.fht-esslingen.de wrote:
On Mon, May 20, 2002 at 01:54:31PM -0700, Alexandre Julliard wrote:
Andreas Mohr andi@rhlx01.fht-esslingen.de
writes:
Why is the "missing font" message a WINE_WARN ? IMHO this should clearly be a WINE_ERR, as it's
a user warning,
it's not only of interest to developers.
Warnings should be WARN, only errors should be ERR
(makes sense uh?)
We already have way too much noise being printed
by default. Ideally
it should be possible to always display the error
messages because you
would only get one when there is really a fatal
error. As it is now,
if you want a user-friendly install, you have to
pipe all the output
to /dev/null (like we do in Crossover) if you
don't want to scare your
users with dozens of meaningless errors. That's
not good. That's not good, yes. And it's even worse if people don't know where to look at in order to find out "why this bloody wineconsole doesn't work" (to just express how people would react).
why not have wine take advantage of syslog-ng (if syslog-ng is installed and running)? its an easy way to find out like you said "why this bloody wineconsole doesn't work" and you can still redirect the output to /dev/null...
by the by, if you don't know how syslog-ng is an easy way to find out, it prints out all messages it is given to tty12, so all the user would have to do is hit ctrl+alt+f12 read the message(s) and then alt+f7 back to x...
Dustin
__________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com
On Mon, 2002-05-20 at 22:22, Dustin Navea wrote:
why not have wine take advantage of syslog-ng
by the by, if you don't know how syslog-ng is an easy way to find out, it prints out all messages it is given to tty12, so all the user would have to do is hit ctrl+alt+f12 read the message(s) and then alt+f7 back to x...
I don't *think* I'm using syslog-ng (I'm on whatever comes with Debian woody) and I can do this anyway. I have an entry like this in syslog.conf:
*.* /dev/tty10
And I get everything on VC#10
I have loved this feature since I discovered it. I even use it on the firewall and added a startup script to change to VC 10 on startup (so I just need to plug a monitor in to see why it's stopped responding :)
--- Russell Howe rhowe@wiss.co.uk wrote:
On Mon, 2002-05-20 at 22:22, Dustin Navea wrote:
why not have wine take advantage of syslog-ng
by the by, if you don't know how syslog-ng is an
easy
way to find out, it prints out all messages it is given to tty12, so all the user would have to do
is
hit ctrl+alt+f12 read the message(s) and then
alt+f7
back to x...
I don't *think* I'm using syslog-ng (I'm on whatever comes with Debian woody) and I can do this anyway. I have an entry like this in syslog.conf:
*.* /dev/tty10
And I get everything on VC#10
I have loved this feature since I discovered it. I even use it on the firewall and added a startup script to change to VC 10 on startup (so I just need to plug a monitor in to see why it's stopped responding :)
Ahh, that is a good point, and thanks for the info, I may not have to use 2 syslog's now ;)
__________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com
Andreas Mohr andi@rhlx01.fht-esslingen.de writes:
Besides, like you said above, "only errors should be ERR". This is not only an error, it's a *critical error*, as it aborts the whole program... If that's not an *ERROR*, then I really don't know what an error looks like.
Of course if it aborts the program it's a critical error. But that's not what it's supposed to do, it's supposed to go look for a default font. The right way to fix this kind of issues is not to print even more messages on abort, it's to implement a fallback that makes sure we never abort. Or if we really cannot continue, popup a message box or something like this. The user should not be required to start Wine from an xterm to be able to figure out what's going on.
On Mon, May 20, 2002 at 02:40:10PM -0700, Alexandre Julliard wrote:
Andreas Mohr andi@rhlx01.fht-esslingen.de writes:
Besides, like you said above, "only errors should be ERR". This is not only an error, it's a *critical error*, as it aborts the whole program... If that's not an *ERROR*, then I really don't know what an error looks like.
Of course if it aborts the program it's a critical error. But that's not what it's supposed to do, it's supposed to go look for a default font. The right way to fix this kind of issues is not to print even more messages on abort, it's to implement a fallback that makes sure we never abort. Or if we really cannot continue, popup a message box or something like this. The user should not be required to start Wine from an xterm to be able to figure out what's going on.
True, console messages are a problem for those GUI only (yuck ! ;-) users. I'm afraid that faced with a pretty broken font selection choice, wineconsole won't have much of a choice whether to abort or not... So in case it really isn't usable, we need to notify the user of why it happened (using a MessageBox).
Eric's new patch does indeed improve font enumeration (I now get a working wineconsole, thanks !), although the font size is a bit tiny. Thus it's a bit difficult to read.
On 20 May 2002, Alexandre Julliard wrote: [...]
Or if we really cannot continue, popup a message box or something like this. The user should not be required to start Wine from an xterm to be able to figure out what's going on.
Just a word of caution:
The user should not be required to have a graphical interface (usually X) running to be able to figure out what's going on. You can write console Windows applications and these should not require X to be running.
-- Francois Gouget fgouget@free.fr http://fgouget.free.fr/ It really galls me that most of the computer power in the world is wasted on screen savers. Chris Caldwell from the GIMPS project http://www.mersenne.org/prime.htm
The user should not be required to have a graphical interface (usually X) running to be able to figure out what's going on. You can write console Windows applications and these should not require X to be running.
easier said than done. As of today wineconsole requires a real user32 up and running (and I never tested with ttydrv as graphic driver) I however have an (n)curse backend for wineconsole (which doesn't require user32). the core part of it is ok (curse handling), what's still badly broken is how this wineconsole should attach to the unix console (which requires some more work).
A+
-
Alexandre Julliard -
Andreas Mohr -
Dustin Navea -
Eric Pouech -
Francois Gouget -
Russell Howe