From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.devel Subject: Re: moving window handling into lisp Date: Fri, 21 Aug 2009 14:40:03 +0200 Message-ID: <4A8E95A3.5040604@gmx.at> References: <4A882312.6020106@gmx.at> <4A8D12B3.6070502@gmx.at> <4A8D46C9.1010108@gmx.at> <4A8D66D5.3000600@gmx.at> <4A8D92AC.5010404@gmx.at> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1250858459 15737 80.91.229.12 (21 Aug 2009 12:40:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 21 Aug 2009 12:40:59 +0000 (UTC) Cc: Emacs-Devel devel To: Lennart Borgman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Aug 21 14:40:51 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 1MeTQJ-0001b8-6s for ged-emacs-devel@m.gmane.org; Fri, 21 Aug 2009 14:40:51 +0200 Original-Received: from localhost ([127.0.0.1]:42911 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MeTQI-000554-LB for ged-emacs-devel@m.gmane.org; Fri, 21 Aug 2009 08:40:50 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MeTPi-0004yE-1S for emacs-devel@gnu.org; Fri, 21 Aug 2009 08:40:14 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MeTPc-0004xS-V1 for emacs-devel@gnu.org; Fri, 21 Aug 2009 08:40:13 -0400 Original-Received: from [199.232.76.173] (port=46164 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MeTPc-0004xO-OM for emacs-devel@gnu.org; Fri, 21 Aug 2009 08:40:08 -0400 Original-Received: from mail.gmx.net ([213.165.64.20]:32804) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1MeTPc-0001D0-6j for emacs-devel@gnu.org; Fri, 21 Aug 2009 08:40:08 -0400 Original-Received: (qmail invoked by alias); 21 Aug 2009 12:40:06 -0000 Original-Received: from 62-47-38-0.adsl.highway.telekom.at (EHLO [62.47.38.0]) [62.47.38.0] by mail.gmx.net (mp035) with SMTP; 21 Aug 2009 14:40:06 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/HpSVLPd7HJRcxtKUs6z++riRx8c/M5AZiDFC/TU /4POnXgIdzbOtT User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) In-Reply-To: X-Y-GMX-Trusted: 0 X-FuHaFi: 0.65 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) 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:114473 Archived-At: >>> The algorithm computes level by level in the second pass (ie on its >>> way down) how the windows should be sized. So you have the sizes for >>> all windows on that level at once. >> I still don't understand what a "level" is. > > All children to a window are on the same level. So you want a routine to set the sizes of all children of a window? What would you want to pass to that routine? A list? > Do I understand you right, do you say: These should set the size > without any checking. The new size of one window. Applying the new sizes of all windows is done transactionally, all at once (or none at all if there's a failure). > You can make a lisp copy of the configuration. This copy should > contain just the info needed to compute the new sizes. If you want the > sizes after deletion then just do not include the window you want to > delete in the copy. And who does delete the window _and_ resize the remaining ones? > I guessed there must be some pointer (in a general sense) for each > frame to the root window. I do not know the actual implementation, but > I just glanced at it. Unfortunately it takes some time for me to read > C so I guess a little. I can see there is a Lisp_Object called > root_window in struct frame. This is the pointer I am talking about. > > My question (and suggestion) to you is this: Would it be possible to > temporarily replace the frames root_window with a new window when the > frame size gets so small that the window configuration does not fit? > Whether this is easy (or perhaps even possible) is of course dependent > on the details in this implementation. > > It depends on for example on how drawing of windows are done. Is > drawing of a frame something that starts from the frame and then goes > down to look at the windows? Or does the windows live a life on their > on in this regard? I have assumed the former when I suggested to just > swap the roor_window pointer. You know more about the implementation > details and can probably give a better answer. It would get us into hell's kitchen to just swap some pointers. The more so because you want redisplay to happen in between. What do you think window-configurations have been invented for? > You seem to suggest that it would be hard to understand for the user. > In that case, why? Because at the time the window-manager shrinks my Emacs frame I usually want to work with some other application. >> You do undelete all the time. It's completely transparent. > > How can it be transparent if windows disappears and reappears? I must > be misunderstanding you somehow... There might be no redisplay in between. >>> - size-0 windows in a case like this would be the same. >> Many applications do that. > > Can you explain how you mean? In many applications (Thunderbird is one of them) I can make subwindows disappear completely by dragging one of their borders and make them reappear later by dragging on the border where they disappeared. martin