Commit dc80e3e2 authored by Nalin Dahyabhai's avatar Nalin Dahyabhai

trap X errors while retrieving the contents of the root pixmap. add.

* src/vtebg.c(_vte_bg_get_pixmap, _vte_bg_get_pixbuf): trap X errors while
	retrieving the contents of the root pixmap.
* doc/ambiguous.txt: add.
* README: update.
* vte.spec: rebuild.
parent cd6c601b
2003-06-03 nalin
* src/vtebg.c(_vte_bg_get_pixmap, _vte_bg_get_pixbuf): trap X errors
while retrieving the contents of the root pixmap.
* doc/ambiguous.txt: add.
* README: update.
* vte.spec: rebuild.
Tue Jun 3 15:50:38 2003 Jonathan Blandford <jrb@redhat.com> Tue Jun 3 15:50:38 2003 Jonathan Blandford <jrb@redhat.com>
* src/pty.c (n_read): add a missing break in the switch statement. * src/pty.c (n_read): add a missing break in the switch statement.
......
...@@ -19,20 +19,13 @@ ...@@ -19,20 +19,13 @@
illustrates more or less what the widget sees after it filters incoming data. illustrates more or less what the widget sees after it filters incoming data.
* What's missing? * What's missing?
- Accessibility doesn't work right yet. - Accessibility doesn't work quite right yet.
- Chinese and Korean text isn't displayed correctly because we pass it through
iconv() before performing substitutions, and they both use GR characters.
Japanese works because it only uses GL characters, which iconv() essentially
casts to gunichars, where we perform substitutions. Probably we need to break
the text into narrow and wide chunks by performing substitution first (to find
and break out the wide chunks) and then iconv the narrow sets (what's left)
one chunk at a time.
- Mouse hilite tracking isn't implemented yet. - Mouse hilite tracking isn't implemented yet.
- Most control sequences are recognized, but many aren't implemented. There - Most control sequences are recognized, but many aren't implemented. There
are enough to run ls, vim, less, emacs and mutt, but more need to be are enough to run ls, vim, less, emacs and mutt, but more need to be
implemented (ff, i1, i3, is, iP, LF, LO, MC, mh, ML, mm, mo, nw, pf, implemented (ds, ff, hd, hu, i1, i3, iP, is, LF, LO, MC, ML, mm, mo, pf, pk,
pk, pl, pf, po, pO, ps, px, r1, r2, r3, RA, RF, rp, rs, RX, SA, SX, wi, pl, pn, po, pO, ps, px, r1, r2, r3, RA, RF, rp, rs, RX, SA, SX, wi, several
several more from the XTerm set). more from the XTerm set).
- I'm not sure the widget implementation itself is correct. There are many - I'm not sure the widget implementation itself is correct. There are many
changes in going from GTK+ 1.2 to 2.0, and examples of the proper way to do changes in going from GTK+ 1.2 to 2.0, and examples of the proper way to do
things is currently scarce, so some of it's guesswork. things is currently scarce, so some of it's guesswork.
......
Unicode defines width information for characters. Conventionally this
describes the number of columns a character is expected to occupy when
printed or drawn using a monospaced font.
There are five width classes with which we concern ourselves. Four of
these are narrow, wide, half-width, and full-width. For practical
purposes, narrow and half-width can be grouped together as
"single-width" (occupying one column), and wide and full-width can be
grouped together as "double-width" (occupying two columns).
The last class we're concerned with is those of ambiguous width. These
are characters which have the same meaning and graphical representation
everywhere, but which are either single-width or double-width based on
the context in which they appear.
Width information is crucial for terminal-based applications which need
to address the screen: if the application draws five characters and
expects the cursor to be in moved six columns to the right, and the
terminal moves the cursor seven (or five, or any number other than six),
display bugs manifest.
Ambiguously-wide characters pose an implementation problem for terminals
which may not be running in the same locale as an application which is
running inside the terminal. In these cases, the terminal cannot depend
on the libc wcwidth() function because wcwidth() typically makes use of
locale information.
There are basically four approaches to solving this problem:
A) Force characters with ambiguous width to be single-width.
B) Force characters with ambiguous width to be double-width.
C) Force characters with ambiguous width to be have a width value based
on the locale's region.
D) Force characters with ambiguous width to be have a width value based
on the locale's encoding.
Methods A and B will produce display bugs, because they don't take into
account any context information. Method C fails on glibc-based systems
because glibc uses method D and the two methods produce different
results for the same wchar_t values.
So the VteTerminal widget uses approach D. Depending on the context in
which a character was received (a combination of the terminal's encoding
and whether or not the character was received as an ISO-2022 sequence),
a character is internally assigned a width when it is received from the
terminal.
Text which is not received from the terminal (input method preedit data)
is processed using method C, although now that I think about it, the
fact that it's UTF-8 text suggests that these characters should be
treated as single-width.
...@@ -5802,13 +5802,13 @@ static struct { ...@@ -5802,13 +5802,13 @@ static struct {
{"i1", NULL}, {"i1", NULL},
{"i3", NULL}, {"i3", NULL},
{"is", NULL},
{"ic", vte_sequence_handler_ic}, {"ic", vte_sequence_handler_ic},
{"IC", vte_sequence_handler_IC}, {"IC", vte_sequence_handler_IC},
{"if", NULL}, {"if", NULL},
{"im", vte_sequence_handler_im}, {"im", vte_sequence_handler_im},
{"ip", NULL}, {"ip", NULL},
{"iP", NULL}, {"iP", NULL},
{"is", NULL},
{"K1", vte_sequence_handler_complain_key}, {"K1", vte_sequence_handler_complain_key},
{"K2", vte_sequence_handler_complain_key}, {"K2", vte_sequence_handler_complain_key},
......
...@@ -495,7 +495,6 @@ vte_bg_get_pixmap(VteBg *bg, ...@@ -495,7 +495,6 @@ vte_bg_get_pixmap(VteBg *bg,
GdkBitmap *mask; GdkBitmap *mask;
GdkPixbuf *pixbuf; GdkPixbuf *pixbuf;
char *file; char *file;
int width, height;
if (bg == NULL) { if (bg == NULL) {
bg = vte_bg_get(); bg = vte_bg_get();
...@@ -527,17 +526,33 @@ vte_bg_get_pixmap(VteBg *bg, ...@@ -527,17 +526,33 @@ vte_bg_get_pixmap(VteBg *bg,
switch (source_type) { switch (source_type) {
case VTE_BG_SOURCE_ROOT: case VTE_BG_SOURCE_ROOT:
if (GDK_IS_PIXMAP(bg->root_pixmap)) { if (GDK_IS_PIXMAP(bg->root_pixmap)) {
gdk_drawable_get_size(bg->root_pixmap, &width, &height); int width, height;
/* Tell GTK+ that this foreign pixmap shares the
* root window's colormap. */
rcolormap = gdk_drawable_get_colormap(gdk_get_default_root_window()); rcolormap = gdk_drawable_get_colormap(gdk_get_default_root_window());
if (gdk_drawable_get_colormap(bg->root_pixmap) == NULL) { if (gdk_drawable_get_colormap(bg->root_pixmap) == NULL) {
gdk_drawable_set_colormap(bg->root_pixmap, rcolormap); gdk_drawable_set_colormap(bg->root_pixmap,
rcolormap);
}
/* Retrieve the pixmap's size. */
gdk_error_trap_push();
width = height = -1;
gdk_drawable_get_size(bg->root_pixmap, &width, &height);
gdk_error_trap_pop();
/* If the pixmap gave us a valid size, retrieve its
* contents. */
if ((width > 0) && (height > 0)) {
gdk_error_trap_push();
pixbuf = gdk_pixbuf_get_from_drawable(NULL,
bg->root_pixmap,
NULL,
0, 0,
0, 0,
width, height);
gdk_error_trap_pop();
} }
pixbuf = gdk_pixbuf_get_from_drawable(NULL,
bg->root_pixmap,
NULL,
0, 0,
0, 0,
width, height);
} }
break; break;
case VTE_BG_SOURCE_PIXBUF: case VTE_BG_SOURCE_PIXBUF:
...@@ -633,17 +648,32 @@ vte_bg_get_pixbuf(VteBg *bg, ...@@ -633,17 +648,32 @@ vte_bg_get_pixbuf(VteBg *bg,
case VTE_BG_SOURCE_ROOT: case VTE_BG_SOURCE_ROOT:
if (GDK_IS_PIXMAP(bg->root_pixmap)) { if (GDK_IS_PIXMAP(bg->root_pixmap)) {
gint width, height; gint width, height;
gdk_drawable_get_size(bg->root_pixmap, &width, &height);
/* If the pixmap doesn't have a colormap, tell GTK+ that
* it shares the root window's colormap. */
rcolormap = gdk_drawable_get_colormap(gdk_get_default_root_window()); rcolormap = gdk_drawable_get_colormap(gdk_get_default_root_window());
if (gdk_drawable_get_colormap(bg->root_pixmap) == NULL) { if (gdk_drawable_get_colormap(bg->root_pixmap) == NULL) {
gdk_drawable_set_colormap(bg->root_pixmap, rcolormap); gdk_drawable_set_colormap(bg->root_pixmap, rcolormap);
} }
pixbuf = gdk_pixbuf_get_from_drawable(NULL,
bg->root_pixmap, /* Read the pixmap's size. */
NULL, gdk_error_trap_push();
0, 0, width = height = -1;
0, 0, gdk_drawable_get_size(bg->root_pixmap, &width, &height);
width, height); gdk_error_trap_pop();
/* If we got a valid size, read the pixmap's
* contents. */
if ((width > 0) && (height > 0)) {
gdk_error_trap_push();
pixbuf = gdk_pixbuf_get_from_drawable(NULL,
bg->root_pixmap,
NULL,
0, 0,
0, 0,
width, height);
gdk_error_trap_pop();
}
} }
break; break;
case VTE_BG_SOURCE_PIXBUF: case VTE_BG_SOURCE_PIXBUF:
......
Name: vte Name: vte
Version: 0.11.9 Version: 0.11.9
Release: 1 Release: 2
Summary: An experimental terminal emulator. Summary: An experimental terminal emulator.
License: LGPL License: LGPL
Group: User Interface/X Group: User Interface/X
...@@ -94,6 +94,9 @@ rm -f $RPM_BUILD_ROOT/%{_libdir}/python*/site-packages/*.a ...@@ -94,6 +94,9 @@ rm -f $RPM_BUILD_ROOT/%{_libdir}/python*/site-packages/*.a
%{_libdir}/pkgconfig/* %{_libdir}/pkgconfig/*
%changelog %changelog
* Mon Jun 2 2003 Nalin Dahyabhai <nalin@redhat.com> 0.11.9-2
- rebuild
* Mon Jun 2 2003 Nalin Dahyabhai <nalin@redhat.com> 0.11.9-1 * Mon Jun 2 2003 Nalin Dahyabhai <nalin@redhat.com> 0.11.9-1
- fix saving/restoring the cursor with DECSET/DECRST - fix saving/restoring the cursor with DECSET/DECRST
- revert behavior wrt ambiguously-wide characters to be more like 0.10.x - revert behavior wrt ambiguously-wide characters to be more like 0.10.x
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment