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.
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.
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 ?)
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.
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 ?
> - we don't want to set the OSC in stone.
ack
> A much more acceptable solution would implement the OSC as a perl
> extension (making it truly optional). Ideally, all that would be needed in
> the core would be some refresh hooks, and possibly a way to store metadata
> for lines, or a "renumber" hook.
Does it mean (in the case of a perl implementation), that pixbuf should
live fully in the perl context ?
Indeed Gtk2::Gdk::Pixbuf bindings contain render_to_drawable(), it _may_
not be impossible to grab or build a Gtk2::Gdk::Drawable.
(maybe gtk.gdk.window_lookup($term->vt) could return a valid Drawable)
In such a case only some hooks (and line hinting) would be added into core code.
Otherwise, if pixbufs are kept inside core code, and a kind
register_image() would exist to allocate an _InTermImage (or a
rxvt_img). But I'd have difficulties to imagine exactly which parts
would be worse urxvt and which ones would belong to the perl extension.
> A generic framework to customise drawing of rectangles in the core (where
> an extension would tell the core it would use a certain rectangle on
> screen, and urxvt would invoke the extension when a redraw is needed)
> might also be quite useful, similar to the existing overlay code. In fact,
> the overlay code and this could possibly be merged.
> Alternatively, a custom rendition flag could be used to indicate
> "specialness" and an extension would set these flags on the desired
> rectangle.
This touch urxvt internals, and I let the choice of the "hinting
strategy" to your discretion.
My first opinion is that keeping a per-line hint ("metadata for lines")
(altering the line_t) is apparently simpler and enough than altering at
the character level (new rstyle for the rend_t).
But line numbering changing across resize could make custom rendition
flag (rend_t) preferable if this is more consistent.
This choice will likely have consequences on the critical part (partial
or full-refresh) in scr_refresh().
> > === The patch *is* usable, but there are ===
>
> Of course, these should be fixed as well (unless it were a perl extension,
> for which it would be entirely fine not to be complete).
Although I take note that a full-C implementation isn't inherently an option
you'd reject, you'd prefer as much code as possible to leave in perl.
I could either try to move incrementally more parts to perl, especially
pictures_parse_params(), set_pos() and set_cursor() to begin with,
either rewrite a full Gtk2::Gdk::Pixbuf-based implementation.
I'll try to give a look at the later but I can't say I could come up soon
with something workable (to anyone: feel free to preempt me)
> > * one issue in resizing (more specifically when terminal's height changes).
>
> Resizing is an interetsing problem - if text around images is allowed,
> then doing it properly would require reflowing text around images, which
> is quite a big project imho. Can't imagine anything simpler to do the job,
> though.
Instead of linking to one of libcss, libcroco or ccss I tried to define
a limited set of presentational flags and didn't took into account text
flow.
But more seriously, having images stuck to EOL (not talking about LtR)
is useful and _could_ be common enough. That was the only dose of
positioning complexity I took (IMG_WRAP|IMG_EOL) but even that one was a
bit too complex for now.
> > ( I also considered grabbing the filename from X/mouse [drag & drop or
> > copy-filename-on-click] but didn't found a viable solution yet )
>
> One could always add a "insert image from selection/path in selection"
> menu item.
<seductive>
<gdk/gdkdnd.h> provides a full (non-trivial) XDND-compliant
drag & drop implementation [3]
</seductive>
best regards
[1] http://git.gnome.org/browse/gtk+/log/gdk/x11?h=gtk-3-6
[2] http://sourceforge.net/projects/gtk-xcb/
[3] http://git.gnome.org/browse/gtk+/tree/gdk/x11/gdkdnd-x11.c
_______________________________________________
rxvt-unicode mailing list
[email protected]
http://lists.schmorp.de/cgi-bin/mailman/listinfo/rxvt-unicode
