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