From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#745: pop-to-buffer, frames, and input focus Date: Sat, 30 Aug 2008 15:42:00 +0200 Message-ID: <48B94E28.9040707@gmx.at> References: <48AD2FB5.3000204@gmx.at> <48ADD085.50505@gmx.at> <48AEEBB8.50201@gmx.at> <48AFFD26.3040204@gmx.at> <48B2B78C.9090407@gmx.at> <48B50C63.8010402@gmx.at> <48B69007.20604@gmx.at> <48B7181B.7080706@gmx.at> <48B7C0DA.8040104@gmx.at> <48B901B0.90701@gmx.at> Reply-To: martin rudalics , 745@emacsbugs.donarmstrong.com NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1220105281 17145 80.91.229.12 (30 Aug 2008 14:08:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 30 Aug 2008 14:08:01 +0000 (UTC) Cc: 745@emacsbugs.donarmstrong.com To: Helmut Eller Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Aug 30 16:08:53 2008 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1KZR81-0007yY-N8 for geb-bug-gnu-emacs@m.gmane.org; Sat, 30 Aug 2008 16:08:38 +0200 Original-Received: from localhost ([127.0.0.1]:51609 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KZR73-0005n1-0g for geb-bug-gnu-emacs@m.gmane.org; Sat, 30 Aug 2008 10:07:37 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KZR70-0005mk-6k for bug-gnu-emacs@gnu.org; Sat, 30 Aug 2008 10:07:34 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KZR6y-0005mQ-Vm for bug-gnu-emacs@gnu.org; Sat, 30 Aug 2008 10:07:33 -0400 Original-Received: from [199.232.76.173] (port=35254 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KZR6y-0005mG-Pi for bug-gnu-emacs@gnu.org; Sat, 30 Aug 2008 10:07:32 -0400 Original-Received: from rzlab.ucr.edu ([138.23.92.77]:55005) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KZR6x-0006bK-VM for bug-gnu-emacs@gnu.org; Sat, 30 Aug 2008 10:07:32 -0400 Original-Received: from rzlab.ucr.edu (rzlab.ucr.edu [127.0.0.1]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id m7UE7TSx030620; Sat, 30 Aug 2008 07:07:30 -0700 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.13.8/8.13.8/Submit) id m7UDt5d4025362; Sat, 30 Aug 2008 06:55:05 -0700 X-Loop: don@donarmstrong.com Resent-From: martin rudalics Resent-To: bug-submit-list@donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Sat, 30 Aug 2008 13:55:05 +0000 Resent-Message-ID: Resent-Sender: don@donarmstrong.com X-Emacs-PR-Message: report 745 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Original-Received: via spool by 745-submit@emacsbugs.donarmstrong.com id=B745.122010398023240 (code B ref 745); Sat, 30 Aug 2008 13:55:05 +0000 Original-Received: (at 745) by emacsbugs.donarmstrong.com; 30 Aug 2008 13:46:20 +0000 Original-Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with SMTP id m7UDkFM2023234 for <745@emacsbugs.donarmstrong.com>; Sat, 30 Aug 2008 06:46:17 -0700 Original-Received: (qmail invoked by alias); 30 Aug 2008 13:46:10 -0000 Original-Received: from 62-47-52-54.adsl.highway.telekom.at (EHLO [62.47.52.54]) [62.47.52.54] by mail.gmx.net (mp042) with SMTP; 30 Aug 2008 15:46:10 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/A7/M06RLAy/rOUkGPbVPJ89/JXf+Ix9xLE9hjH8 lpXpB+PASbMqsL User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) In-Reply-To: X-Y-GMX-Trusted: 0 X-FuHaFi: 0.57 X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 3) Resent-Date: Sat, 30 Aug 2008 10:07:33 -0400 X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:19907 Archived-At: >> (1) do a `display-buffer' making a new frame without that frame getting >> raised and/or input focus, and > > If I call gtk_window_set_focus_on_map (GTK_WINDOW (wtop), FALSE) in > gtkutil.c:xg_create_frame_widgets, then Metacity dosn't give the focus > to new frames. The initial Emacs frame is also not focused. > gtk_window_set_focus_on_map sets _NET_WM_USER_TIME to 0. I know that > because I read the GTK source. It can be verified by calling xprop on > the resulting Emacs frame. In this case we'd have to make `pop-to-buffer' give focus to the frame, look out for applications that ("wrongly") expect `display-buffer' to focus the frame, focus the initial frame, and decide what to do about `select-window/frame'. After the release we could implement this for all ewmh-compliant window-managers. >> (2) give input focus to/raise a frame that hasn't input focus/is not >> raised. >> >> entirely using _NET_WM_USER_TIME? > > I don't know how to that with _NET_WM_USER_TIME. For _NET_WM_USER_TIME I read This property allows a Window Manager to alter the focus, stacking, and/or placement behavior of windows when they are mapped depending on whether the new window was created by a user action or is a "pop-up" window activated by a timer or some other event. but I fail to understand what "new window" means here. > But the EWMH-spec says this: > > _NET_ACTIVE_WINDOW, WINDOW/32 > > The window ID of the currently active window or None if no window has > the focus. This is a read-only property set by the Window Manager. If > a Client wants to activate another window, it MUST send a > _NET_ACTIVE_WINDOW client message to the root window: > > _NET_ACTIVE_WINDOW > window = window to activate > message_type = _NET_ACTIVE_WINDOW > format = 32 > data.l[0] = source indication > data.l[1] = timestamp > data.l[2] = requestor's currently active window, 0 if none > other data.l[] elements = 0 > > Source indication should be 1 when the request comes from an > application, and 2 when it comes from a pager. Clients using older > version of this spec use 0 as source indication, see the section called > "Source indication in request" for details. The timestamp is Client's > last user activity timestamp (see _NET_WM_USER_TIME) at the time of the > request, and the currently active window is the Client's active toplevel > window, if any (the Window Manager may be e.g. more likely to obey the > request if it will mean transferring focus from one active window to > another). > > Depending on the information provided with the message, the Window > Manager may decide to refuse the request (either completely ignore it, > or e.g. use _NET_WM_STATE_DEMANDS_ATTENTION). > > The current implementation of x_ewmh_activate_frame seems to work fine. OK. >> I faintly recall a discussion about a >> misinterpretation of timestamps sent to the window-manager (Metacity?) >> by Emacs. > > I've seen Metacity spit out warnings along the lines that XSetInputFocus > was called with a wrong timestamp. But I can't reproduce that right now. Ahh, I recall that discussion. Yet another reason why XSetInputFocus should be avoided for ewmh-compliant window managers. We should avoid calling XSetInputFocus for these in the present release. So I think we can distinguish three types of window managers according to our needs and what _NET_SUPPORTS tells us: - _NET_WM_USER_TIME capable ones, where we can have `display-buffer' not set the input focus for new frames (and thus not implicitly select the new window thus contradicting the doc-string of `display-buffer'). I suppose Metacity falls into this group. - _NET_ACTIVE_WINDOW capable ones, where `display-buffer' will behave as now but x_ewmh_activate_frame works. Sawfish seems to belong here. - Non-ewmh-compliant ones where we have to use XSetInputFocus. martin