Well, I will report two bugs really. The first one is the most
important, you have very good code to handle multi-threading, but you didn't
thought in the posibility of one only process reentrant, did you?
I've a GTK application that has a ggi_visual inside it (-inwin
rules). All seems to work nice, the GGL sprites walk through the screen as
they should. First problem, ggi doesnt receive events from this window. I
tried to simulate the expose_event with ggiEventSend, but it doesn't seem to
work. Well this isn't the bug I'm surely doing something wrong in this. To
avoid this, I catch with GTK the expose event and instead of simulate the
gii one, I do myself the ggiFlush. But GGL uses alarms to synchronize with
the required framerate, and gtk don't know well what uses, but its the same,
when I call ggiFlushRegion from gtk it can be drawing a BIG area, which
takes a bit, and if in this moment the GGL alarm signal is received, the
ggiFlushRegion is interrupted to do �other ggiFlushRegion!. You then assume
that there is another process accesing the visual and lock the process. But
there is only one process reentrant!
Is this really a bug or am I doing another thing wrong? If it is,
it would help me a lot if you fix it as soon as possible. I can use tricks
to avoid this while developing in my house, but I can't distribute the
program whith this tricks...
And the second bug, is that when I call ggiClose, if the visual is
an X-Window, it closes the window ALWAYS, even if the window isn't created
by ggi (-inwin). So I can't call ggiClose and I'm losing memory each time I
close a gtk window that contains the ggl widget. But this bug doesn't worry
me much, the other one is much more dangerous.
Thanks
--
_
/_) \/ / / email: mailto:[EMAIL PROTECTED]
/ \ / (_/ www : http://programacion.mundivia.es/ryu
[ GGL developer ] & [ IRCore developer ] & [ GPUL member ]
