Box graphic tweak

Box graphic tweak

[Chong Yidong]

I just made a tweak to the way 3D boxes are drawn, to make them more
legible.  The W32 code looks like it could use a similar change, but I
didn't want to do the translation without being able to test it.  Could
someone on W32 take a look?  Thanks.

  * xterm.c (x_draw_relief_rect): If box width is larger than 1,
  draw the outermost line using the black relief, for legibility.
  Omit drawing the four corner pixels.

Re: Box graphic tweak

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Date: Fri, 08 Oct 2010 01:14:02 -0400
> 
> I just made a tweak to the way 3D boxes are drawn, to make them more
> legible.

Can you tell more?  What should be the differences as result of this
change?  Perhaps screen snapshots will be useful.

Re: Box graphic tweak

[Chong Yidong]

[-- Attachment #1: Type: text/plain, Size: 431 bytes --]

Eli Zaretskii <eliz@gnu.org> writes:

>> I just made a tweak to the way 3D boxes are drawn, to make them more
>> legible.
>
> Can you tell more?  What should be the differences as result of this
> change?  Perhaps screen snapshots will be useful.

Here is a before/after image of a button.  The outermost line of the top
and left surface of the button is drawn using the black relief, so that
it is visible on bright backgrounds.


[-- Attachment #2: buttons.png --]
[-- Type: image/png, Size: 704 bytes --]

Re: Box graphic tweak

[Miles Bader]

Chong Yidong <cyd@stupidchicken.com> writes:
> Here is a before/after image of a button.  The outermost line of the top
> and left surface of the button is drawn using the black relief, so that
> it is visible on bright backgrounds.

It looks reasonable in your picture, but remember that the "button"
attribute is also commonly used for mode-lines.

Also, how about on black backgrounds?  It will just make the relief look
"thinner", right?

-Miles

-- 
values of β will give rise to dom!

Re: Box graphic tweak

[Chong Yidong]

[-- Attachment #1: Type: text/plain, Size: 560 bytes --]

Miles Bader <miles@gnu.org> writes:

> It looks reasonable in your picture, but remember that the "button"
> attribute is also commonly used for mode-lines.

The default mode-line has width 1, so it's unaffected.  Setting the
width to 2, the result still also looks reasonable; see attached.

> Also, how about on black backgrounds?  It will just make the relief look
> "thinner", right?

Seems fine to me (I use a black background myself).  The button borders
legibility issue isn't generally a problem for black backgrounds, when
the button itself is grey.


[-- Attachment #2: modeline.png --]
[-- Type: image/png, Size: 4388 bytes --]

Re: Box graphic tweak

[Kenichi Handa]

In article <8739sg81un.fsf@stupidchicken.com>, Chong Yidong <cyd@stupidchicken.com> writes:

> > It looks reasonable in your picture, but remember that the "button"
> > attribute is also commonly used for mode-lines.

> The default mode-line has width 1, so it's unaffected.  Setting the
> width to 2, the result still also looks reasonable; see attached.

??? The default box's line-width of mode-line is -1 to make the
height of the mode-line the same as the other default lines.

---
Kenichi Handa
handa@m17n.org

RE: Box graphic tweak

[Drew Adams]

> > The default mode-line has width 1, so it's unaffected.  Setting the
> > width to 2, the result still also looks reasonable; see attached.
>
> ??? The default box's line-width of mode-line is -1 to make the
> height of the mode-line the same as the other default lines.

And I tried to stress that a setting of -1 is important, and that users need to
be able to adjust whatever new boxing features we might add:

d> More importantly, such an appearance difference should in any 
d> case be under user control - just as users can today control
d> the box outline width and even whether it extends outside the
d> char size or within it (using a negative width).  It must
d> not be forced.
d> 
d> IOW, if you would like to make such a feature available to 
d> users, great, but it should be as optional as the other `box'
d> attributes.
d> 
d> (The ability to use a negative box width is important, BTW, 
d> and your new feature should not force a boxed char to always
d> be larger than a normal char - there needs to be some way to
d> control the overall size.

No response to that.  I still don't know whether and how much users will be able
to control this.  All that was said was that this feature gives us a new default
appearance.

Re: Box graphic tweak

[Miles Bader]

"Drew Adams" <drew.adams@oracle.com> writes:
> No response to that.  I still don't know whether and how much users will be able
> to control this.  All that was said was that this feature gives us a new default
> appearance.

Though my initial impression is that it's rather nicer looking than the
old default appearance, especially in places like customize buffers
where the old look was ... kinda unpolished.

-miles

-- 
Would you like fries with that?

Re: Box graphic tweak

[Kenichi Handa]

In article <49AEB9D768C84AADAD221D9DBE22E44B@us.oracle.com>, "Drew Adams" <drew.adams@oracle.com> writes:

> > ??? The default box's line-width of mode-line is -1 to make the
> > height of the mode-line the same as the other default lines.

> And I tried to stress that a setting of -1 is important,

Ah, I didn't read the other mails of the thread.

> and that users need to
> be able to adjust whatever new boxing features we might add:

>>> More importantly, such an appearance difference should in any 
>>> case be under user control - just as users can today control
>>> the box outline width and even whether it extends outside the
>>> char size or within it (using a negative width).  It must
>>> not be forced.
>>> 
>>> IOW, if you would like to make such a feature available to 
>>> users, great, but it should be as optional as the other `box'
>>> attributes.
>>> 
>>> (The ability to use a negative box width is important, BTW, 
>>> and your new feature should not force a boxed char to always
>>> be larger than a normal char - there needs to be some way to
>>> control the overall size.

I agree.

---
Kenichi Handa
handa@m17n.org

Re: Box graphic tweak

[Chong Yidong]

Kenichi Handa <handa@m17n.org> writes:

>> The default mode-line has width 1, so it's unaffected.  Setting the
>> width to 2, the result still also looks reasonable; see attached.
>
> ??? The default box's line-width of mode-line is -1 to make the
> height of the mode-line the same as the other default lines.

Indeed, my mistake.  Anyhow, all line-widths less than 2 should be
displayed as before (apart from the four corner pixels).

RE: Box graphic tweak

[Drew Adams]

> >> I just made a tweak to the way 3D boxes are drawn, to make 
> >> them more legible.
> >
> > Can you tell more?  What should be the differences as result of this
> > change?  Perhaps screen snapshots will be useful.
> 
> Here is a before/after image of a button.  The outermost line 
> of the top and left surface of the button is drawn using the black 
> relief, so that it is visible on bright backgrounds.

FWIW - It looks a bit worse, not better, to me (just one opinion). But it's hard
to judge out of context (e.g. buttons in Customize, mode line/header text,
etc.).  My guess is that in some contexts it might be an improvement and in
others it would not be appropriate.

More importantly, such an appearance difference should in any case be under user
control - just as users can today control the box outline width and even whether
it extends outside the char size or within it (using a negative width).  It must
not be forced.

IOW, if you would like to make such a feature available to users, great, but it
should be as optional as the other `box' attributes.

(The ability to use a negative box width is important, BTW, and your new feature
should not force a boxed char to always be larger than a normal char - there
needs to be some way to control the overall size.  I run into this for example
in places where a window height automatically gets increased by one line to
accommodate the extra pixel(s) coming from an outside-char box.  Using a
negative box width takes care of that annoyance.)

Re: Box graphic tweak

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Date: Fri, 08 Oct 2010 01:14:02 -0400
> 
> I just made a tweak to the way 3D boxes are drawn, to make them more
> legible.  The W32 code looks like it could use a similar change, but I
> didn't want to do the translation without being able to test it.  Could
> someone on W32 take a look?  Thanks.
> 
>   * xterm.c (x_draw_relief_rect): If box width is larger than 1,
>   draw the outermost line using the black relief, for legibility.
>   Omit drawing the four corner pixels.

Jason, could you please do this?  I tried, but the differences between
the X and the w32 code are substantial to the degree that sufficient
knowledge of the underlying primitives is required to DTRT, and I lack
that knowledge.

Thanks.

For reference, here are the diffs for the changes done by Chong:

=== modified file 'src/xterm.c'
--- src/xterm.c	2010-10-03 15:39:21 +0000
+++ src/xterm.c	2010-10-09 03:30:31 +0000
@@ -1942,18 +1942,38 @@ x_draw_relief_rect (struct frame *f,
     gc = f->output_data.x->black_relief.gc;
   XSetClipRectangles (dpy, gc, 0, 0, clip_rect, 1, Unsorted);
 
+  /* This code is more complicated than it has to be, because of two
+     minor hacks to make the boxes look nicer: (i) if width > 1, draw
+     the outermost line using the black relief.  (ii) Omit the four
+     corner pixels.  */
+
   /* Top.  */
   if (top_p)
-    for (i = 0; i < width; ++i)
-      XDrawLine (dpy, window, gc,
-		 left_x + i * left_p, top_y + i,
-		 right_x + 1 - i * right_p, top_y + i);
+    {
+      if (width == 1)
+	XDrawLine (dpy, window, gc,
+		   left_x  + (left_p  ? 1 : 0), top_y,
+		   right_x + (right_p ? 0 : 1), top_y);
+
+      for (i = 1; i < width; ++i)
+	XDrawLine (dpy, window, gc,
+		   left_x  + i * left_p, top_y + i,
+		   right_x + 1 - i * right_p, top_y + i);
+    }
 
   /* Left.  */
   if (left_p)
-    for (i = 0; i < width; ++i)
-      XDrawLine (dpy, window, gc,
-		 left_x + i, top_y + i, left_x + i, bottom_y - i + 1);
+    {
+      if (width == 1)
+	XDrawLine (dpy, window, gc, left_x, top_y + 1, left_x, bottom_y);
+
+      XClearArea (dpy, window, left_x, top_y, 1, 1, False);
+      XClearArea (dpy, window, left_x, bottom_y, 1, 1, False);
+
+      for (i = (width > 1 ? 1 : 0); i < width; ++i)
+	XDrawLine (dpy, window, gc,
+		   left_x + i, top_y + i, left_x + i, bottom_y - i + 1);
+    }
 
   XSetClipMask (dpy, gc, None);
   if (raised_p)
@@ -1962,18 +1982,40 @@ x_draw_relief_rect (struct frame *f,
     gc = f->output_data.x->white_relief.gc;
   XSetClipRectangles (dpy, gc, 0, 0, clip_rect, 1, Unsorted);
 
+  if (width > 1)
+    {
+      /* Outermost top line.  */
+      if (top_p)
+	XDrawLine (dpy, window, gc,
+		   left_x  + (left_p  ? 1 : 0), top_y,
+		   right_x + (right_p ? 0 : 1), top_y);
+
+      /* Outermost left line.  */
+      if (left_p)
+	XDrawLine (dpy, window, gc, left_x, top_y + 1, left_x, bottom_y);
+    }
+
   /* Bottom.  */
   if (bot_p)
-    for (i = 0; i < width; ++i)
+    {
       XDrawLine (dpy, window, gc,
-		 left_x + i * left_p, bottom_y - i,
-		 right_x + 1 - i * right_p, bottom_y - i);
+		 left_x  + (left_p  ? 1 : 0), bottom_y,
+		 right_x + (right_p ? 0 : 1), bottom_y);
+      for (i = 1; i < width; ++i)
+	XDrawLine (dpy, window, gc,
+		   left_x  + i * left_p, bottom_y - i,
+		   right_x + 1 - i * right_p, bottom_y - i);
+    }
 
   /* Right.  */
   if (right_p)
-    for (i = 0; i < width; ++i)
-      XDrawLine (dpy, window, gc,
-		 right_x - i, top_y + i + 1, right_x - i, bottom_y - i);
+    {
+      XClearArea (dpy, window, right_x, top_y, 1, 1, False);
+      XClearArea (dpy, window, right_x, bottom_y, 1, 1, False);
+      for (i = 0; i < width; ++i)
+	XDrawLine (dpy, window, gc,
+		   right_x - i, top_y + i + 1, right_x - i, bottom_y - i);
+    }
 
   XSetClipMask (dpy, gc, None);
 }