From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#45620: 28.0.50; Child frames should have their own border width and colour Date: Mon, 4 Jan 2021 17:22:44 +0100 Message-ID: <8af92126-3e57-66c0-08e9-b0b5326fa538@gmx.at> References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="1393"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 45620@debbugs.gnu.org To: Alexander Miller Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Jan 04 17:23:18 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 1kwSdZ-0000EB-Uy for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 04 Jan 2021 17:23:18 +0100 Original-Received: from localhost ([::1]:50408 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kwSdZ-0005fO-1X for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 04 Jan 2021 11:23:17 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43564) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kwSdK-0005et-84 for bug-gnu-emacs@gnu.org; Mon, 04 Jan 2021 11:23:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:48489) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kwSdK-0002TM-0z for bug-gnu-emacs@gnu.org; Mon, 04 Jan 2021 11:23:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kwSdJ-0002NR-Rt for bug-gnu-emacs@gnu.org; Mon, 04 Jan 2021 11:23:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 04 Jan 2021 16:23:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 45620 X-GNU-PR-Package: emacs Original-Received: via spool by 45620-submit@debbugs.gnu.org id=B45620.16097773749112 (code B ref 45620); Mon, 04 Jan 2021 16:23:01 +0000 Original-Received: (at 45620) by debbugs.gnu.org; 4 Jan 2021 16:22:54 +0000 Original-Received: from localhost ([127.0.0.1]:60035 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kwSdC-0002Mu-3a for submit@debbugs.gnu.org; Mon, 04 Jan 2021 11:22:54 -0500 Original-Received: from mout.gmx.net ([212.227.15.18]:53891) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kwSd9-0002Mg-IG for 45620@debbugs.gnu.org; Mon, 04 Jan 2021 11:22:52 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1609777365; bh=WNcE0v5B3WJ7uceBo+UgtbucUoJ7gDeBpXsMk+E6MG8=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=Kmu3WBT1bF64vEAPDM0CiGKZ9oYqNKQq6HJe5EA16qn5XuIlhYJBNvGOJqU3T7u34 O1M59tWL/zAz+pI00aOg0J7FqSTYtA80hlbbQOGaS7xRqdKmCxyyrO3jX9GSai51Mo p/vygGC35yKFdX42l3reBljaDBWf2H223LmenIgI= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from [192.168.1.100] ([46.125.249.15]) by mail.gmx.com (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MBUqL-1kqBdy25fz-00Cy7t; Mon, 04 Jan 2021 17:22:45 +0100 In-Reply-To: Content-Language: en-US X-Provags-ID: V03:K1:Iga+wE2fNobC5IlTcghW6ROb3IKwOe3hIIDsr6jnqvmf+ETHbqU 6d4eRfKUoF9hoWkjH2SIo/0C5aH0c8+DC1MhI8SxF96ZWyxftM47xUeOfNbth3rLhWMYhQz jidnAvMEern6fp640Wx5mLOgEt1g+LuAlrjt9Hk1k63UxGrcOjKKE5/bPOtI99CBjZRCOHb ybC6R6sN6Po20ztIin2ow== X-UI-Out-Filterresults: notjunk:1;V03:K0:Yh75fMbcWI4=:9dBjICyVhKtxet0nWHJbVn 38pyPINmpRsH1r/JrGVADscqDCoO4mLzcjxk6nFtOaZZPyG0vFfoP9d+pwX4WByTgzH1/mdYN NsTQ+32GhAutawlzsWkRk7yejxlW2zlMmdVXRxT1O7uiRpjutaF2FAE1txQkYnpkvfOjSHjnB Lma7fZou5PnoDdCC5BQiYnV1Kf+IXmXkdbbddE8yIf3z3lWr3ICVQSWVJP7lGHQgDEcDWUop+ IuU6XIYa4fvqz2srnqA++/zBHmEISSwUFloqJODSe2w3BQFA4ur5aNsBKzd123b/aRX9ujEIo hteQ2DPbHjt4rRFpfY7k2eKSx2IrT1hQie4fBjmcS6QP1tm3swboVYcugh9SnKJETqJMi7e+R LN0GQTJ6Qzq9VAMtNuE4KdPg8ECkQ+WZ/kIiQYkm3rPwn99FHAEYFQdeBbBzXPgPah9UrPfhd Ei2FDK7f9FbuGsBmLNN8UzkMjvDHOSPSM6TMLj4V/ULRRciAzYDKz+e8WqdMD86660kCutcFa 5LViMjVQErJqo5DwYk6oPZM+saRNXWkisAWxHRT18zHEICw5lT44DKNOt4DlL5pQF1QICEtk8 X30qoLsUnGT8hu/H5bU9sG+jVbLDkOwxUlM2PZ/2pDrUE0UpVHX5d/UlvV7P4m7NeBdi7xNlm ZnqycFAfqcqKB0myTv1BETuYZKUnp+x5BJW4WIZj+Po6TEvWKQkydS2QYtxbhNEmBl1aXQWYN ZS9G+QrQK/PlVOTLeCrY2cgmoUde3Pljy6ChMyJCOTZtspa/lgXyJqYDzrm6MRnyxkPofibe 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:197314 Archived-At: > What customisations are you referring to? I cannot think of any > scenario, other than changing and reloading your theme, that could > change the settings of already present child frames. Here I'm using a child frame for popping up the minibuffer with the customization (defcustom pop-up-mini-internal-border "blue" "Background of internal border of 'pop-up-mini-frame'." ... and the form (set-face-background 'internal-border pop-up-mini-internal-border pop-up-mini-frame) to put it into practice when setting up such a frame. This works fine until I do M-x customize-face RET internal-border RET. As soon as I apply the value I customized there, my minibuffer child frame gets that border instead of the one specified via 'pop-up-mini-internal-border' above. > > If I'm not mistaken we use that face for our tooltip frames too which > > means one more conflict. > > Partially. On my system the internal-border colour and width only > applied to the top and left sides of the tooltip frame. Yes. I think there's a bug somewhere but the only time I tried to locate it, I decided that someone else intentionally does it that way. > Packages do have the choice, they just have to make sure to override the > frame-local faces whenever they show something. The problem, as I see > it, is that they *have to* create a face to override the local > internal-border, instead of just having the option to do it, because > themes cannot offer a general setting, like an easily visible dark > border on a bright foreground, because they run into the frame margin > colour conflict like modus did in the linked issue. So if a package > doesn't overwrite the local internal-border your default look-and-feel > is a badly visible same-colour-on-same-colour popup. Agreed. On a historical note, I had to add the entire internal border entertainment to child frames because neither gtk nor X bother to supply the normal window manager border for them (Windows does) and so you can neither make them stand apart easily nor can you resize them with the mouse. Implementing the latter from within Emacs was even very entertaining. I intentionally left the border color alone because I'm convinced that customizing it is a bad idea as sketched in the above scenario and packages should always try their own way to specify it. > > So what should we do? Provide a separate 'child-frame-internal-border' > > face and then probably also a 'tooltip-internal-border-face'? > > That would be perfectly good enough for themes like modus, yes. Can you propose a patch? Look at where we use INTERNAL_BORDER_FACE_ID to set up a face (x_clear_under_internal_border in xterm.c is an example), check f for child-frameness there and use the new face if the frame is a child frame. But be aware: Users like me will then have to separately set the background for the child frame face so you might get incompatibility complaints ... martin