On Wed, 2005-06-15 at 16:28 +0200, Dirk Meyer wrote: > Is it up-to-date. Last time I checked it, it was very old and doesn't > look supported anymore.
There are other bindings, but this one is part of the edesklets project: http://sourceforge.net/projects/edesklets/ > 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. 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. 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. :) 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. :) 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). 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.) However, if Evas builds on Windows, you could use the evas buffer engine an use something like pygame strictly for display. But either way evas is there. 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. > > 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. > 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.) > 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). > 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). Ah, so you're right. Cheers, Jason.
signature.asc
Description: This is a digitally signed message part
