Christian Neumair chris@gnome-de.org writes:
That reminds me of asking for nicer, GUI-driven error handling: touch mustardandwiener.exe && wine mustardandwiener.exe returns wine: cannot determine executable type for L"H:\Desktop\test.exe" which is neither verbose enough nor user friendly, because it is simply printed at a terminal. Modern desktop environments usually launch wine from their file manager, i.e. without terminals.
Well, as to the contents of the message itself, I don't know how it could be improved. You asked Wine to run an empty file and it said it can't figure out what kind of executable it is: why is this a problem?
As to using message boxes for errors, well I have submitted patches to do this before and some were accepted, and some were not. The reasoning was that having all errors appear in message boxes would be annoying.
Perhaps if there was a generic mechanism such that when a terminal was available the message was printed, and when it was not (like in a GUI) a message box was used, that would be more acceptable.
I don't know how to tell if a console is available or not though. Plus to be convenient it'd need to be a new Wine API and we're trying to remove them rather than add to them :)
Can't we have popup dialogs for that kind of errors? As far as I know, debian guys have build a shell/wrapper around wine that pops up if weird things like these occur. Can't we have such a wrapper in stock wine? For now, it would be enough to just catch the most common problems (binary not found, binary can't be loaded, etc.).
To be frank I still think displaying the output of stderr when a program launched from the GUI fails is the desktops job. All kinds of messages can be printed by Wine before we even have a chance to initialize the GUI subsystem - in fact the "cannot run exe" message may well be an example of that.
Writing a patch to Gnome to make it do that wouldn't be hard and would solve a broad class of problems.
thanks -mike
Mike Hearn wrote:
Christian Neumair chris@gnome-de.org writes:
That reminds me of asking for nicer, GUI-driven error handling: touch mustardandwiener.exe && wine mustardandwiener.exe returns wine: cannot determine executable type for L"H:\Desktop\test.exe" which is neither verbose enough nor user friendly, because it is simply printed at a terminal. Modern desktop environments usually launch wine from their file manager, i.e. without terminals.
Well, as to the contents of the message itself, I don't know how it could be improved. You asked Wine to run an empty file and it said it can't figure out what kind of executable it is: why is this a problem?
A user often doesn't understand what that means. A proper error message should be, at the very least, something like the following: Wine cannot run "H:\Desktop\test.exe". It is not in a format Wine understands.
Also, maybe we need a new debug level for that (above ERR and FIXME), which is "Human readable messages". The message as it is is perfectly understandable to programmers, but not to users. Even if it was, these messages are usually surrounded by hundred of messages that the user have no use in seeing. We should be able to let the user see only the messages that are relevant to them.
Shachar
On Sun, 2004-07-25 at 19:02 +0300, Shachar Shemesh wrote:
Also, maybe we need a new debug level for that (above ERR and FIXME), which is "Human readable messages". The message as it is is perfectly understandable to programmers, but not to users. Even if it was, these messages are usually surrounded by hundred of messages that the user have no use in seeing. We should be able to let the user see only the messages that are relevant to them.
Yeah, I like that idea. It could also be the first step towards moving certain classes of messages into a GUI form (of course it could still be sent to the console when you run wine like that, or be controlled by a config option).
Alexandre, what is your opinion on such a channel?
thanks -mike
Also, maybe we need a new debug level for that (above ERR and FIXME), which is "Human readable messages". The message as it is is perfectly understandable to programmers, but not to users. Even if it was, these messages are usually surrounded by hundred of messages that the user have no use in seeing. We should be able to let the user see only the messages that are relevant to them.
Yeah, I like that idea. It could also be the first step towards moving certain classes of messages into a GUI form (of course it could still be sent to the console when you run wine like that, or be controlled by a config option).
What about a simple GUI-application which would call wine and capture (and maybe parse?) the output? This would be called if a program is started with a shortcut (no console). For the console you can still use the normal wine. Like that the user has at least the ability to see the messages. The content is a different matter.
bye Fabi
On Monday 26 July 2004 13:04, Fabian Cenedese wrote:
What about a simple GUI-application which would call wine and capture (and maybe parse?) the output? This would be called if
If it is fatal error we can use error code returned by wine process.
On Mon, 26 Jul 2004 11:04:38 +0200, Fabian Cenedese wrote:
What about a simple GUI-application which would call wine and capture (and maybe parse?) the output? This would be called if a program is started with a shortcut (no console). For the console you can still use the normal wine. Like that the user has at least the ability to see the messages. The content is a different matter.
I think that'd be rather fragile: if the message changes the gui wrapper breaks. Better to not hack around it and just do it in the core
At 13:31 26.07.2004 +0100, Mike Hearn wrote:
On Mon, 26 Jul 2004 11:04:38 +0200, Fabian Cenedese wrote:
What about a simple GUI-application which would call wine and capture (and maybe parse?) the output? This would be called if a program is started with a shortcut (no console). For the console you can still use the normal wine. Like that the user has at least the ability to see the messages. The content is a different matter.
I think that'd be rather fragile: if the message changes the gui wrapper breaks. Better to not hack around it and just do it in the core
Well, the parsing was just an idea. The main intent for the GUI-app was that the user could at least see something as opposed to the messages vanishing on the non-existent console or the ever popping up error dialogs. The user can use the messages or he can just discard them. And he's not forced to click on thousands of dialogs :) Would that be the most "GUI user friendly" solution? Rewording the errors is no good if the perfect error messages disappear in the system :)
bye Fabi
On Mon, 26 Jul 2004 15:44:02 +0200, Fabian Cenedese wrote:
Well, the parsing was just an idea. The main intent for the GUI-app was that the user could at least see something as opposed to the messages vanishing on the non-existent console or the ever popping up error dialogs.
I guess GUI dialogs would only be used for fatal or nearly-always-fatal errors (like crashes or startup problems). The rest would go to stderr as always.
Le lun 26/07/2004 à 10:56, Mike Hearn a écrit :
On Mon, 26 Jul 2004 15:44:02 +0200, Fabian Cenedese wrote:
Well, the parsing was just an idea. The main intent for the GUI-app was that the user could at least see something as opposed to the messages vanishing on the non-existent console or the ever popping up error dialogs.
I guess GUI dialogs would only be used for fatal or nearly-always-fatal errors (like crashes or startup problems). The rest would go to stderr as always.
Would using something along the lines of the Quake3 console (the one briefly shown on Win32 at startup) be useful for such messages?
Vincent
Mike Hearn mike@navi.cx writes:
[...]
I don't know how to tell if a console is available or not though.
isatty(STDOUT_FILENO) is probably pretty close to the right way to do this.
-----ScottG.
On Fri, 30 Jul 2004 16:39:36 -0400, Scott W Gifford wrote:
isatty(STDOUT_FILENO) is probably pretty close to the right way to do this.
Thanks but I suspect we'd need to use the Windows API at that point in the code.
-
Fabian Cenedese -
Mike Hearn -
Scott W Gifford -
Shachar Shemesh -
Vincent Béron -
Vitaly Lipatov