From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Lennart Borgman Newsgroups: gmane.emacs.devel Subject: Re: moving window handling into lisp Date: Fri, 21 Aug 2009 15:58:26 +0200 Message-ID: References: <4A8D12B3.6070502@gmx.at> <4A8D46C9.1010108@gmx.at> <4A8D66D5.3000600@gmx.at> <4A8D92AC.5010404@gmx.at> <4A8E95A3.5040604@gmx.at> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1250863148 31914 80.91.229.12 (21 Aug 2009 13:59:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 21 Aug 2009 13:59:08 +0000 (UTC) Cc: Emacs-Devel devel To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Aug 21 15:59:01 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 1MeUdw-0005ag-M6 for ged-emacs-devel@m.gmane.org; Fri, 21 Aug 2009 15:59:01 +0200 Original-Received: from localhost ([127.0.0.1]:42186 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MeUdw-0005Je-3I for ged-emacs-devel@m.gmane.org; Fri, 21 Aug 2009 09:59:00 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MeUdq-0005JM-Ui for emacs-devel@gnu.org; Fri, 21 Aug 2009 09:58:54 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MeUdl-0005Eu-9B for emacs-devel@gnu.org; Fri, 21 Aug 2009 09:58:53 -0400 Original-Received: from [199.232.76.173] (port=37960 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MeUdl-0005En-2V for emacs-devel@gnu.org; Fri, 21 Aug 2009 09:58:49 -0400 Original-Received: from an-out-0708.google.com ([209.85.132.243]:10382) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MeUdk-0008TQ-31 for emacs-devel@gnu.org; Fri, 21 Aug 2009 09:58:48 -0400 Original-Received: by an-out-0708.google.com with SMTP id b6so291687ana.21 for ; Fri, 21 Aug 2009 06:58:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=flyXdv/kj19SdBu47Mz7FEQKbTdSlHLEL+CHB0pvWyg=; b=D/Kx/bhgBrPh0YsB17P1aIye5FD7Ms/jpF+Cm5wZ8aDobw37C/KqcXKnywAv0dJXKD VZIW48R3FSxq/uLPPBxNU5r2tKKCr9KZgJI+W5vDRqALLL4r2tyw5bUjdEnUPbve1LhX ADGETUwKbXTrNb+TNxGOeD+M/fr7fpI+dKfnI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=f7MOAf4z07vN8B4hE+9o51Z5l/8XMm1XDhejMNa6/yrxO5zEyHRZbFJpwFd4brqOuw +VO87ogZKCEkpuwhb2quCbbfHrNagmdTWrwybL/jae8i2/NUmzzAejdcOsbHZzXPaaAo BIkn3sJjKlFgTPFBAEPTKIHCu8QbtxCY25nYg= Original-Received: by 10.101.121.3 with SMTP id y3mr1036715anm.53.1250863127445; Fri, 21 Aug 2009 06:58:47 -0700 (PDT) In-Reply-To: <4A8E95A3.5040604@gmx.at> X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) 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:114476 Archived-At: On Fri, Aug 21, 2009 at 2:40 PM, martin rudalics wrote: >>>> 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? =C2=A0A list? Yes, but I am starting to wonder a bit what I really want. It looks to me like I instead could use your new functions+remove restriction check. See below. >> Do I understand you right, do you say: These should set the size >> without any checking. > > The new size of one window. =C2=A0Applying the new sizes of all windows i= s > done transactionally, all at once (or none at all if there's a failure). There are some ideas here that are rather similar but differs a bit. You and Stefan have been talking about the idea about treating the size changes as transactions with possible roll back. That seems ok to me. But I choosed a little bit different route. I am trying to make the calculations first and only apply them if new sizes fit. However with my idea there is still the problem of applying the new sizes without bumping into any restriction during the applying phase. This could happen even if you know that the final result will fit. That was the reason I asked for a function above to set the sizes of all children at once. But such a function will not help since bumbing into restrictions can happen further down the tree also. So what I need is still a way to apply the new sizes without restriction checks during that phase. Am I clear enough when I try to explain this? How should I do to avoid the restrictions in this phase? >> 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? You ... ;-) Yes, I know that this is lacking. I have been wondering about this part. It is not clear to me how resizing and deletion/creation of windows are tighed together in the current code. I think those parts should be broken up. Can you please try to explain how things are now and if you see some way to brake those things apart? >> 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. =C2=A0The > more so because you want redisplay to happen in between. =C2=A0What do yo= u > think window-configurations have been invented for? Window configurations was invented for this situation. It has a much broader use. But if you say it is impossible to switch this pointer then I surely assume that you are right (since you know better about how the code has been structured). Then I assume that window configurations must be used to get my suggestion to work. The drawback I see then is that window pointers migh gets lost. Are there any way around that? >> 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. I am sorry, but I can't see why that should make it harder to understand. The text to show can of course be changed to avoid some confusion. Does not that help? >>> You do undelete all the time. =C2=A0It'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. How can you avoid that when the frame gets too small? >>>> - 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. Are there no sign at all that there are 0-size windows there? > martin >