* Box graphic tweak
@ 2010-10-08 5:14 Chong Yidong
2010-10-08 8:54 ` Eli Zaretskii
2010-11-27 11:19 ` Eli Zaretskii
0 siblings, 2 replies; 12+ messages in thread
From: Chong Yidong @ 2010-10-08 5:14 UTC (permalink / raw
To: emacs-devel
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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Box graphic tweak
2010-10-08 5:14 Box graphic tweak Chong Yidong
@ 2010-10-08 8:54 ` Eli Zaretskii
2010-10-08 13:59 ` Chong Yidong
2010-11-27 11:19 ` Eli Zaretskii
1 sibling, 1 reply; 12+ messages in thread
From: Eli Zaretskii @ 2010-10-08 8:54 UTC (permalink / raw
To: Chong Yidong; +Cc: emacs-devel
> 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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Box graphic tweak
2010-10-08 8:54 ` Eli Zaretskii
@ 2010-10-08 13:59 ` Chong Yidong
2010-10-08 14:13 ` Miles Bader
2010-10-08 15:18 ` Drew Adams
0 siblings, 2 replies; 12+ messages in thread
From: Chong Yidong @ 2010-10-08 13:59 UTC (permalink / raw
To: Eli Zaretskii; +Cc: emacs-devel
[-- 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 --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Box graphic tweak
2010-10-08 13:59 ` Chong Yidong
@ 2010-10-08 14:13 ` Miles Bader
2010-10-09 3:46 ` Chong Yidong
2010-10-08 15:18 ` Drew Adams
1 sibling, 1 reply; 12+ messages in thread
From: Miles Bader @ 2010-10-08 14:13 UTC (permalink / raw
To: Chong Yidong; +Cc: Eli Zaretskii, emacs-devel
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!
^ permalink raw reply [flat|nested] 12+ messages in thread
* RE: Box graphic tweak
2010-10-08 13:59 ` Chong Yidong
2010-10-08 14:13 ` Miles Bader
@ 2010-10-08 15:18 ` Drew Adams
1 sibling, 0 replies; 12+ messages in thread
From: Drew Adams @ 2010-10-08 15:18 UTC (permalink / raw
To: 'Chong Yidong', 'Eli Zaretskii'; +Cc: emacs-devel
> >> 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.)
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Box graphic tweak
2010-10-08 14:13 ` Miles Bader
@ 2010-10-09 3:46 ` Chong Yidong
2010-10-14 4:20 ` Kenichi Handa
0 siblings, 1 reply; 12+ messages in thread
From: Chong Yidong @ 2010-10-09 3:46 UTC (permalink / raw
To: Miles Bader; +Cc: Eli Zaretskii, emacs-devel
[-- 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 --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Box graphic tweak
2010-10-09 3:46 ` Chong Yidong
@ 2010-10-14 4:20 ` Kenichi Handa
2010-10-14 4:34 ` Drew Adams
2010-10-14 6:04 ` Chong Yidong
0 siblings, 2 replies; 12+ messages in thread
From: Kenichi Handa @ 2010-10-14 4:20 UTC (permalink / raw
To: Chong Yidong; +Cc: eliz, emacs-devel, miles
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* RE: Box graphic tweak
2010-10-14 4:20 ` Kenichi Handa
@ 2010-10-14 4:34 ` Drew Adams
2010-10-14 4:45 ` Miles Bader
2010-10-14 4:51 ` Kenichi Handa
2010-10-14 6:04 ` Chong Yidong
1 sibling, 2 replies; 12+ messages in thread
From: Drew Adams @ 2010-10-14 4:34 UTC (permalink / raw
To: 'Kenichi Handa', 'Chong Yidong'; +Cc: eliz, miles, emacs-devel
> > 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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Box graphic tweak
2010-10-14 4:34 ` Drew Adams
@ 2010-10-14 4:45 ` Miles Bader
2010-10-14 4:51 ` Kenichi Handa
1 sibling, 0 replies; 12+ messages in thread
From: Miles Bader @ 2010-10-14 4:45 UTC (permalink / raw
To: Drew Adams
Cc: 'Chong Yidong', emacs-devel, eliz,
'Kenichi Handa'
"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?
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Box graphic tweak
2010-10-14 4:34 ` Drew Adams
2010-10-14 4:45 ` Miles Bader
@ 2010-10-14 4:51 ` Kenichi Handa
1 sibling, 0 replies; 12+ messages in thread
From: Kenichi Handa @ 2010-10-14 4:51 UTC (permalink / raw
To: Drew Adams; +Cc: cyd, miles, eliz, emacs-devel
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Box graphic tweak
2010-10-14 4:20 ` Kenichi Handa
2010-10-14 4:34 ` Drew Adams
@ 2010-10-14 6:04 ` Chong Yidong
1 sibling, 0 replies; 12+ messages in thread
From: Chong Yidong @ 2010-10-14 6:04 UTC (permalink / raw
To: Kenichi Handa; +Cc: eliz, emacs-devel, miles
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).
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Box graphic tweak
2010-10-08 5:14 Box graphic tweak Chong Yidong
2010-10-08 8:54 ` Eli Zaretskii
@ 2010-11-27 11:19 ` Eli Zaretskii
1 sibling, 0 replies; 12+ messages in thread
From: Eli Zaretskii @ 2010-11-27 11:19 UTC (permalink / raw
To: Jason Rumney; +Cc: Chong Yidong, emacs-devel
> 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);
}
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2010-11-27 11:19 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-10-08 5:14 Box graphic tweak Chong Yidong
2010-10-08 8:54 ` Eli Zaretskii
2010-10-08 13:59 ` Chong Yidong
2010-10-08 14:13 ` Miles Bader
2010-10-09 3:46 ` Chong Yidong
2010-10-14 4:20 ` Kenichi Handa
2010-10-14 4:34 ` Drew Adams
2010-10-14 4:45 ` Miles Bader
2010-10-14 4:51 ` Kenichi Handa
2010-10-14 6:04 ` Chong Yidong
2010-10-08 15:18 ` Drew Adams
2010-11-27 11:19 ` Eli Zaretskii
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.