#510 MacOSX: Silent failure when run from GUI
If bochs.app is run from the gui, but no bochsrc.txt
file is present. Then bochs tries to display its text
menu. But because bochs wasn't started up from the
command line all it does is send the text configure
interface to the MacOS X console and then shutdown.
From the user's perspective, all they see is the Bochs
icon bounce up and down as it starts, and then
disappear when it fails. No alerts, no messages.
Also, since bochs.app is being run from the gui, it
should already be aware that the text menu isn't usable.
I see that if no bochsrc file is detected, then quick
start is disabled. I suppose with BX_WITH_CARBON I
could insert another check for isatty, though I'm not
quite sure of the appropriate way to insert a platform
specific call to display an alert box.
Is there a way from that spot to send a message to the
default UI's callback interface?
Logged In: YES
user_id=185114
I think the right solution in these cases is to use a
platform specific dialog box to tell the user what to do
that will actually work. For example
"Please run Bochs by clicking on the Applescript icon
instead" or "Please run Bochs by typing 'bochs' at the
command line instead" or whatever.
The question of course is where to put this message. Maybe
at the point where we're just about to call the text config
interface. I'll think more about it.
Logged In: YES
user_id=185114
In CVS I have added a function ensure_text_console_exists()
which is called just before starting the text config
interface. On any system which does not have a console, the
ensure_text_console_exists() function should show a visible
error dialog using whatever library is available and then
return false to make Bochs quit.
All we have to do is show a dialog telling the user that
it's not going to work, and suggesting what they should do
instead. This isn't as good as creating a console and
making it work somehow, but it's certainly better than
silent failure.
Br'fin, could you make a patch that fills in the
BX_WITH_CARBON part of that function with a little dialog
code? I'm afraid it can't reference any code in
gui/carbon.cc because that may be stuck in a plugin
somewhere. We can just put the code right in main() for
now.
Logged In: YES
user_id=430631
Ok, I've attached a patch that implements a Carbon dialog
after checking the tty in ensure_text_console_exists
I should check, there are probably related issues with
BX_PANICs at this pre-gui point in bochs. Bochs panics and
of course can't show anything.
Patch implementing carbonFatalDialog
Logged In: YES
user_id=185114
Brefin, I checked in your patch. Thanks!
I realized that I might be calling
ensure_text_console_exists() from the wrong place. The
condition that you mentioned was "if no bochsrc file is
detected" but in fact you end up in the text config
interface even if there is a bochsrc but you did not type
-q. I think I need to move the call to
ensure_text_console_exists into gui/textconfig.cc somewhere.
Two things remain before this can be closed.
1. Move ensure_text_console_exists to the right place. I
will do this.
that's the other platform where I know the text console
cannot be used. The SDL problem could also be solved by
enabling the WinMain function that I wrote for
wxWindows-win32. I'll ask Volker to take a look at this
part.
Logged In: YES
user_id=430631
Well, Carbon will run right away because there's two checks
in the carbon code path that check things ahead of time. For
instance, one path checks for the command line argument
-psn*, sets up the carbon working directory and turns
quickstart on.
Another path, with Carbon & Plugins also does the isatty
check and turns on quickstart there. (This is because Carbon
& Plugins may include SDL which prevents the -psn* check
from occuring)
Logged In: YES
user_id=185114
Oops, when I wrotemy previous message it was not actually
checked in yet. Now it is, in rev 1.193.
Logged In: YES
user_id=185114
Volker, I know you've done some work on SDL in win32. If
that is working ok for you, please close this bug.
Logged In: YES
user_id=376477
Now there's only a problem with the runtime configuration. If
you choose "continue simulation" and the gui window receives
the focus again, all keypresses done on the console are
forwarded to the gui window. This problem appears only with
the SDL gui on win32 (with and without plugins).
The start menu works fine now.
Logged In: YES
user_id=185114
The remaining problem with SDL keyboard focus is already
mentioned in another bug report
[ 526984 ] SDL compiled in cygwin just quits
So I will close this one. #526984 is not scheduled for 2.0,
unless someone figures out how to fix it.