Dirk Meyer wrote: >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. > > > >From my limited experience getting the basic Freevo 2 running on Windows, I must confess a little confusion. From what I could gather, the code was heading in a nice direction of abstracting the Canvas and Image interfaces - through mevas - and implementing them with different backends - imlib2, pygame, etc. The major issues related to the imaging stuff I ran into were the missing thumbnail methods in the Canvas/Image interface (the main Freevo code was using imlib2 directly) and the missing Canvas and Image method implementations in the pygame backend.
So basically my vote would be for a clean Canvas, Image and Buffer abstraction which is used by the main Freevo code, through the mevas layer. Then different backends can still be used and you are not tied to any particular platform. It may be a little more work, but it seems better in the long run. >>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. > > > I would ask that you not ignore Windows, but at the same time you don't have to worry about the port. I would simply ask that you keep in mind that there may be various backends written in future and design with that in mind. I think a little abstraction can go a long way. >>>>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 > > Tyler -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.6.9 - Release Date: 6/11/2005 ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ Freevo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freevo-devel
