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: Infrastructural complexity. Date: Mon, 20 Jul 2009 17:32:45 +0200 Message-ID: <4A648E1D.1000007@gmx.at> References: <20090712180623.GA1009@muc.de> <1247784574.6302.83.camel@dell-desktop.example.com> <1247787842.6302.90.camel@dell-desktop.example.com> <1247793496.6302.112.camel@dell-desktop.example.com> <1247797261.6302.137.camel@dell-desktop.example.com> <1247798678.6302.156.camel@dell-desktop.example.com> <87ocrjtafd.fsf@stupidchicken.com> <1247871746.6287.157.camel@dell-desktop.example.com> <1247966060.7410.63.camel@dell-desktop.example.com> <4A62F7AD.4000609@gmx.at> <87eiscn223.fsf@catnip.gol.com> <4A643993.5080302@gmx.at> <87ljmjl9ow.fsf@catnip.gol.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: ger.gmane.org 1248104037 5902 80.91.229.12 (20 Jul 2009 15:33:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 20 Jul 2009 15:33:57 +0000 (UTC) Cc: Thomas Lord , rms@gnu.org, cyd@stupidchicken.com, lennart.borgman@gmail.com, joakim@verona.se, emacs-devel@gnu.org, juri@jurta.org, monnier@iro.umontreal.ca, acm@muc.de, drew.adams@oracle.com To: Miles Bader Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jul 20 17:33:48 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 1MSus5-0005QI-A1 for ged-emacs-devel@m.gmane.org; Mon, 20 Jul 2009 17:33:45 +0200 Original-Received: from localhost ([127.0.0.1]:51630 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MSus4-00028X-7u for ged-emacs-devel@m.gmane.org; Mon, 20 Jul 2009 11:33:44 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MSurI-0001o1-Bt for emacs-devel@gnu.org; Mon, 20 Jul 2009 11:32:56 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MSurD-0001lf-Bp for emacs-devel@gnu.org; Mon, 20 Jul 2009 11:32:55 -0400 Original-Received: from [199.232.76.173] (port=53806 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MSurC-0001lW-Vy for emacs-devel@gnu.org; Mon, 20 Jul 2009 11:32:51 -0400 Original-Received: from mail.gmx.net ([213.165.64.20]:46703) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1MSurC-000370-3K for emacs-devel@gnu.org; Mon, 20 Jul 2009 11:32:50 -0400 Original-Received: (qmail invoked by alias); 20 Jul 2009 15:32:48 -0000 Original-Received: from 62-47-60-166.adsl.highway.telekom.at (EHLO [62.47.60.166]) [62.47.60.166] by mail.gmx.net (mp031) with SMTP; 20 Jul 2009 17:32:48 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX18cZuNNfyQcfhIet4F01YseNwnSv5fhv4QdhSZxfw WHY98ZdIFHcHAH User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) In-Reply-To: <87ljmjl9ow.fsf@catnip.gol.com> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.71 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) 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:112832 Archived-At: > Once you start letting the WM have any control all bets are off -- > remember, it's _not_ just initial placement, but movement, sizing > [think: tiling WM!], additional WM-added frames, dealing with the many, > many, differences between WMs on different platforms, etc. The user is supposed to control the WM and tiling WMs should manage multiple Emacs frames better than Emacs itself is able to tile a frame into multiple windows. After all that's what tiling WMs are supposed to do well. > This approach seems a complete non-starter to me, unless we have control > over the WM as well (and we don't)... ... hopefully we don't since otherwise we could never blame the WM for not being able to handle our frames ;-) Anway, converting windows to frames in order to tear them off and back to windows when docking them back seems hardly feasible to me. Not to think of multiple (un-)wrapping menu- or toolbars somewhere in the middle of a frame just because the user decided to resize that frame. So once we decided that the multi-frames approach is a non-starter we should decide that tear-off windows and windows with menu- or toolbars are non-starters too. Can we agree on that? martin