Re: Another balsa bug... (was Re: crashes)

[Michael Gerdts <gerdts cae wisc edu>]

I included Michael Johnson's entire message to me back to the list.  Please
forgive the old:new content ratio...

On Fri, Mar 24, 2000 at 07:03:28AM -0500, Michael Johnson wrote:
> Michael Gerdts wrote:
> > 
> > On Thu, Mar 23, 2000 at 09:40:28PM -0500, Michael Johnson wrote:
> > > Matthew Guenther wrote:
> > > >
> > > > Using a GtkText widget, couldn't you simply display any parts that are
> > > > text/plain in the widget, but everything else goes to the attachment pane?
> > >
> > > I'd suggest that anything that is text/plain goes in the widget, UNLESS
> > > the part in question has a name associated with it (Content-Disposition
> > > or parameter to Content-Type) in which case it should be treated as an
> > > attachment.
> > >
> > > ..mj
> > 
> > There are several other types that can be displayed as text and would be
> > rather annoying to have to click on to open them.  For instance, balsa
> > would be rather useless for me to read postmaster mail, where most messages
> > contain three parts: text/plain, message/delivery-status, and
> > text/rfc822-headers.  Presumably text/enriched and text/html are ones that
> > people expect to be able to treat as "normal mail" and not as something
> > that requires a separate window to be opened to be viewed.
> 
> In addition, Pawel Salek wrote:
> > And thanks for the attachment discussion. I get impression that user
> > should be able to select MIME types to be shown as text, the rest would 
> > be represented as attachments. I wouldn't insert inline links in text
> > before gtkhtml or something similar is ready.
> 
> Perhaps we could use this general rule: Anything that is message/* or
> text/* and does not have a name associated with it is displayed inline.
> Anything else is an attachment. For the time being, this may result in
> some inline content being rather ugly (text/enriched and text/html for
> example) until a more powerful text display widget is in place.

Perhaps it would be a good idea to use an existing HTML widget to display
everything.  It seems as though eventually an HTML-capable widget will be
necessary and there are already such widgets available in projects like the
GNOME Help Browser and Mozilla.  I'm not familiar with the specifics of
their use, but it seems as though slapping <pre> </pre> tags around a
text/plain (along with replacing special characters with &whatever;) would
work easily.  text/enriched could be handled similarly by converting to
html.  HTML could be displayed directly...

OR perhaps the better approach is to use bonobo to bring in the
type-specific displayer.  Presumably this would make it easy to deal with
alternative message display techniques.  For example, I imagine that some
people would like to have audio controls embedded into the message when
they get an audio/basic attachment, particularly if that is their primary
way of communicating with a particular person.  Other people may want to
forgo the overhead of starting up the audio app, since when they get
audio/basic files they either delete or save them without listening.

This also has interesting implications for composing... wouldn't it be nice
to be able to select entirely different input methods for composing
messages?  Perhaps when I send mail to my brother, I use the voice
recognition composer, but when I send mail to linux-kernel, I am probably
in a programming frame of mind and would like a vi or emacs compatible
composer.  Unless of course I am on my web pad.  Then my default composer
should be whatever works best with its handwriting recognition module.

> This rule only works well for multipart/mixed messages. Other multipart
> types have different semantics and would be better handled in other
> ways. For example, multipart/alternative would require Balsa to display
> only one of the possible alternatives as inline content and either
> ignore or treat as attachments all the other alternatives.
> 
> ..mj

Mike