From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Third Newsgroups: gmane.emacs.bugs Subject: bug#50424: 27.2; Tab bar button mouse face not clearing entirely Date: Wed, 8 Sep 2021 17:57:50 +0100 Message-ID: References: <87eea2cebb.fsf.ref@yahoo.com> <87eea2cebb.fsf@yahoo.com> <83eea2rn8z.fsf@gnu.org> <87h7exc2dk.fsf@yahoo.com> <83lf49r4bc.fsf@gnu.org> <87czplb51o.fsf@yahoo.com> <83ilzcpt0d.fsf@gnu.org> <83mtonob41.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3135"; mail-complaints-to="usenet@ciao.gmane.io" Cc: luangruo@yahoo.com, 50424@debbugs.gnu.org, juri@linkov.net To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Sep 08 18:59:12 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mO0uk-0000Z8-Ml for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 08 Sep 2021 18:59:11 +0200 Original-Received: from localhost ([::1]:49098 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mO0uj-0000P6-Jz for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 08 Sep 2021 12:59:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56112) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mO0uc-0000OP-Jm for bug-gnu-emacs@gnu.org; Wed, 08 Sep 2021 12:59:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:50164) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mO0uc-0007FH-CY for bug-gnu-emacs@gnu.org; Wed, 08 Sep 2021 12:59:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mO0uc-0003ZW-Bh for bug-gnu-emacs@gnu.org; Wed, 08 Sep 2021 12:59:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Alan Third Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 08 Sep 2021 16:59:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 50424 X-GNU-PR-Package: emacs Original-Received: via spool by 50424-submit@debbugs.gnu.org id=B50424.163112028513641 (code B ref 50424); Wed, 08 Sep 2021 16:59:02 +0000 Original-Received: (at 50424) by debbugs.gnu.org; 8 Sep 2021 16:58:05 +0000 Original-Received: from localhost ([127.0.0.1]:33477 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mO0tg-0003Xx-VK for submit@debbugs.gnu.org; Wed, 08 Sep 2021 12:58:05 -0400 Original-Received: from outbound.soverin.net ([116.202.126.228]:48139) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mO0te-0003XJ-9D for 50424@debbugs.gnu.org; Wed, 08 Sep 2021 12:58:03 -0400 Original-Received: from smtp.soverin.net (unknown [10.10.3.28]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id 89EE4298; Wed, 8 Sep 2021 16:57:56 +0000 (UTC) Original-Received: from smtp.soverin.net (smtp.soverin.net [159.69.232.142]) by soverin.net DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=idiocy.org; s=soverin; t=1631120275; bh=5R6QU8i8k1Kj/JYNl5qwg67uU2XFafe4Z3/UeKZbUJs=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=heOMrLCb1xThUuFQWcnihBY0r99z7FagvAGq/DIlqYX2Dwvn/hSG5zk7g2lQK31bR Cx/zeUaeaN4sa083GEyCSFgTTfHBYtKiTjTpp653lKYWIcWotGKZsJXHy2rPDZaAm6 n4LdqFQww4IXXiw5BgOrU25ps1OPF5yxbtmTLT1AOwXYusCS9ziohTLSsYKdR/UVrr CvrzEuCjDcoseW5RCXXdDGhpkUoBGZSiXC6Q+Y89ZnYXOb/yQkR2M6SFylpSbR+XYm NTw6ZRiZrcZNiJ9WIR8H9OOgZZvcs0RrpK3eHdc6mPhzBHCSy556qLCDkDRtrBr54W LTbyXGNlNbueA== Original-Received: from alan by faroe.holly.idiocy.org with local (Exim 4.94.2) (envelope-from ) id 1mO0tS-001MhJ-KN; Wed, 08 Sep 2021 17:57:50 +0100 Mail-Followup-To: Alan Third , Eli Zaretskii , luangruo@yahoo.com, juri@linkov.net, 50424@debbugs.gnu.org Content-Disposition: inline In-Reply-To: <83mtonob41.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:213848 Archived-At: On Wed, Sep 08, 2021 at 09:05:50AM +0300, Eli Zaretskii wrote: > > Date: Wed, 8 Sep 2021 00:13:15 +0100 > > From: Alan Third > > Cc: Po Lu , Juri Linkov , > > 50424@debbugs.gnu.org > > > > On Tue, Sep 07, 2021 at 01:41:38PM +0300, Eli Zaretskii wrote: > > > > > > I hope the information here will allow Juri and people who really > > > understand the meaning of an image margin and relief (Alan?) fix the > > > rest of the problem. > > > > AFAIK the margin and relief are entirely handled by the term code and > > don't really have anything to do with the image itself. I expect > > that's why this is an OS specific problem. > > The code to deal with that is identical in xterm.c and w32term.c. > > Can you perhaps help us understand the purpose and semantics of the > delicate dance in the xdisp.c code I posted regarding images on the > tool-bar buttons? AFAIU, the xterm/w32term code was written to > reflect that, and the tab-bar code is simply a copy of the tool-bar > code, except that the image spec is defined entirely in Lisp, instead > of being dynamically redefined on the fly by the C code in the display > engine. So we need to understand the meaning of the margins and the > relief settings and their relation to the button being "selected" as > well as to the value of auto-raise-tool-bar-buttons, in order to do in > Lisp the same thing. Because xterm/w32term rely on this logic to > clear the area when the mouse pointer moves off the button. I think all it's doing is ensuring the total area the image takes up is the same whether there's a relief or not. The total width = image + relief width + margin width, so if you reduce the size of the relief you have to increase the size of the margin by the same amount to make sure it takes up the same amount of space and doesn't move. As far as I can see, what's happening here is that the margin is pushing the relief one pixel into the separator to the left, so I suspect that's why it's not being cleared. I'm somewhat surprised that it's not pushing the right hand side one pixel too far in the other direction and causing it to not be cleared either, but maybe that's just chance. The change below fixes it here, but I've not made sure it does the right thing with different sized margins and so on. modified src/w32term.c @@ -2057,11 +2057,11 @@ w32_draw_image_relief (struct glyph_string *s) && FIXNUMP (XCAR (Vtab_bar_button_margin)) && FIXNUMP (XCDR (Vtab_bar_button_margin))) { - extra_x = XFIXNUM (XCAR (Vtab_bar_button_margin)); - extra_y = XFIXNUM (XCDR (Vtab_bar_button_margin)); + extra_x = XFIXNUM (XCAR (Vtab_bar_button_margin)) - thick; + extra_y = XFIXNUM (XCDR (Vtab_bar_button_margin)) - thick; } else if (FIXNUMP (Vtab_bar_button_margin)) - extra_x = extra_y = XFIXNUM (Vtab_bar_button_margin); + extra_x = extra_y = XFIXNUM (Vtab_bar_button_margin) - thick; } if (s->face->id == TOOL_BAR_FACE_ID) modified src/xterm.c @@ -3235,11 +3235,11 @@ x_draw_image_relief (struct glyph_string *s) && FIXNUMP (XCAR (Vtab_bar_button_margin)) && FIXNUMP (XCDR (Vtab_bar_button_margin))) { - extra_x = XFIXNUM (XCAR (Vtab_bar_button_margin)); - extra_y = XFIXNUM (XCDR (Vtab_bar_button_margin)); + extra_x = XFIXNUM (XCAR (Vtab_bar_button_margin)) - thick; + extra_y = XFIXNUM (XCDR (Vtab_bar_button_margin)) - thick; } else if (FIXNUMP (Vtab_bar_button_margin)) - extra_x = extra_y = XFIXNUM (Vtab_bar_button_margin); + extra_x = extra_y = XFIXNUM (Vtab_bar_button_margin) - thick; } if (s->face->id == TOOL_BAR_FACE_ID) -- Alan Third