On Fri, Feb 08, 2013 at 05:12:36PM +0100, Raphaël Droz <[email protected]>
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
--==---/ / _ \/ // /\ \/ / [email protected]
-=====/_/_//_/\_,_/ /_/\_\
_______________________________________________
rxvt-unicode mailing list
[email protected]
http://lists.schmorp.de/cgi-bin/mailman/listinfo/rxvt-unicode
