Re: Functional requirements for Gnus

[Kai Grossjohann <grossjohann@amaunet.cs.uni-dortmund.de>]

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