From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Arthur Miller Newsgroups: gmane.emacs.bugs Subject: bug#25408: Remove Decorations Around Emacs Frame (Windows OS) Date: Thu, 16 Feb 2017 14:22:49 +0100 Message-ID: References: <587499E6.9030205@gmx.at> <838tqietdj.fsf@gnu.org> <587522DB.2050105@gmx.at> <831swaepnc.fsf@gnu.org> <5875EF34.20507@gmx.at> <9efbe1e3-e8aa-f056-bc5c-5a41f10b6d42@gmail.com> <58996EED.6030601@gmx.at> <3d34793f-4b7c-d4ea-74ec-49ce84214cc8@gmail.com> <589F1F58.1050807@gmx.at> <301ed349-64c7-12c6-d843-e73eb1e20e83@gmail.com> <58A0434D.6030206@gmx.at> <58A55D26.3010203@gmx.at> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a113cc15898b25d0548a5b14b X-Trace: blaine.gmane.org 1487251517 19246 195.159.176.226 (16 Feb 2017 13:25:17 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 16 Feb 2017 13:25:17 +0000 (UTC) Cc: 25408@debbugs.gnu.org, =?UTF-8?Q?Cl=C3=A9ment?= Pit--Claudel To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Feb 16 14:25:13 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1ceM3b-0004N1-7l for geb-bug-gnu-emacs@m.gmane.org; Thu, 16 Feb 2017 14:25:11 +0100 Original-Received: from localhost ([::1]:46635 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ceM3f-0003XS-E7 for geb-bug-gnu-emacs@m.gmane.org; Thu, 16 Feb 2017 08:25:15 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59539) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ceM1a-0001f0-Ug for bug-gnu-emacs@gnu.org; Thu, 16 Feb 2017 08:23:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ceM1W-0003dx-Dy for bug-gnu-emacs@gnu.org; Thu, 16 Feb 2017 08:23:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:43586) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ceM1W-0003dt-AJ for bug-gnu-emacs@gnu.org; Thu, 16 Feb 2017 08:23:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ceM1W-0007mZ-5T for bug-gnu-emacs@gnu.org; Thu, 16 Feb 2017 08:23:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Arthur Miller Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 16 Feb 2017 13:23:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25408 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 25408-submit@debbugs.gnu.org id=B25408.148725137729884 (code B ref 25408); Thu, 16 Feb 2017 13:23:02 +0000 Original-Received: (at 25408) by debbugs.gnu.org; 16 Feb 2017 13:22:57 +0000 Original-Received: from localhost ([127.0.0.1]:41784 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ceM1Q-0007lu-W2 for submit@debbugs.gnu.org; Thu, 16 Feb 2017 08:22:57 -0500 Original-Received: from mail-oi0-f46.google.com ([209.85.218.46]:36779) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ceM1P-0007li-MU for 25408@debbugs.gnu.org; Thu, 16 Feb 2017 08:22:56 -0500 Original-Received: by mail-oi0-f46.google.com with SMTP id u143so8045263oif.3 for <25408@debbugs.gnu.org>; Thu, 16 Feb 2017 05:22:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fBJIyIUbal80ANa8OJD21n94Bc8jGAy70MjGo+ibF/w=; b=BXokqvUENJp9a93GmPsJYfb711yX6kRIYne79RebqYvTx4soiBEBq+YMRrqPsvtGDV iyIOWVfmrXFDs/C0xgNCjkYJMHXBVcoe4O1ozz00JYycRQfavSmoWQQJv/3wE6Z862Eh wj48aCiCMDquDlcnC7ARiV6t8i0qWI0f/WU9ar4NX/pRE3/6WoVMi+gYOVJBdm2jyiFV GzPVJA19Y6YeZ6VyTPbjC3U0DgzvmObJy7u6/mWEK3QUZL9b7Y3QdYdUmDIVZ9ir4/yG AOQaE9/FE0QAIA15VfDMoikb/mFDcTLubDhOLzvnESYchZq+Q88u0BwHptu3MBSdFeE/ jY1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fBJIyIUbal80ANa8OJD21n94Bc8jGAy70MjGo+ibF/w=; b=L3/nxCkXzbunwggfnbgQ35RMjX96Hhw5WUMomaciMz9zMJug8Q6SCd4PQTGVdvV5lg LVhhJATRW1Bau31oyUnKg8FkDSsHUlUAlzvsjVwmHEZoSZ/bUe3TzNdxQaUMGEXTxdx0 hi5Ac70EKna1yrXiLiDCiuvRzrBa4yW5Q2T9qopDyhbMDCxLM9leom8p7hy+NQrLUS+V tE4eilGlF9XEs2otd/hiYVyP+GqA2kOZ8OM1IO0P3IKWhCKCnoY32UA0wyCjQCRSi/2+ yU+VvdTIBhHecyIH0xGKdhNOudFeECFaLKT38C1Mr+6QRyMbzaCHCkWPDtX3G0VpmSia iJ1A== X-Gm-Message-State: AMke39kG/eCXYwygD1qN46tCfFIH5fl/6gk8jJ03E0PvfLLinNIWmF07Yhci4FLVKcC/WXGyElG81KmcpI917g== X-Received: by 10.202.62.138 with SMTP id l132mr1209822oia.128.1487251369910; Thu, 16 Feb 2017 05:22:49 -0800 (PST) Original-Received: by 10.182.105.73 with HTTP; Thu, 16 Feb 2017 05:22:49 -0800 (PST) In-Reply-To: <58A55D26.3010203@gmx.at> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 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.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:129407 Archived-At: --001a113cc15898b25d0548a5b14b Content-Type: text/plain; charset=UTF-8 If they don't get focus when they pop-up, and not get focus via mouse and if they also don't have decorations, what is considered as full functionality of "normal" frames? That sounds to me a bit like a popup window. Do you give them focus by switching with keyboard, like moving focus to "other window"? "The concern is how to control aspects like appearance, placement, focusing and stacking order of some specific Emacs frames, without affecting the remaining frames." As you yourself point out, certain WMs does allow you to create rules per windows. On some managers one can set rule based on window title bar, window class or class name, xid, role etc. I don't know if title bar property can be used if titlebar exist but is hidden. Maybe a separate class name could be used for that kind of windows so one can set appropriate hints for that frame. Or maybe you are already doing that? Just an idea, I haven't looked at your patch to be honest. I cloned code today from git and compilations is crashing on me, when dumping lisp code: (without your patch applied): Loading /home/arthur/emacs/lisp/international/characters.el (source)... Wrong type argument: char-table-p, nil make[1]: *** [Makefile:752: bootstrap-emacs] Error 255 make[1]: Leaving directory '/home/arthur/emacs/src' make: *** [Makefile:409: src] Error 2 Will be interesting to test it once I manage to compile Emacs. 2017-02-16 9:04 GMT+01:00 martin rudalics : > > That's great. Are you going to push your patch to git-repo? > > After having resolved some remaining issues, yes. > > > When it comes to other platforms than Windows, I have no idea about OS X > > since I don't own any macs, but for X11, we have different means to > > controll decorations and their looks & behaviour. On X11 we have window > > managers that makes it easy to configure (or remove) borders, decorations > > etc, so in my humble opinion I don't think you have to spend countless > time > > to make it work with every possible window manager etc. > > The concern here is not how to turn off decorations for all windows (or > maybe all windows of a certain application), something which themes most > likely already provide to some extent. The concern is how to control > aspects like appearance, placement, focusing and stacking order of some > specific Emacs frames, without affecting the remaining frames. > > Consider the need to display some explanatory information for the > editing activity you are about to accomplish. If you don't want to pop > up a new "normal" window or frame for that purpose, you currently have > two possibilites: Use the echo area or the tooltip frame. Both are > ephemeral and have to be shared with all other applications pursuing a > similar goal. > > Hence the need for some sort of minor frames which are OT1H less > ephemeral and can be more easily replicated than tooltips or the echo > area and are OTOH visually and habitually less obtrusive than normal > frames or windows. > > Some desirable properties of such minor frames are: > > (1) Do not show any window manager decorations provided their visibility > and placement can be controlled by the application. > > (2) Do not show them on the taskbar. > > (3) Do not focus them when they pop up. > > (4) Do not give them focus via mouse movements, mouse wheel scrolling or > accidental mouse clicks. > > (5) Allow to attach them to some normal Emacs frame or window. This > means to automatically move, resize and stack them along with that > frame/window without affecting the appearance of any other object on > your display. It may also mean to make them obscure as few as > possible text of the frame they have been attached to. > > (6) Apart from (1)--(5) give them the full functionality of "normal" > Emacs frames. > > Obviously, (6) is the most difficult part. For example, displaying such > a frame without making it continuously vanish and reappear. > > martin > --001a113cc15898b25d0548a5b14b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
If they don't get focus when = they pop-up, and not get focus via mouse and if they also
don't have= decorations, what is considered as full functionality of "normal"= ; frames?
That sounds to me a bit like a popup window. Do you give them= focus by switching
with keyboard, like moving focus to "other win= dow"?

