On Sat, Feb 16, 2013 at 01:13:03AM +0100, Raphaël Droz wrote: > Hi, > > first, thank you for the review ! > > On Sun, Feb 10, 2013 at 09:52:59PM +0100, Marc Lehmann wrote: > > And a few major things: > > > > - gdk pixbuf xlib bindings must not be used (they are unmaintained and > > often cause black or garbage images on anything but 24 bit depth). > > There is the rxvt_img api which should be used instead. > > This is probably the only thing I'm sorry to argue about: > > I did some preliminary attempts using the raw xlib and use of rxvt_img > api but I must admit it was hard and time-consuming [no offense here, > just my small experience, and some impatience]. (but to be exhaustive, I > even tried Cairo). > When I finally found gdk_pixbuf_new_from_file*() and > gdk_pixbuf_xlib_render_to_drawable() and got them working in a couple of > minutes I considered them as a godsend. > These functions behave exactly how I'd expect from a nice image library. > It'd be sad to do without such a great help.
You can clearly use gdk_pixbuf_new_from_file, as it is not part of the xlib bindings. Concerning gdk_pixbuf_xlib_render_to_drawable, see rxvt_img::new_from_pixbuf for an example of how to copy a pixbuf to an XImage. But as Marc said, the best would be to reuse the rxvtimg api. > 1) could you point me to any reference on gdk pixbuf xlib non-maintenance ? > According to gdk git log [1] that code is still updated in latest releases. > Moreover gdk_pixbuf_xlib is always part of gdk-pixbuf in all > distribution packages. Wrong log. The right one is http://git.gnome.org/browse/gdk-pixbuf/log/contrib/gdk-pixbuf-xlib And see https://bugzilla.gnome.org/show_bug.cgi?id=631837 for an example of a bug that I reported in 2010 (including a patch) and which is still not fixed. > If I correctly understood Gtk evolution, gdk pixbuf xlib deprecation > _would_ implies at least one of: > A) gtk-xcb [2] is ready to takeover (seems not) > B) cairo (xcb) is ready to takeover Gdk API's X11-backend part (is it ?) You confuse gdk x11-backend with gdk-pixbuf xlib bindings. > 2) don't you think that bugs related to different screen depth should > be, as much as possible, fixed there, with the objective of a sane and > long-term approach, rather than trying to workaround them specifically > in urxvt ? While I don't know a lot about GDK, I can't believe gdk-x11 > to be definitely hopeless in this regard. Ditto. > Still talking about a C-based implementation, and about the structure > ("rxvt_img api"): do you mean that rxvt_img should be extended (flags, > filename, ...) and then a vector of rxvt_img should be preferred to the > current vector of _InTermImage ? If the rxvt_img api is not good enough for this use case then you could try to extend it yes. Emanuele _______________________________________________ rxvt-unicode mailing list [email protected] http://lists.schmorp.de/cgi-bin/mailman/listinfo/rxvt-unicode
