[patch][RFC] display images *inside* urxvt

Marc Lehmann schmorp at schmorp.de
Sun Feb 10 21:52:59 CET 2013


On Fri, Feb 08, 2013 at 05:12:36PM +0100, Raphaƫl Droz <raphael.droz at gmail.com> wrote:
> The attached patch intends to add support of image display inside urxvt.
> Of course urxvt is already fully capable of displaying images as
> backgrounds. But images "inside" the terminal window were not.

Well, I am sure they would (at least by integrating some interface intot
he background extension:), but it's not immediately obvious how to do it.

In general, this is the kind of thing I do envisage for urxvt in the
future. Your patch is also quite thoughtful (for adding configure
switches for example).

There are a few minor things that would need changes:

- the existing codign standard would need to be followed
- _InTermImage is a reserved identifier in c++
- no new Rxvt_* OSC extensions should be added, as obviously, rxvt
  doesn't have them and they clash with xterm - it should be
  from the URxvt_ space.

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.
- we don't want to set the OSC in stone.

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.

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.

That would have multiple advantages:

- bugs or imperfections are not as important - the bar for inclusion
  of a perl plugin is much lower, as it is optional.
- being optional (and off by default) has obvious security advantages as
  well.
- it wouldn't set the OSC in stone, so allows for different forms of future
  expansion.
- it would avoid magical fear of core-bloat (also called "mikachu feelings").

> === 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).

> * 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.

> ( 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.

> +++ b/doc/images.txt

This would, in the long run, have to move to rxvt.7.pod (unless it becomes
a perl extension, in which case it can just be mebedde dinto it).

-- 
                The choice of a       Deliantra, the free code+content MORPG
      -----==-     _GNU_              http://www.deliantra.net
      ----==-- _       generation
      ---==---(_)__  __ ____  __      Marc Lehmann
      --==---/ / _ \/ // /\ \/ /      schmorp at schmorp.de
      -=====/_/_//_/\_,_/ /_/\_\




More information about the rxvt-unicode mailing list