"The concern is how to control
aspects like appearance, placement, focusing and stacking order of some
specific Emacs frames, without affecting the remaining frames."
As you yourself point out, certain WMs does allow you to create rule= s per windows.=C2=A0 On some
managers one can set rule based on window = title bar, window class or class name,=C2=A0
xid, role etc. I don't= know if title bar property can be used if titlebar exist but is hidden.
Maybe a separate class name could be used for that kind of = windows so one can set
appropriate hints for that frame. Or maybe you a= re already doing that? Just an idea,
I haven't looked at your patch= to be honest.

I cloned code today from git and compilati= ons is crashing on me, when dumping lisp code:
(without your = patch applied):

Loading /home/arthur/emacs/lisp/internati= onal/characters.el (source)...
Wrong type argument: char-table-p, nilmake[1]: *** [Makefile:752: bootstrap-emacs] Error 255
make[1]: Leaving= directory '/home/arthur/emacs/src'
make: *** [Makefile:409: src= ] Error 2

Will be interesting to test it once I manage to= compile Emacs.


2017-02-16 9:= 04 GMT+01:00 martin rudalics <rudalics@gmx.at>:
> That's great. Are you going t= o push your patch to git-repo?

 After having resolved some remaining issues, yes.

> When it comes to other platforms than Windows, I have no idea about OS= X
> since I don't own any macs, but for X11, we have different means t= o
> controll decorations and their looks & behaviour. On X11 we have w= indow
> managers that makes it easy to configure (or remove) borders, decorati= ons
> etc, so in my humble opinion I don't think you have to spend count= less time
> to make it work with every possible window manager etc.

 The concern here is not how to turn off decorations for all windows (or
maybe all windows of a certain application), something which themes most likely already provide to some extent.=C2=A0 The concern is how to control<= br> aspects like appearance, placement, focusing and stacking order of some
specific Emacs frames, without affecting the remaining frames.

