| Re: [AD] X11 unresponsiveness |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
Elias Pschernig wrote:
Well, my view is a bit different. The _private doesn't mean it is
private in file scope, but private with regards to the X lock.
Actually, what I think the _private bit may mean is pretty much what
private does for C++ classes.. eg. _xwin_private* functions/variables
can/should only be accessed by _xwin* functions. Either case, I don't
think it'd be a bad idea to create a function to encase the
if(_xwin_input_handler) function pointer check in, and call that from
XUNLOCK.
About 4.0.x compatibility,
I really don't know. I was under the impression only global symbols can
have an effect on ABI compatibility (but probably I'm wrong).
AFAIK, that's right. Whenever you change/add/remove global (non-static)
functions or variables, ABI compatibility is broken for DLLs.. however,
I can't say if .so's have the same restiction.
Yes. But the thing is, we have a very small patch, which actually
improves the signals version a bit. So I see no reason to not apply it.
Admitted, the improvement does not affect the general problem. But
actually *requiring* polling would be a big step.
Alright, I can concede this. However, if you do it, and it works, that
would leave the question open as to whether the *_needs_poll functions
should return TRUE or FALSE.
So, my view is, *encourage* using polling by
stating it in the docs, and adjusting all the examples to query the
driver if polling is required and do it in that case.
I thought this was already done, actually. I know the docs already
encourage checking the *_needs_poll function and to call poll_* if it
returns true.. and I thought the examples followed this. If not, then
that's definately something that should be fixed regardless. The
examples should show proper coding behavior.
- Kitty Cat