Re: [Evolution-hackers] Bug #232

On Fri, 2003-11-14 at 01:43, JP Rosevear wrote: 
> On Tue, 2003-11-11 at 04:40, James Ogley wrote:
> > Many many centuries ago, there was a lot of discussion, and work towards
> > fixing bug #232 - reading TNEF attachments.  The solution that was
> > arrived at was using gtnef (kudos Larry)
> > 
> > However, gtnef has never been ported to GNOME2, and I discovered this
> > morning that bug #232 appears to still exist in 1.4.5.  There have been
> > a couple of calls on bugzilla, attached to the bug report for the bug to
> > be reopened, but nothing's been done.
> > 
> > I'll be adding the description of how I rediscovered the lost bug #232
> > to bugzilla, but I wanted to raise it here.  Are there plans to port
> > gtnef to GNOME2, and if not is there a new solution to bug #232?
> Larry, any thoughts on the time involved for this?

A simple port probably wouldn't take very much time, but the problem is
the way gtnef works is far less than ideal.  Because of licensing issues
(the tnef code base it was derived from is GPL'd) it cannot be linked
into the mailer so it has to be an exe component.  Since it has to be a
component it has to duplicate a large amount of the mail display code to
make an interface that looks similar to the normal attachment
interface.  So it is both extremely slow to activate and annoying to

In a perfect world camel would provide a plugable method for allowing a
content type to present itself as a group of several other content-types
so that the display code could be reused and someone would write an
LGPL'D tnef decoder.  I can't write the tnef decoder myself since I've
already messed with the current code a lot but if someone is serious
about doing it we could probably clean room reverse engineer the GPL'd
version.  I'll let one of the mail hackers comment on the plugable camel


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]