Consider the need to display some explanatory information for the
editing activity you are about to accomplish.=C2=A0 If you don't want t= o pop
up a new "normal" window or frame for that purpose, you currently= have
two possibilites: Use the echo area or the tooltip frame.=C2=A0 Both are ephemeral and have to be shared with all other applications pursuing a
similar goal.

Hence the need for some sort of minor frames which are OT1H less
ephemeral and can be more easily replicated than tooltips or the echo
area and are OTOH visually and habitually less obtrusive than normal
frames or windows.

Some desirable properties of such minor frames are:

(1) Do not show any window manager decorations provided their visibility =C2=A0 =C2=A0 and placement can be controlled by the application.

(2) Do not show them on the taskbar.

(3) Do not focus them when they pop up.

(4) Do not give them focus via mouse movements, mouse wheel scrolling or =C2=A0 =C2=A0 accidental mouse clicks.

(5) Allow to attach them to some normal Emacs frame or window.=C2=A0 This =C2=A0 =C2=A0 means to automatically move, resize and stack them along with= that
=C2=A0 =C2=A0 frame/window without affecting the appearance of any other ob= ject on
=C2=A0 =C2=A0 your display.=C2=A0 It may also mean to make them obscure as = few as
=C2=A0 =C2=A0 possible text of the frame they have been attached to.

(6) Apart from (1)--(5) give them the full functionality of "normal&qu= ot;
=C2=A0 =C2=A0 Emacs frames.

Obviously, (6) is the most difficult part.=C2=A0 For example, displaying su= ch
a frame without making it continuously vanish and reappear.

martin

--001a113cc15898b25d0548a5b14b--