From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?ISO-8859-1?Q?Jan_Dj=E4rv?= Newsgroups: gmane.emacs.devel Subject: Re: GTK frame changes Date: Fri, 03 Jul 2009 14:43:08 +0200 Message-ID: <4A4DFCDC.2040809@swipnet.se> References: <4A4CADCB.8000304@gmx.de> <4A4CC3D7.40109@swipnet.se> <4A4CD73D.2080802@gmx.de> <4A4CDDF2.4030608@swipnet.se> <4A4CF264.6040306@gmx.de> <4A4D0E0E.70405@swipnet.se> <4A4DE33F.4060006@gmx.de> <87ws6qufng.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1246625432 6484 80.91.229.12 (3 Jul 2009 12:50:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 3 Jul 2009 12:50:32 +0000 (UTC) Cc: grischka , emacs-devel@gnu.org To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jul 03 14:50:24 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1MMiDf-0003fA-JJ for ged-emacs-devel@m.gmane.org; Fri, 03 Jul 2009 14:50:24 +0200 Original-Received: from localhost ([127.0.0.1]:44141 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MMiDe-0000nY-Se for ged-emacs-devel@m.gmane.org; Fri, 03 Jul 2009 08:50:22 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MMi7P-0003TX-Tz for emacs-devel@gnu.org; Fri, 03 Jul 2009 08:43:56 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MMi7F-0003OL-UK for emacs-devel@gnu.org; Fri, 03 Jul 2009 08:43:52 -0400 Original-Received: from [199.232.76.173] (port=35962 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MMi7F-0003OF-PW for emacs-devel@gnu.org; Fri, 03 Jul 2009 08:43:45 -0400 Original-Received: from mtah31.telenor.se ([213.150.131.4]:52402) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MMi7F-0005Ts-5Q for emacs-devel@gnu.org; Fri, 03 Jul 2009 08:43:45 -0400 Original-Received: from iph1.telenor.se (iph1.telenor.se [195.54.127.132]) by mtah31.telenor.se (Postfix) with ESMTP id DCE385A7FC for ; Fri, 3 Jul 2009 14:43:09 +0200 (CEST) X-SMTPAUTH-B2: X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgGUAIaZTUpV4S1uPGdsb2JhbACBUZc5AQEBATe0G4QSBQ X-IronPort-AV: E=Sophos;i="4.42,341,1243807200"; d="scan'208";a="26273046" Original-Received: from c-6e2de155.25-1-64736c10.cust.bredbandsbolaget.se (HELO coolsville.localdomain) ([85.225.45.110]) by iph1.telenor.se with ESMTP; 03 Jul 2009 14:43:09 +0200 Original-Received: from [172.20.199.2] (gaffa [172.20.199.2]) by coolsville.localdomain (Postfix) with ESMTP id 05C8B7FA07B; Fri, 3 Jul 2009 14:43:09 +0200 (CEST) User-Agent: Thunderbird 2.0.0.22 (X11/20090608) In-Reply-To: <87ws6qufng.fsf@uwakimon.sk.tsukuba.ac.jp> X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:111955 Archived-At: Stephen J. Turnbull skrev: > grischka writes: > > Jan Dj=E4rv wrote: >=20 > > > The XProtocol specification (the oldest I have is R6.8, the newest= is=20 > > > 7.4, they say the same thing) says this: > > >=20 > > > "Whether or not a server is implemented with internal > > > concurrency, the overall effect must be as if individual requests > > > are executed to completion in some serial order, and requests > > > from a given connection must be executed in delivery order (that > > > is, the total execution order is a shuffle of the individual > > > streams). >=20 > Jan is missing a number of issues, I think. First, there are (at > least) two clients and *two* connections involved here. One is > Emacs's, the other is the WM's. This leaves a lot of room for > nondeterminism ("shuffling") in the order in which configuration > events arrive on Emacs's connection. >=20 Not missing, just ignoring ... > Second, the process that generates the ConfigureNotify event is *not*, > and cannot be, atomic. When the WM has set the SubstructureRedirect > flag on the root window, a request by Emacs to configure one of its > (X) windows will propagate up the toolkit hierarchy to a shell window, > which will then execute X protocol. However the reaction of the > server to that protocol request is *not* to configure the window and > send a ConfigureNotify event. It is to *do nothing* except send a > ConfigureRequest event to the window, which will be processed by the > WM (because of the substructure redirection), not Emacs. The WM *then > issues the configuration request again*, which will succeed this time > because the WM "owns" the substructure redirection. And also the WM may choose to alter or drop that request. Which is why Lisp code that sets a frame size and immediately after expect that frame to have that size is no good. The sync-thingy is just an optimization so= that=20 lisp code will see its expected size as fast as we can make it happen, in= the=20 cases the WM does honor the size request. > "metacity"? As a developer of an X client, that's not my favorite > WM.... metacity's idea of "well-behaved" is a bit more restrictive > than fdo's standards specify. Agreed. Jan D.