From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: Aquamacs distro for OS X like behavior Date: Tue, 05 Apr 2005 02:02:32 +0200 Message-ID: References: <7ca1709813602da58a139cee58fb4c63@gmail.com> <3b9c4e2f33d37fed55f640dcafbc8d65@gmail.com> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1112659385 6783 80.91.229.2 (5 Apr 2005 00:03:05 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 5 Apr 2005 00:03:05 +0000 (UTC) Cc: Stefan Monnier , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Apr 05 02:03:00 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DIbWb-0000Xm-Fp for ged-emacs-devel@m.gmane.org; Tue, 05 Apr 2005 02:02:33 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DIb5O-0007L5-A0 for ged-emacs-devel@m.gmane.org; Mon, 04 Apr 2005 19:34:26 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DIb5A-0007Jr-9Q for emacs-devel@gnu.org; Mon, 04 Apr 2005 19:34:12 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DIb55-0007HP-Jm for emacs-devel@gnu.org; Mon, 04 Apr 2005 19:34:07 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DIb55-0007Gl-0Q for emacs-devel@gnu.org; Mon, 04 Apr 2005 19:34:07 -0400 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1DIbWg-0003Ss-VI for emacs-devel@gnu.org; Mon, 04 Apr 2005 20:02:39 -0400 Original-Received: from localhost ([127.0.0.1] helo=lola.goethe.zz) by fencepost.gnu.org with esmtp (Exim 4.34) id 1DIbWa-0004fH-Ap; Mon, 04 Apr 2005 20:02:32 -0400 Original-To: David Reitter In-Reply-To: <3b9c4e2f33d37fed55f640dcafbc8d65@gmail.com> (David Reitter's message of "Tue, 5 Apr 2005 00:27:10 +0100") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) 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:35565 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:35565 David Reitter writes: > On 4 Apr 2005, at 18:47, David Kastrup wrote: > >> There is considerable leeway in those goals. For example, >> different file selection dialogs and similar are quite common, and >> in fact, the whole widgetry stuff (like customize and co) could be >> made to make use of the native widgets where available. > > From a UI and an OS X perspective, customization buffers should > definitely go into proper dialogues with native widgets. I don't think this is OS X specific. Mapping hierarchical widgets to native constructs would be a lot of work. Right now only atomic widgets like the file selection dialog are, if at all, available. I think that some consensus, even if I can't remember this being discussed before, could be achieved that this would be generally desirable at least where the actions were mouse-induced: present people with familiar interfaces. There are drawbacks, like not being able to use the power of Emacs' keyboard commands to manipulate entries, but for people annoyed by that, there would always be the possibility to configure the Emacs text widgets as default. >> Well, we do have something like customization themes IIRC, but I >> don't know their extent and how they are used. If a whole set of >> defaults were to be changed by a single theme (and could be changed >> back at will), then an out-of-the-box configuration that was >> different on MacOSX would be quite tolerable. > > I don't know if an out-of-the-box configuration for the default > Emacs is needed - the idea of a distribution like what we > demonstrate with Aquamacs might already do the job. If you change options with setq, it becomes more troublesome to customize them than if a theme was available. Also it has the problem that people used to NTEmacs can't easily get the same behavior from Aquamacs and the other way round. Shipping all Emacs versions with both an NTEmacs and an Aquamacs customization theme would mean that you get something set up to match your platform best as delivered, but if you are already acquainted to the defaults of a different platform, a single customization will turn your NTEmacs into an Aquamacs and the other way round. > Either way, merely using a 'theme' with the on-board means, for > example to make customization buffers look different, will IMHO not > tweak the application UI enough. A user interface is more than just > pretty buttons and a choice of colors. Customization themes in Emacs have nothing to do with pretty buttons and choice of colors. They are simply a single name for a complete set of customized variable defaults. [Other ramplings about "theme" removed] > Consequently, I'm arguing for native widgets wherever possible. For > a new project - or one with less tradition and less importance, > there is stuff like wxWidgets. In this case, I would be grateful if > someone would implement more Carbon (or Cocoa) based UI stuff, and > if better internal interfaces existed, for example to handle > scrollbars correctly. This is stuff only developers experienced with > Emacs code - yes, you! - can implement. This is stuff only developers experienced with the native scrollbars - yes, you! - can implement. Basically this needs knowledge of both the native widgets as well as Emacs. Your point of view is that other Emacs developers should be forced to learn the details of the widgets of your platform. Are you going to buy me a Mac and developer information for that? My point of view is that it makes more sense if the Mac developers learn the details of Emacs. At least, both code and documentation for Emacs are freely available, so you need not stumble around in the dark. And you can actually test what you are playing with, having a Macintosh available. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum