On Tue, 2005-06-14 at 18:06 +0200, Dirk Meyer wrote: > Part of the display code belongs to imlib2. I don't have a problem > with a wrapper adding some extra functions.
Ok, thinking aloud here ... I recently took out the pygame code from pyimlib2 and put it into a separate module. Basically this module acts as glue between pygame for display, and pyimlib2 for images. What we're talking about now is glue between X11 and pyimlib2. It happens that pyevas needs the same kind of glue. Currently I've got a bunch of code duplicated between pyevas and pyimlib2. Obviously this sucks. So how about a new library, called, well, whatever -- pydisplayglue -- that supports glue between A and B, where A in (X11, pygame, pygtk, etc.) and B in (pyimlib2, pyevas). This ends up being a bit of a kitchen sink library insofar as it will support a bunch of different libraries and will need compile-time enabling/disabling of what it supports. But then at least we have a separate module for our display-specific junk, and we're not duplicating code. This would be a library that mevas (or whatever its successor is) uses directly. I also discovered last night there's another project called pyevas. Always annoying when that happens. :) It's a bit more feature complete than my bindings, but also lacks support for stuff I need. But I don't quite like how it's put together, so I'm not ready to abandon my code because some other project beat me to a release. :) But I'll have to think about a new name so as to avoid a conflict. I imagine this is a typical problem for third party bindings of a library when said library has no official bindings :) We could prefix or suffix this family of libraries with some unique identifier. Or use python-foo rather than pyfoo. Shrug. Perhaps we want to find a name for an umbrella project for these libraries and use that in a namespace to avoid conflicts. > part of imlib2, but it belongs into pyimlib2. The same for the feature > I want to add about reading images in buffer (we talked about that in > irc, dumping the file and read it again). There's no way I can see to make Imlib2 load a compressed image from memory, so whether or not pyimlib2 implements it or mevas or whatever, it's going to have to write to a temporary file and pass the filename to Imlib2. Now, in theory, if the system supported POSIX shared memory, it could write that to shared memory and give Imlib2 a filename like /dev/shm/foobar.jpg. That's an interesting kludge; the data would never touch the disk in that case. That would have to be in pyimlib2's C module. > The second idea may be to move the code into the mediadb. Creating > thumbnails should be part of that. The mediadb could also create > thumbnails for audio files with image id3 tag and video files by > creating a snapshot. I think if fdo thumbnail stuff is in a more base library, people will be more inclined to use it than to roll their own. But architecturally it may make more sense in mediadb/beacon/whatever. > I have no problem with changing mevas. There is no release yet, so I > could change stuff again. I want both because maybe we have display > engines not using evas (e.g. windows output or dxr3 stuff). When I said "change" I basically meant "rewrite" :) Does directfb support dxr3? Because evas has a dfb engine. > I also don't need backward compatibility. It would be nice to have, > but changing some parts for a better system sounds ok to me. For MeBox, I'm not trying to please everyone. What that basically means is, I'll use evas, and if evas doesn't support your hardware, then you don't use MeBox. :) But you kind of _do_ need backward compatibility in terms of what you support. Like, Freevo 1.5.x supports dxr3, and you want to make sure Freevo 2.x supports that too. > Fine by me. I want a good canvas module. But it should depend on > pyevas. Should not, you mean? > Agreed. What do you think of http://freevo.sf.net/pyimlib2? Fine by me, as long as I have write access to that. I'll want to maintain a web page. Jason.
signature.asc
Description: This is a digitally signed message part
