From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Brady Montz Newsgroups: gmane.emacs.devel Subject: Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date) Date: 19 Apr 2002 09:27:58 -0700 Sender: emacs-devel-admin@gnu.org Message-ID: References: <4.3.2.7.2.20020417123512.0398e4c8@san-francisco.beasys.com> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1019237716 27785 127.0.0.1 (19 Apr 2002 17:35:16 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Fri, 19 Apr 2002 17:35:16 +0000 (UTC) Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 16ycI0-0007E2-00 for ; Fri, 19 Apr 2002 19:35:16 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 16ycbS-0005S5-00 for ; Fri, 19 Apr 2002 19:55:22 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 16ybHg-0006oK-00; Fri, 19 Apr 2002 12:30:52 -0400 Original-Received: from c64-255-216-95.sea1.cablespeed.com ([64.255.216.95] helo=sandman.balestra.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 16ybF0-00061X-00 for ; Fri, 19 Apr 2002 12:28:06 -0400 Original-Received: (from bradym@localhost) by sandman.balestra.org (8.10.2/8.10.2) id g3JGRxL02631; Fri, 19 Apr 2002 09:27:59 -0700 (PDT) X-Authentication-Warning: sandman.balestra.org: bradym set sender to bradym@balestra.org using -f Original-To: xemacs-design@xemacs.org, emacs-devel@gnu.org In-Reply-To: Original-Lines: 109 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.5 (bamboo) Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.9 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:2793 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:2793 Per Abrahamsen writes: > Actually, I believe the trend in HCI research is to avoid or minimize > the use of dialog boxes. They really _are_ in the way, also in a GUI. > This doesn't mean the current (X)Emacs interface is good, it certainly > isn't intuitive to a new user. I HATE dialog boxes. Even if they are done OK (you actually CAN do a search in a program with the dialog box without the box getting in the way) it still irritates to have this thing flashing in my face. And don't forget the programming effort for creating and maintaining all those dialog boxes. > So I think we really ought to forget about dialog boxes, and instead > concentrate on making the minibuffer interface more accesible. > > Here is some suggestions: > > 1. Put the minibuffer in the top by default. It is more visible > there, and users of MSIE or Mozilla (and apparently some modern > IDE's) will not be surprised to find an input field there. This seems a good idea. If it's in a clearly seperate "bar" then it could make the screen less confusing when you have multiple windows sharing a single minibuffer. We also might be able to use this region to clearly show when a recursive edit is going on. Perhaps a little stack or such. > 2. Add some strong visual clue (color, animation, whatever) when focus > change to the minibuffer. The toolbar should probably also change > to "relevant" buttons for the action, and for those actions that > are relevant, a > > 3. Maybe even have a dialog box (!) pointing to the minibuffer when > activating a menu entry that traditionally pop up a dialog. The > box should have an "OK" and a "Don't pop up next time" button. > > 3b Alternatively a "novice" mode, where an arrow point to minibuffer, > and a tooltip like message explain what is going on. Many games > teach their UI in that way. (What a cool way to organize the > standard (X)Emacs tutorial! But I digress). I think I prefer 3b, preferably after some tooltip sorta timeout. After 10 seconds of a patiently waiting minibuffer (or if there's incorrect input), it might be time to give a hint. I do think that emacs needs a major GUI overhaul if it's to thrive. I don't know if the minibuffer is the worst offender (IMHO - it's the ascii art), and I'd rather see a comprehensive rethinking of the GUI over piecemeal improvements (a dialog here, a menu reorg there). Things I would like: 1. actual widgets, with an abstraction layer that allows a single lisp spec of them to work on multiple backends - gtk, qt, cocoa, vt100. This might restrict them to be fairly simple, but that's not necessarily a bad thing. I think speedbar and customize are good examples of us straining against the limits of text. 2. one of the things I LOVE about emacs is how easy it is to find stuff. "hmmm, I need something to sort a region, what could that be." C-h a and there you go. MUCH better than trying to figure out something in word, for example. But this assumes a LOT of knowledge about emacs. (like "region"). I do think emacs the pack here, but it's got SO much stuff to find I believe it needs to make another go at advancing the ball. I can imagine something where functions not only have a doc string, but enough info for a more cleverly interactive browser/searcher than M-x apropos to easily find them (we may not need much more for that), easily connected to the customize options relating to that function, and ideally a mini-tutorial or example code for those functions/variables. I'd like something where someone can enter a "what do you want to do" sorta thing, get a nicely scrollable/searchable table, where then can click on each item to customize, read about, or see it in action. That would rock. 3. we have a nice set of tools for managing which files/buffers you have open and how to switch between them: ibuffer, iswitchb, various things like desktop.el, speedbar, buffer-menu, ... It might be good to settle on one or a few different ways of using all of these and making them more obvious for beginners. Again, this plays into an emacs strength. I've used no other editor where I could have 200 files open and stay sane. The faster I can find, open, and switch to and between files, the happier I am. Unfortunately, most beginners I've seen never figure out what emacs can do here. I think all four (including the minibuffer) of these items are examples of both irritating user-interface deficiencies and great strenghts emacs has. I love the minibuffer, the ability for simple little lisp programs to have an interface, having lots of stuff to find, and a wide variety of file/project management tools. We don't have to change, damage, dumbify emacs to make it "easier" to use; we can do a lot to make it easier to use emacs's best features. My personal interests are (1) and (2). I've been swamped with work for the last few months, but I'm really wanting to be able to have an aquafied emacs for my mac. So, I have a lot of personal interest in working on the "yet another toolkit" issue. And (2) just seems really neat to me. -- Brady Montz bradym@balestra.org