From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Helmut Eller Newsgroups: gmane.emacs.bugs Subject: bug#745: pop-to-buffer, frames, and input focus Date: Sun, 31 Aug 2008 10:55:32 +0200 Message-ID: References: <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> <48B94E28.9040707@gmx.at> Reply-To: Helmut Eller , 745@emacsbugs.donarmstrong.com NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1220173680 950 80.91.229.12 (31 Aug 2008 09:08:00 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 31 Aug 2008 09:08:00 +0000 (UTC) Cc: 745@emacsbugs.donarmstrong.com To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Aug 31 11:08:54 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 1KZivU-0007eK-M1 for geb-bug-gnu-emacs@m.gmane.org; Sun, 31 Aug 2008 11:08:52 +0200 Original-Received: from localhost ([127.0.0.1]:47042 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KZiuV-0004he-Ke for geb-bug-gnu-emacs@m.gmane.org; Sun, 31 Aug 2008 05:07:51 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KZiuP-0004gS-Nx for bug-gnu-emacs@gnu.org; Sun, 31 Aug 2008 05:07:45 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KZiuI-0004fW-Rx for bug-gnu-emacs@gnu.org; Sun, 31 Aug 2008 05:07:44 -0400 Original-Received: from [199.232.76.173] (port=56033 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KZiuI-0004fT-Kj for bug-gnu-emacs@gnu.org; Sun, 31 Aug 2008 05:07:38 -0400 Original-Received: from rzlab.ucr.edu ([138.23.92.77]:50728) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KZiuG-0000i2-8n for bug-gnu-emacs@gnu.org; Sun, 31 Aug 2008 05:07:37 -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 m7V97UKs026864; Sun, 31 Aug 2008 02:07:30 -0700 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.13.8/8.13.8/Submit) id m7V904me023232; Sun, 31 Aug 2008 02:00:04 -0700 X-Loop: don@donarmstrong.com Resent-From: Helmut Eller Resent-To: bug-submit-list@donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Sun, 31 Aug 2008 09:00:04 +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.122017283621361 (code B ref 745); Sun, 31 Aug 2008 09:00:04 +0000 Original-Received: (at 745) by emacsbugs.donarmstrong.com; 31 Aug 2008 08:53:56 +0000 Original-Received: from rolmail.net (cgp1.rolmail.net [195.254.252.190]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id m7V8rpM6021355 for <745@emacsbugs.donarmstrong.com>; Sun, 31 Aug 2008 01:53:53 -0700 Original-Received: from dummy.name; Sun, 31 Aug 2008 10:53:49 +0200 Original-Received: from dummy.name; Sun, 31 Aug 2008 10:55:32 +0200 In-Reply-To: <48B94E28.9040707@gmx.at> (martin rudalics's message of "Sat, 30 Aug 2008 15:42:00 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 3) Resent-Date: Sun, 31 Aug 2008 05:07:44 -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:19924 Archived-At: * martin rudalics [2008-08-30 15:42+0200] writes: >>> (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. Sounds good. >>> (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. Perhaps it means "newly mapped window". I guess some window manager could give the focus to a newly mapped window only if its timestamp is newer than the timestamp of the currently focused window. I would be surprised though, if some application would rely on this behavior :-) Continuously updating this timestamp, e.g. on every keypress, sounds rather excessive just to give the WM this possibility. >>> 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. Yes, I think the same. Helmut. > LocalWords: timestamp keypress