From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David De La Harpe Golden Newsgroups: gmane.emacs.devel Subject: Re: Add function to make frame topmost? Date: Sun, 02 May 2010 16:27:24 +0100 Message-ID: <4BDD99DC.2040901@harpegolden.net> References: <4BDB5A6E.5060803@harpegolden.net> <4BDB8886.4050202@harpegolden.net> <4BDC6CE7.8060400@harpegolden.net> <4BDCA50D.9080000@harpegolden.net> <88A13318710742A89D64A4F416461969@us.oracle.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: dough.gmane.org 1272814060 8601 80.91.229.12 (2 May 2010 15:27:40 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 2 May 2010 15:27:40 +0000 (UTC) Cc: =?ISO-8859-1?Q?=27Jan_?=, 'Lennart Borgman' , 'Stefan Monnier' , =?ISO-8859-1?Q?Dj=E4rv=27?= , 'Emacs-Devel devel' To: Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun May 02 17:27:38 2010 connect(): No such file or directory 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.69) (envelope-from ) id 1O8b50-0005Hi-38 for ged-emacs-devel@m.gmane.org; Sun, 02 May 2010 17:27:38 +0200 Original-Received: from localhost ([127.0.0.1]:41773 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O8b4z-0007PR-HR for ged-emacs-devel@m.gmane.org; Sun, 02 May 2010 11:27:37 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O8b4u-0007PI-GL for emacs-devel@gnu.org; Sun, 02 May 2010 11:27:32 -0400 Original-Received: from [140.186.70.92] (port=59756 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O8b4s-0007P9-Od for emacs-devel@gnu.org; Sun, 02 May 2010 11:27:31 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O8b4r-0006CW-33 for emacs-devel@gnu.org; Sun, 02 May 2010 11:27:30 -0400 Original-Received: from harpegolden.net ([65.99.215.13]:60751) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O8b4q-0006CO-UO for emacs-devel@gnu.org; Sun, 02 May 2010 11:27:29 -0400 Original-Received: from [87.198.55.196] (87-198-55-196.ptr.magnet.ie [87.198.55.196]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "David De La Harpe Golden", Issuer "David De La Harpe Golden Personal CA rev 3" (verified OK)) by harpegolden.net (Postfix) with ESMTP id 29422971C; Sun, 2 May 2010 16:27:27 +0100 (IST) User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20091109) In-Reply-To: <88A13318710742A89D64A4F416461969@us.oracle.com> X-detected-operating-system: by eggs.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:124430 Archived-At: Drew Adams wrote: > Not to divert the discussion from your patch, but wouldn't we anyway need > something like what bug #4476 suggests in order to save & restore frame configs? > If we are intending to be let users persistently save the state of their windows > and frames, then won't we need to record and restore (or at least request > restoration of) the fine-grained stacking order/z-order? Maybe. Apart from leaving the z-order alone: One could try to restore something as close as possible to a saved absolute z-order, but users might be surprised by that since non-emacs windows may well have come and gone in the meantime, and it would mean restoring a frame configuration might bury and interleave frames behind non-emacs windows. It might all seem a bit random. Restoring the relative z-order of emacs frames, but restoring them contiguous in the stack and maybe at the top (not always-on-top, I just mean in front) on restoration, might be a better option. Except when the user is saving and restoring in rapid succession in the one session, as I imagine most people's typical use of frame-configuration-to-register/jump-to-register is. Then it might be the surprising/annoyingly-raisey option, and leaving the z-order as-is might be best. Or could punt and make it an option as to which of the three happens and/or which of the three happens in which context (same-session set-frame-configuration from a "live" frame configuration object vs. from a deserialized "undead" frame configuration object) Probably need coding up and testing for a real assessment.