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

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


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




Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/