[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [pygame] event object
Pete Shinners <shredwheat@attbi.com> writes:
> Michael Hudson wrote:
> > Then, from somewhere, you have a wide unicode build. You need to either
> >
> > (a) get yourself a narrow unicode build
> > -or-
> > (b) recompile pygame against the wide build you have installed
> >
> > (a) can probably be achieved by going to http://www.python.org/2.2.1/
> > and downloading the RPM and (b) is presumably a matter of downloading
> > the pygame source and running "python2 setup.py install".
>
> michael, impressive insight here, glad you knew what this was all about,
> because it had me a bit puzzled.
It's been a problem waiting to happen for a while (not specifically
wrt. pygame). This is the first time I've seen it in the wild
(probably because this is the first time a wide unicode build has had
wide distribution).
> i've got a couple questions about it though.
Ah :)
> is there any way i could provide binaries that worked for both types of
> unicode? i assume not.
I don't think so.
> here is the line of code in event.c that i'm sure is
> the problem..
>
> insobj(dict, "unicode", PyUnicode_FromUnicode(
> (Py_UNICODE*)&event->key.keysym.unicode,
> event->key.keysym.unicode > 0));
>
> this is translating the "unicode" value from the SDL event to the pygame
> event.
Careful; doesn't this assume sizeof(Py_UNICODE) == 2? That's exactly
what's not true in a wide unicode build.
> to make things interesting, i have some crazy macros defined that
> allow this code to compile on "pre-unicode" versions of python.
>
> #define PyUnicode_Check(text) 0
> #define PyUnicode_AsUnicode(text) text
> #define Py_UNICODE void
> #define PyUnicode_FromUnicode(p,c) PyLong_FromLong(*(short*)(p))
>
>
> perhaps instead of calling the "C" versions of this function i could do the
> work on the python side? something like
>
> PyUnicode_FromObject(PyString_FromString((char*)&event->key.keysym.unicode));
That won't work. PyUnicode_FromObject gets the magic API renaming
trick done to it. Not sure why, mind.
> or even something magic like this?
>
> PyObject *temp = Py_BuildValue("(u)", &event->key.keysym.unicode);
> PyObject *unicode = PyTuple_GET_ITEM(temp, 0);
> Py_INCREF(unicode);
> Py_DECREF(temp);
That might compile, but I doubt it will work.
What encoding does event->key.keysym.unicode have? ucs2?
Something like
PyUnicode_Decode(&event->key.keysym.unicode, len, "UCS-2", NULL);
*ought* to be the ticket, but PyUnicode_Decode gets involved in the
API renaming scheme too. I think I'll complain about this on
python-dev. Not that getting it changed will help in the 2.2
timeframe...
Wild hacks like finding the builtin "unicode" object and
PyEval_CallObject-ing that may be your only hope.
> unfortunately i'm not too framiliar with the unicode stuff in python, i
> suppose i'll need to dig into the source and see if i have an option?
> seems like a lame thing to require two versions of pygame binaries for.
> anyone have any insight as to why redhat would use different than default
> unicode chars?
No. It's interesting though.
Cheers,
M.
____________________________________
pygame mailing list
pygame-users@seul.org
http://pygame.seul.org