From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: gdba probs Date: Mon, 09 Dec 2002 15:21:25 -0500 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: <15855.47556.171128.631234@nick.uklinux.net> <15858.42618.90759.591751@nick.uklinux.net> Reply-To: rms@gnu.org NNTP-Posting-Host: main.gmane.org X-Trace: main.gmane.org 1039484004 21853 80.91.224.249 (10 Dec 2002 01:33:24 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 10 Dec 2002 01:33:24 +0000 (UTC) Cc: emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18LZH1-0005gL-00 for ; Tue, 10 Dec 2002 02:33:23 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 18LZRL-0002Vr-00 for ; Tue, 10 Dec 2002 02:44:04 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18LUPc-0007G5-02 for emacs-devel@quimby.gnus.org; Mon, 09 Dec 2002 15:21:56 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 18LUPD-0007Ch-00 for emacs-devel@gnu.org; Mon, 09 Dec 2002 15:21:31 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18LUP8-0007Ag-00 for emacs-devel@gnu.org; Mon, 09 Dec 2002 15:21:29 -0500 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18LUP7-0007AN-00 for emacs-devel@gnu.org; Mon, 09 Dec 2002 15:21:25 -0500 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.10) id 18LUP7-0008CS-00; Mon, 09 Dec 2002 15:21:25 -0500 Original-To: nick@nick.uklinux.net In-reply-to: <15858.42618.90759.591751@nick.uklinux.net> (message from Nick Roberts on Sun, 8 Dec 2002 01:55:06 +0000) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Emacs development discussions. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:10023 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:10023 Apart from the errors, I like to think much of the functionality is self evident. Maybe so, but the person who said he didn't know what these windows were for apparently did not find it so. How about if you talk with him about why it wasn't evident to him? At the moment there's only what you get from `C-h f gdba' (reproduced below). Can you think of ways to make the text in the windows themselves show what they do and how to use them? Please put some effort into this. A major part of the idea of graphical interfaces is that they can, with some effort, be self-explanatory. But just putting text in a window doesn't automatically achieve that; you have to design your interface for it. One idea is that a window, when "empty" or nearly so, could show a command list for that window. However, it could also contain buttons which provide a graphical way to give the window commands. Then a user would not need to learn and remember special commands for each window. This would be an easier-to-use interface. There are a further 3 buffers (assembler, registers, display) that the user might want to display and each user will have his/her own preferences. I have looked at trying to save a window configuration and I note that this concept has been on the TODO list of desktop.el for a long time. I can imagine this is not an easy thing to do. This is less important. As long as there is a way people can specify the layout they want, that is good enough for starters. Please focus on making the interface natural and self-explanatory. As for what each buffer does I could start to document it in info format but its still evolving and I don't know if there is sufficient interest yet. Please do document it (in Texinfo format). Miles suggested this: The GUI debuggers I've used typically start out displaying only one or two windows (e.g., the command window and a source window, sort of like normal gud mode), but offer toolbar buttons to easily pop up others; once the others are popped up, they are updated continuously. Note that for some window types, you can pop up more than one instance -- e.g. memory display windows, where you may want to display several regions of memory simultaneously. I think this is a good idea. If users want to change configurations as they go, then saving a configuration permanently is NOT very useful.