Jason Tackaberry wrote: > 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.
Agreed. Duplicate code is a bad option. > 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. Or it is inside mevas (or whatever). > 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. Is it up-to-date. Last time I checked it, it was very old and doesn't look supported anymore. > 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. I guess that would be the best choice for the gui problem. So let's say out umbrella is called foo. We would release foo-pyimlib2 and foo-pyepeg. Or pyfoo-imlib2 and pyfoo-evas. Whatever foo is. Maybe add everything into one project, so imlib2 would be in foo.Imlib2 and pyevas foo.evas. The 'umbrella' would contain the wrapper (imlib2, evas, 'glue') and a higher level mevas like canvas api. >> 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. I know, I will think of something when I have some time to do this. > 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. Nice idea. >> 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. Yes. Why only add support for image thumbnails? A thumbnail module should also support id3 tags and even video thumbnailing. But I'm not sure how to do this and if it should be inside the the gui umbrella or mediadb. >> 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" :) If you make a similar interface, I have no problem with it. Basicly it is similar, there are container and image objects. That's all I need for starters. > Does directfb support dxr3? Because evas has a dfb engine. No, DXR3 isn't supported at all. Someone wrote bad SDL bindings for the DXR3 and made it work. It isn't really supported by Freevo but would be nice to have. But evas has memory out, right? So that's all we need to write our own display modules. More or less, the pygame display only copies the memory to sdl. >> 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? Right. Evas and Imlib2 don't work with Windows. So I want at least some sort of fallback. Maybe someone else could 'fake' evas and imlib2 using pygame or something else. >> 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. You have Freevo cvs access and this includes www access. Log in at freevo.sf.net and go into /home/groups/f/fr/freevo/htdocs (or similar). Dischi -- Fast, cheap, good: pick two.
pgpGZiMPwE8go.pgp
Description: PGP signature
