Re: [AD] Allegro 5 TODOs (from wiki)

[Evert Glebbeek <eglebbk@xxxxxxxxxx>]

On 4 Dec 2008, at 12:19, Peter Hull wrote:
> I think Apple have failed to make this very clear, but while Carbon is
> their name for all the C api for OS X, there's 'good' Carbon (i.e the
> CoreXXX libraries) and 'bad' Carbon (the compatibility stuff from OS
> 9). I believe it's only the latter that isn't making it to 64 bit - it
> would be very odd if, for example, CoreGraphics wasn't available on 64
> bit.

They don't make it very clear, no, although I am aware of the  
distinction. I always find myself wondering which part of Carbon is  
safe to use and which part is not.
Anyway, in this case, my reason for making the change was mostly that  
the rest of the code also uses Cocoa (and as alittle exercise for  
myself).

> The other thing I thought about and ran away from is that screens are
> supposed to be 'plug and play', so what happens if someone connects or
> disconnects a monitor at the wrong time? I know that the
> CGDirectDisplayID is supposed to be a unique(ish) ID that stays with a
> certain monitor even if it's not connected, rather than an index.

That is a tricky situation. Consider the following scenario/setup:

user has two displays connected
Program detects both displays, selects the second one as the "active"  
display, then pauses
user disconnects second display and connects another one, then  
resumes the program

What should happen? I would expect the program to use the newly  
connected monitor as the second display and "forget" about the  
previous second display - so in this case the unique ID is useless.  
However, in the case that

user has two displays connected
Program detects both displays, selects the second one as the "active"  
display, then pauses
user connects a third display one, then resumes the program

the program should still use the original second display and not  
randomly decide that the new third display is "the second". I don't  
know if that's guarenteed or not in the "screens" array. If it is  
we're fine, if it isn't... well, we could do it ourselves: make a  
list (vector?) of displays connected when the program starts and  
catch display connect/disconnect events and update the list  
accordingly: new displays go at the back of the list, disconnected  
displays are deleted from the list.

There's also the question of what to do if a display is disconnected  
while it's in use. I have no idea what would normally happen to  
programs displayed on the second display in this case, but we may  
need to do something sensible (maybe sending "window closed" messages  
from all windows on that display is good enough) if the alternative  
is for the program to crash.

> I'll check the patch as soon as I can, it looks OK though.

Cheers.
Do you think it makes sense to put it in before 4.9.7 comes out? In  
case we may want someone to test it for us?

Evert