[B2-devel] Re: OS X -

[Max H. <ma...@qu...>]

At 10:46 Uhr +1000 12.10.2001, ni...@in... wrote:
>...
>>  What I would like to suggest is that we add a singleton
>>  EmulatorManager class that keeps track of the Emulator object (and in
>>  future versions, manages multiple). This would be a singleton class,
>>  similiar to NSApplication, i.e. you could call [EmulatorManager
>>  sharedEmulatorManager] to get the single instance.
>>
>>  This would then have some useful methods, like IsAnyEmulatorRunning
>>  (i.e. active and not paused) or something alike.
>>  Furthermore, it then would have a method to check if the emulator in
>>  the current key window is running (and not paused), and if that is
>>  true, then we don't intercept key events.
>
>	This would be an ideal situation. Even better would be
>if this class could check if the pointer is in the EmulatorView,
>and not send any events to it if it is not.
>
>	As an interim, how about we just pass all key events to
>the Emulator class, and ignore any OS defaults.

That would be bad. E.g. the small window widgets (close/mini/zoom) 
would not be highlighted, no buttons would work and no menu shortcuts.

Your really have to decide what events you want to handle yourself, 
and the rest you one should feedback into the regular handling.


>  That way, there
>is no need to check if an emulator is running. From memory, the
>EmulatorView will do the right thing (ignore) when it gets an
>event, and its emulator is not running. If not, should be simple
>to add.

See above :) That is the reason why I right now have only the key 
events intercepted, that doesn't hurt me much.

How about this: we add a method to Emulator (or some other class) like

- (BOOL)tryHandleEvent:(NSEvent *)event;

Then, our Applicaton class would have this code:

- (void)sendEvent:(NSEvent *)event
{
	if (![emulator tryHandleEvent:event])
		[super sendEvent:event])
}

I.e. this way the decision logic would be inside of the Emulator 
object... or the EmulatorManager or where we put it.



>
>...
>>  BTW, Nigel, how is speed for you? On my G4/400, running Sys 7.5.3 in
>>  the emu, I can literally see it do redraws etc.
>
>	Same speed deficiencies. I haven't worked out if it is
>the graphics environment (e.g. the barber pole, and having to
>have the MacOS blit from an NSBitmap), or the emulation on a
>RISC processor. I do remember that it was also quite slow on
>my Sun Sparcstation 5 at work.

Don't forget that you also have double buffering on from the MacOS, 
which in our case doesn't really help - turning on retained mode for 
the window might help.

>
>	It is fast enough to be usable in a pinch, though.

Well if you compare it to the same version of Basilisk (latest 
release snapshot) but compiled with an X11 front end, it is quite a 
bit slower - this tells me we have a lot to improve :)

BTW, I managed to modify your code to make it run with Basilisk CVS!!

It works slightly better than using that CVS code directly - instead 
of staying black, the screen turn into black/white stripped, but then 
again nothgin happens :/


>
>
>
>>  P.S.: do you happen to know a Cris Pearson from Tasmania? :)
>
>	Nope.
>(which, considering the small size of Tassie, is surprising :-)

LOL :)


Max
-- 
-----------------------------------------------
Max Horn
Software Developer

email: <mailto:ma...@qu...>
phone: (+49) 6151-494890