From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: grischka Newsgroups: gmane.emacs.devel Subject: Re: moving window handling into lisp Date: Mon, 24 Aug 2009 15:10:23 +0200 Message-ID: <4A92913F.6000805@gmx.de> References: <4A89AA46.6050502@gmx.de> <4A8BC2CD.5060303@gmx.de> <4A8BF3E0.5090304@gmx.at> <4A8D375D.9090905@gmx.de> <4A8D46DA.4090500@gmx.at> <4A8DA56F.7070908@gmx.de> <4A8E916E.3020109@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 1251121719 2611 80.91.229.12 (24 Aug 2009 13:48:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 24 Aug 2009 13:48:39 +0000 (UTC) Cc: emacs-devel@gnu.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Aug 24 15:48:32 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 1MfZuQ-0002nN-V0 for ged-emacs-devel@m.gmane.org; Mon, 24 Aug 2009 15:48:31 +0200 Original-Received: from localhost ([127.0.0.1]:43664 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MfZuQ-0003WE-FA for ged-emacs-devel@m.gmane.org; Mon, 24 Aug 2009 09:48:30 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MfZK0-0002jP-Fo for emacs-devel@gnu.org; Mon, 24 Aug 2009 09:10:52 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MfZJu-0002f0-Jl for emacs-devel@gnu.org; Mon, 24 Aug 2009 09:10:51 -0400 Original-Received: from [199.232.76.173] (port=55676 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MfZJu-0002es-G0 for emacs-devel@gnu.org; Mon, 24 Aug 2009 09:10:46 -0400 Original-Received: from mail.gmx.net ([213.165.64.20]:53787) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1MfZJu-0003L6-10 for emacs-devel@gnu.org; Mon, 24 Aug 2009 09:10:46 -0400 Original-Received: (qmail invoked by alias); 24 Aug 2009 13:10:43 -0000 Original-Received: from p57A099A3.dip0.t-ipconnect.de (EHLO [192.168.1.3]) [87.160.153.163] by mail.gmx.net (mp045) with SMTP; 24 Aug 2009 15:10:43 +0200 X-Authenticated: #18588216 X-Provags-ID: V01U2FsdGVkX1/krBcejtvkePwj3GEVmdAZ9tbaZp/YrnJBuIXTq/ wdN0gjsO8fxm9t User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) In-Reply-To: <4A8E916E.3020109@gmx.at> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.67 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:114556 Archived-At: martin rudalics wrote: > > The distributed fuzzy-machine cannot be simplified because it defends > > itself by, well, being distributed. > > The weak point of that machine is the size_window routine which IIUC is > called by most of these distributed components. It is true that it can weaken the machine if only one routine exists to access some fundamental functionality. In such case it would try to force the implementation of other routines to do somehow the same thing, just not quite. There are signs that it has already started to do so with size_window, e.g. the out-factored shrink_window with a ratio formula somehow different from the one used for enlarging (as we know by now). > >> > Me thinks there are much more thoughts spend on 'window-min-height' > >> > now than there possibly were at the time when it was first > introduced. > >> > >> Not really. Any window-manager has to deal with the possibility that a > >> window gets to small when its parent-window shrinks. All we can do is > >> make such cases occur rarely, in practice. > > > > Window-managers don't deal with shrinking parent windows. They deal > > with fixed desktop/root windows. > > I obviously meant "any Emacs window-manager" here. I don't even know > whether desktop window-managers use concepts like parent-windows or the > split-window paradigm. > > > With individual applications it's called "layout-manager", which exist > > in the various GUI toolkits. > > > > layout-managers are invisible containers that allow you to place > > components like widgets or windows of other layout-managers within, > > and to set a policy how these components are arranged, such as "box", > > "grid", "flow", ... > > > > The concept of min-size exists too, though individually for each > > component, and it actually means what it says, that is "keep this > > thing at least that large". Consequently a case of "too small" can > > never happen. > > So if a component doesn't fit it's iconified in some sense of that word? "Doesn't fit" can only mean that the component can't cope with the situation by automatic adjustment. In that case the user is expected to fix the situation manually, either by configuring the interface, (e.g. removing other components), or by upgrading the display hardware (such as when you can't see the OK buttons on some dialogs more frequently). In any case, iconification (in any sense of the word) belongs to manual configuration, not to automatic adjustments. --- grischka > > martin >