Jason Tackaberry wrote: > On Mon, 2005-06-13 at 19:31 +0200, Dirk Meyer wrote: >> pyevas which should only be python wrappers for evas. That's fine. We >> have pyimlib2 as imlib2 wrapper. The point is: pyimlib2 has stuff that >> doesn't belong there. But instead of changing the name, what about >> moving it somewhere else? Mevas may be a good start. > > I'm kind of torn. I do partly want to keep the name because it's at > least obvious what it does. But I also kind of like the Display class > in pyimlib2. It's a simple convenience class. I can foresee people who > want to use pyimlib2 will want the ability to quickly throw something > into a display and adding another dependency would be annoying.
Part of the display code belongs to imlib2. I don't have a problem with a wrapper adding some extra functions. The main part is imlib2, so we should name it like that. The colorspace conversion is also not 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). > As for the fdo thumbnail code, I think a good image library _should_ > be able to handle thumbnails. I might be inclined to leave that > code there no matter what. 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. > So in the end, maybe our answer is keep the current name and keep the > current code, but try to be conscious about feature creep. OK. >> In the future I want pyevas integrated into mevas to have one >> powerfull image handling and drawing module. > > I'm still not quite sure if mevas and pyevas are compatible > architecturally. I could make a mevas-like API on top of pyevas, but it > would be missing some features (like draw_mask()) since evas doesn't do > that (yet). Making mevas work with pyevas will probably require > considerably rearchitecting mevas. 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). > Probably the best we could do currently is use Evas's image object's > exclusively and all of mevas's canvas objects directly onto that. > But then we're not really using Evas for anything but display. I'm not sure. I would like to have one powerfull canvas lib depending on nothing directly. We could use imagelib/display = pygame/pygame or imlib2/dxr3 or evas/evas. Even DirectX/DirectX. > For MeBox, I'm actually less interested in mevas nowadays (ironically). > I don't have any backward compatibility requirements that you do, so I > can keep the architecture of whatever solution I devise to be reasonably > simple. 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. > My plan was just to build a nice API like mevas's (only a bit > better, since I've learned from mevas) on top of pyevas, and use Evas > for all display. Trying to graft pyevas into mevas as it is now is a > challenge I'm not particularly motivated to sign up for. :) Fine by me. I want a good canvas module. But it should depend on pyevas. > Whatever we decide about pyimlib2, I want to do a release soon, and post > it to Freshmeat. I want to do some more documentation, do some > examples, and make a web page, and try to get this project some more > exposure. Because even though it's not complete, I think it's quite > useful as it is (clearly!). See http://sault.org/pyimlib2/ which is > just pydoc output. But already there is some reasonable documentation, > which we get for free from well-commented source. :) Agreed. What do you think of http://freevo.sf.net/pyimlib2? > After that, I'll submit vf_osd to the MPlayer guys. It's pretty much > done and cleaned up and not embarrassing to submit anymore. :) But I > get my fingers into some areas of MPlayer that I think they're not going > to like, so it will benefit from some review. > > And after that, I'll turn my attention back to pyevas. Great. > One problem is that pyevas and pyimlib2 are such obvious names, I'm not > the first one to make projects with those names. No freshmeat entries > for those names, however. The obvious name is a good thing. So feel free if you want to make a release. We could put it on the freevo sf download page and the doc in a subdir at the freevo webpage. Dischi -- I just got lost in thought... It was unfamiliar territory.
pgpNp2ba8JH2v.pgp
Description: PGP signature
