|Re: [hatari-devel] Re: immortal hatari|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
On 10/29/2016 10:11 PM, Douglas Little wrote:
Ok a bit more on this bizarre issue....
I tried a range of random things, including reinstalling most of the Ubuntu
desktop & compiz related components. Didn't help.
So I grabbed Hatari 2.0 from mercurial and built that. Didn't help - same
I also noticed that a similar issue is easily reproduced by toggling the
sound on/off in the SDL Hatari menu. The window hangs as soon as you return
to the main menu.
That seemed a bit suspicious...
This Ubuntu install is running as a VM under VirtualBox - which definitely
has its moments. So I toggled the sound 'hardware' off, and turned 2D
acceleration on in VirtualBox, and restarted the VM.
Problem went away...
Hm. SDL handles sound in a separate thread. But threads go
away at the same time as the main program...
On 29 October 2016 at 18:06, Douglas Little <doug694@xxxxxxxxxxxxxx> wrote:
Btw. Main advantage (or disadvantage?) of the Python UI is that its
GUI (settings for Hatari etc) can be used while Hatari is running,
it doesn't pause Hatari. It also has GUI for setting Hatari trace
You can run the Python UI with "hatariui" command.
Will give it a try thanks.
When this occurs (either by using the QUIT button, or hitting the red
window X), the 'hatari' process is terminated and no longer in the
If the process owning the window has gone away, it cannot be
the source of this problem. The problem is with your desktop,
or X server, and probably happens also with some other SDL programs.
I might try some other programs but trying not to bloat out the VM too
much before I export it.
The window however retains the last image shown (usually the TOS
desktop or SDL UI) and can be dragged around and minimised as if its
alive. It can't however be closed.
Which desktop environment you're using? Sounds like its
compositor is broken.
Ubuntu 16.10 + unity desktop.