From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/16356 Path: main.gmane.org!not-for-mail From: Kai Grossjohann Newsgroups: gmane.emacs.gnus.general Subject: Re: Functional requirements for Gnus Date: 28 Aug 1998 11:29:47 +0200 Sender: owner-ding@hpc.uh.edu Message-ID: References: NNTP-Posting-Host: coloc-standby.netfonds.no Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII X-Trace: main.gmane.org 1035155242 27278 80.91.224.250 (20 Oct 2002 23:07:22 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2002 23:07:22 +0000 (UTC) Cc: ding@gnus.org Return-Path: Original-Received: from gizmo.hpc.uh.edu (gizmo.hpc.uh.edu [129.7.102.31]) by sclp3.sclp.com (8.8.5/8.8.5) with ESMTP id FAA27225 for ; Fri, 28 Aug 1998 05:30:28 -0400 (EDT) Original-Received: from sina.hpc.uh.edu (sina.hpc.uh.edu [129.7.3.5]) by gizmo.hpc.uh.edu (8.7.6/8.7.3) with ESMTP id EAF07659; Fri, 28 Aug 1998 04:01:32 -0500 Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Fri, 28 Aug 1998 04:30:16 -0500 (CDT) Original-Received: from sclp3.sclp.com (root@sclp3.sclp.com [209.195.19.139]) by sina.hpc.uh.edu (8.7.3/8.7.3) with ESMTP id EAA17908 for ; Fri, 28 Aug 1998 04:29:58 -0500 (CDT) Original-Received: from waldorf.informatik.uni-dortmund.de (waldorf.informatik.uni-dortmund.de [129.217.4.42]) by sclp3.sclp.com (8.8.5/8.8.5) with ESMTP id FAA26957 for ; Fri, 28 Aug 1998 05:29:51 -0400 (EDT) Original-Received: from ramses.informatik.uni-dortmund.de (ramses.informatik.uni-dortmund.de [129.217.20.180]) by waldorf.informatik.uni-dortmund.de with SMTP id LAA10462; Fri, 28 Aug 1998 11:29:49 +0200 (MES) Original-Received: by ramses.informatik.uni-dortmund.de id LAA05792; Fri, 28 Aug 1998 11:29:48 +0200 Original-To: Steinar Bang In-Reply-To: Steinar Bang's message of "26 Aug 1998 16:15:45 +0200" Original-Lines: 61 X-Mailer: Gnus v5.6.41/Emacs 20.3 Precedence: list X-Majordomo: 1.94.jlt7 Xref: main.gmane.org gmane.emacs.gnus.general:16356 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:16356 I've been thinking about the UI issues regarding this. I find that there are at least three different ways of presenting MIME messages to the user (especially multipart messages). I'm giving them titles to show where I got the inspiration. (1) `The TM alternative' The article buffer contains a button for each part. Textual parts also have the text included below the button. It is possible to move between the buttons. Each button can be pressed, causing the corresponding part to be displayed or saved on disk. There are two sub-alternatives: make one button per part and different keys for playing and saving (or, for down-mouse-2, a menu); or make two buttons per part, one for playing and one for saving. (2) `The digest alternative' Users can type C-d on a multipart message, causing it to be exploded as if it were a digest. In the resulting summary buffer, there are commands for viewing/playing each part (g or RET, I guess), and for saving each part. But how should the original article be displayed? One possibility would be to split the article window into two parts, one showing the nndoc digest summary and the other showing the message part currently selected. (The nndoc digest summary would be like a table of contents of the current article.) Another possibility would be to concatenate the textual parts, maybe interspersed with little markers showing where the non-textual MIME parts are. (3) `The X u alternative' For multipart messages, there is a command which creates pseudo-articles similar to the ones created by `X u' and friends. Either there's one pseudo-article per part and there are two commands, one for viewing/playing that part and another for saving it to disk, or there are two pseudo-articles per part, one for viewing/playing and one for saving. It is not yet clear to me how the original article should be displayed in this case. Maybe with the textual parts concatenated and little markers for the non-textual parts? I am not at all sure which alternative I would prefer. All of them have their merits. The advantage of (1) is that one gets a pretty good overview of the whole message contents, and it blends well with inline image displaying. The advantage of (2) is that there are lots of potentially useful things one could do in the nndoc summary buffer: save the part to a file (encoded or decoded), make a followup to that part only, copy that part into another group, ... Coming to think of it, I think I like (3) the least, but (1) and (2) are ties. Whatcha all think? kai -- OOP: object oriented programming; OOPS: object oriented mistakes