Jason Tackaberry wrote: > Right. I think having an umbrella project solves a lot of our problems, > because if we want a small module just for fdo thumbnails, we can toss > it in there.
Yes, Freevo contains some stuff that may be very usefull for other apps, too. So some sort of umbrella is a nice idea. And you working on mebox could use the same umbrella toolkit. > As for what to call it, well that's up for debate. :) How about 'smart' > for "Shared Media Application Toolset Repository". And when people > point out that the T and R are transposed, we can tell them to stop > being so smart. :) Something like that. I had pygul in mind (Python Graphic Umbrella Library) :) OK, ideas everyone! > Our "glue" or display library will be something like ecore, only much > simpler I think. We'd use it to create new X11 windows that Imlib2 can > render to, or X11 windows with evas canvases (like > ecore_evas_software_x11_new()). > > So we have a list of modules under this umbrella project. imlib2, evas, > display, thumbnail (fdo stuff), canvas (mevas successor), some helper > utils, etc. If we keep the umbrella generic enough (i.e. don't limit > just to gui stuff) we can through in pretty much whatever we want. > Maybe even beacon, if I ever get time to work on it. :) Not only GUI stuff, sounds ok to me (but pygul is wrong then). I want to create a nice library for python with cool stuff shared between projects. > And things can be kept reasonably modular. i.e. pysmart-imlib2 should > be able to be installed by itself with no other dependencies (except for > Imlib2 of course). Agreed. > Here's where we're going to disagree, because you have existing > portability requirements. I would want to have an architecture like > this: > > Application > | > Canvas -- Imlib2 > | / > Evas --/ > +---|----+ > | | > Buffer +--> X11, GL, Framebuffer, etc. evas engines > | > ivtv, vf_osd, basically anything else > > > What we have here is an architecture were Evas isn't separable, but that > means, if Evas actually doesn't work on Windows, this library stack > won't work for Freevo. (Or is Windows portability actually a project > goal? I don't really know. But it isn't for MeBox.) First of all: I don't care about Windows. It is no goal for Freevo but it may be a nice to have. If it is not possible, it is no problem for me. But your design still works with evas missing. Just create something for windows with the same API as pyevas and replace it. Or patch evas to make it work with windows. Either way, people who want to use Freevo with Windows need to think about it. I won't drop the nice evas support only for a possible windows Freevo in the future. > Making Canvas not depend on evas really complicates development. > Abstraction is good in places, but when you start abstracting every > level of the pipeline, things start to turn into a real brainfuck. Let us ignore Windows for now. I also think of moving some high level gui stuff from Freevo into the toolkit. Possible stuff are the widgets as high level canvas objects and the animation module. >> > 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. > > I'll see if I can make it work then. If no POSIX shmem support is > available, it'll fall back to writing the file to /tmp or something. Sounds great. >> 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. > > Yeah, it would have the same general architecture, though canvas objects > would probably map to evas objects, so you'd have Image, Text, > TextBlock, Gradient, Rectangle, etc. Maybe a Bitmap object, which would > tie into Imlib2 so we could take advantage of some imaging stuff in > pyimlib2 that evas doesn't have yet (like draw_mask), but you lose some > other flexibility of the Image object. (What I just said might not make > any sense at all; I haven't thought it through.) Don't think too much. Let's try. It would be great if you could put pyevas into Freevo cvs so I can play with it to see the speed and test some nice effects for the future. >> 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. > > Yep. Evas has a buffer engine, which I use for vf_osd. The buffer can > be stored in BGR24 or BGR32 (although for that your evas would need to > be patched with my BGR32 patch -- I'd submit that patch upstream but I > don't know enough about evas to feel confident about it). So evas can output to mplayer bmovl by using the buffer. That's all I need. Dischi -- "There is no reason for any individual to have a computer in their home." (Ken Olsen, Pr�sident von DEC, 1977)
pgpYbMelgRq1K.pgp
Description: PGP signature
