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 ]
