On Mon, Feb 14, 2011 at 10:28 PM, Matthias Clasen <matthias.cla...@gmail.com> wrote: > - Why does this belong in gdk ? > It's in GDK for now because that's where gdk-pixbuf comes from. And as I'm targetting GTK and didn't want to work on two git checkouts while playing with it, I stuck it into gdk. Emmanuelle asked about possibly using it for Clutter. So it's probably useful to split it into its own package just like we did with gdk-pixbuf. It also depends on how
> - It seems to be somewhat stuck in an uncomfortable place between a 'dumb > pixel > area' (GdkPixbuf) and a 'smart active image' (resizable, possibly > animated, draws itself) > Could you elaborate on the "uncomfortable"? It seems a rather nice place to be from my way of looking at things. The only reason why it's a somewhat ugly place is that conceptually, you're used to think of images as one of those two examples. > - How does this relate to cairo surfaces ? If pictures are the one > true way to pass pixel > data to gtk, do we need a picture that wraps cairo surfaces ? > Well, a picture that wraps a cairo surface is basically just boilerplate code (set_surface and get_surface API and implementing the ref_surface vfunc). http://git.gnome.org/browse/gtk+/tree/tests/testpicture.c?h=picture has it at the top. So it's easy to code yourself if you need it. Also, from my experience with all the rendering things, almost nobody needs that functionality. People don't use cairo surfaces, they use "the image loaded from a file" or "the icon". And the code has pictures for that. > - Making the pictureloader both be a picture and have a picture seems > unnecessarily confusing. > Yeah, I'm not sure about that API yet. What you want is 2 things: 1) picture_new_from_uri() 2) nonblocking And picture_new_from_uri() needs to return an object immediately so you can stuff it into the widget of your choice. You don't want the typical gio behavior with having to wait until the async callback gets called and you can call load_finish() to hand you the final image. But you might care about the resulting image and whether it implements interfaces like animatable (gif) or resizable/stylable (svg), so you need to provide a picture and can't just make the loader picture implement all of these interfaces. I'm not happy with the API but couldn't come up with a better one. And I think people want the ability to stuff flickr images by URL into an iconview without blocking. (I suspect they'd use webkit for that today?) Benjamin _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
