On Sun, 2005-07-10 at 13:21 +0200, Dirk Meyer wrote: > I now connected the expose to mevas. Maybe the window class should > remeber the image and handle expose itself? Maybe not. The input
Imlib2.Display supported that. But I think handling expose events belongs at the canvas level. > handler for X11 is connected to freevo, that's ok. You wrote something > about using your signal class here, feel free. It should be in > kaa/base/src/notifier, it has something to do with notification. When > you add your signals.py, you need to rename my file with the same > name, handling possix signals. Or you rename your file. :) The class name is Signal, but signal.py obviously conflicts with the global signal module. What I did in mevas was put it in utils.py along with getch and utf stuff :) Kind of hackish but hard to come up with a good solution short of renaming the class. (And the class name is apt, since they're almost exactly analogous to gtk signals.) > And when we have to kaa.evas, were do you put the "display" code for > framebuffer and directfb? I guess inside evas is good idea. If I use > evas with fb/dfb, I should need to install kaa.display at all. The short answer is because fb/dfb is "display stuff." For the same reason the X11 stuff is in kaa.display, so should dfb stuff be. Evas's support for these engines requires something glues the display to the evas engine. Currently, that something is EvasWindow in kaa.display. It should probably be called EvasX11Window. And dfb stuff would be EvasDFBWindow. Another thing I tried to do but didn't test was make kaa.display compile without Imlib2 installed. It should be possible to use kaa.evas and kaa.display without imlib2, for example. Jason.
signature.asc
Description: This is a digitally signed message part
