On Mon, 2005-06-13 at 19:31 +0200, Dirk Meyer wrote: > Maybe pyimlib2 is the way to go. Let's think about it. You also have
Maybe it is. > 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. 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. 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. > 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. 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. 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. 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. :) 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. :) 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. 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. Jason.
signature.asc
Description: This is a digitally signed message part
