From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: Fix some tooltip related problems Date: Wed, 10 Jan 2018 15:26:00 -0800 (PST) Message-ID: <7fbb8bd3-ebed-4e68-84b5-66bce36dc832@default> References: <5A533FA4.4030507@gmx.at> <9384bae5-cbb9-4b4d-ac5c-1d01f01c8117@default> <5A53B633.5020706@gmx.at> <41d40db5-15d8-4b2c-a058-fb6dabc8bfd3@default> <5A548E7E.2040601@gmx.at> <5A55E8ED.1010602@gmx.at> <475d480b-3885-4779-ae46-09cf7fbbcee7@default> <20180110191755.GA79229@breton.holly.idiocy.org> <329fad14-bed5-409a-828c-facec2e4be35@default> <20180110230426.GB16679@breton.holly.idiocy.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1515626710 17593 195.159.176.226 (10 Jan 2018 23:25:10 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 10 Jan 2018 23:25:10 +0000 (UTC) Cc: martin rudalics , emacs-devel To: Alan Third Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jan 11 00:25:05 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eZPjm-0003GL-Gn for ged-emacs-devel@m.gmane.org; Thu, 11 Jan 2018 00:24:50 +0100 Original-Received: from localhost ([::1]:48967 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eZPlm-0007Zl-5b for ged-emacs-devel@m.gmane.org; Wed, 10 Jan 2018 18:26:54 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59366) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eZPl7-0007Z4-8V for emacs-devel@gnu.org; Wed, 10 Jan 2018 18:26:14 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eZPl3-0005ku-7B for emacs-devel@gnu.org; Wed, 10 Jan 2018 18:26:13 -0500 Original-Received: from userp2120.oracle.com ([156.151.31.85]:38954) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1eZPl2-0005jR-Lc for emacs-devel@gnu.org; Wed, 10 Jan 2018 18:26:08 -0500 Original-Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w0ANNPJn034824; Wed, 10 Jan 2018 23:26:04 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2017-10-26; bh=RrYRigDuLknAbM0yRp5DkMcb0Bmgw9OXB0Ryp2Mpzhc=; b=jvXlBRiV7aQtNWefgEc0qTUnJM5dRcx0Z7E8wEK6JJvUPf9Jwgd5Jl0WGAGtOGhz1v/P JFebxDqRmdQQiHqkK9u2mKoCYzied9R0Xdt2Fcgn93r+t7cO2cP5hk6N5MrPriTknRa0 98kczw1zxvND1H0PMnZgHXv1X5OQZh4KGidIMYZlxu9TZxUegR+ZrNNTKBBaArLtB1VV eTVu5NOZRuB+Eb6ydc9mfT+BWrLV4pDtFOV1d0cCDdKnVDDhDEk0x1RqiliFaoOe9Spa eAo+lhhkl3ROMRMqA10hby6b9rFPh3eIWx+h2fUG96BJq005+nFmsCVThhKIVmLPyoOR bQ== Original-Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp2120.oracle.com with ESMTP id 2fdv65r22r-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 10 Jan 2018 23:26:04 +0000 Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w0ANQ2tU030857 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 10 Jan 2018 23:26:02 GMT Original-Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w0ANQ1x2005879; Wed, 10 Jan 2018 23:26:01 GMT In-Reply-To: <20180110230426.GB16679@breton.holly.idiocy.org> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4627.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8770 signatures=668652 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801100320 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] [fuzzy] X-Received-From: 156.151.31.85 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:221818 Archived-At: > > Given that limitation, I repeat the question: Can't we > > use a ("normal") Emacs frame, where things such as faces > > do work, to implement tooltips? >=20 > I believe it should be possible now we have undecorated frames > available. I=E2=80=99ve made a (really bad) attempt at proving we can do = it. > Patch attached. > > My emacs lisp skills are rather bad, so I couldn=E2=80=99t work out how t= o get > tooltip-hide to work, or how exactly I should set the size of the > tooltip, or how to not display the modeline, but it kind of works... > Someone who knows what they=E2=80=99re doing should be able to make a bet= ter > fist of it than me. Thanks for working on this. I would hope that whatever implementation is ultimately used is used for the existing functions (e.g. `x-tooltip-show'), so that nothing changes for users/Lisp. > One possible issue is that it might be difficult to stop frame=E2=80=90ba= sed > tooltips from crossing screens on multi=E2=80=90monitor setups. I know we= fix > that in Objective=E2=80=90C code in NS, I don=E2=80=99t know if lisp know= s enough > about screen geometry to get round it. I don't think we should _necessarily_ force all of a tooltip's text to be on a single monitor. Though that might make sense in some cases in others it might not. At most, the ability to do that would be a nice-to-have and not something needed or to be imposed (IMO). Put differently, it can be useful to _be able_ to position _any_ frame so that it does not extend across monitors, when possible. But that shouldn't necessarily be imposed on any frame, including, I think a tooltip. > > Did someone have to explain to you what a dimmed menu item > > is all about? Is that inherently confusing the first time > > someone sees it? I think not. A tooltip with dimmed text > > is no more confusing. >=20 > I disagree, a menu item is interactive, or not if it=E2=80=99s dimmed, so= it > becomes clear quite quickly what dimming means. A dimmed tooltip is > still a tooltip, just a bit harder to read. It takes further action to > discover that the information its giving you isn=E2=80=99t currently usab= le. That's reasonable. Not a big deal/difference though (IMO). The ability to get the general info is more important than any possible confusion (which I expect to be none) someone might have from not immediately understanding that dim means that trying the indicated action produces no effect.