Re: [evolution-patches] Plugin for resizing inline attachments (images)

[Srinivasa Ragavan <sragavan novell com>]

On Thu, 2005-06-16 at 17:46 +0800, Not Zed wrote:
> Only had a very quick look at this, sorry, but a few comments about this
> sequence of code below.
> 
> Yeah it works, etc, but its not very efficient, copying whole images
> around from memory to memory to memory.
> 
> You should create a new stream class, which writes to the pixbuf loader.
> Then you just 'deocde to stream' to that stream, and you end up with a
> decoded image!  That way you dont need to generate all these
> intermediate copies of the binary data.  You will still need to write
> out a memory stream for the output though.  You could alsoimplement it
> as a 'stream filter' and do some pipelined processing on it (ok maybe
> not).
> 
> Also note that camel_stream_mem_new() can't fail, so dont bother
> checking for null.
> 
> Other issues - dont put inline_disposition on the type!  This will cause
> all attachments to be expanded all the time, which overrides the current
> behaviour.
> 
> The other massive problem with this code - actually i dont know how it
> is even working - is that the format handler runs in another thread.
> You simply can't call any gtk+ stuff from this thread, NONE, about all
> you can do - and you should have at least looked at what the existing
> code does, which is nothing like this - is insert an <img> tag, and set
> a callback for when the streamed content of that tag is requested.
> 
> Then when it is requested you then create the stream from the part, and
> output it directly to the html stream (thus, saving the need for another
> temporary full-copy of the data).
> 
> Still - it wont handle resizing, you can't override the scaling, and you
> can't do anything useful with the image (i dont know, do you get the
> original still as an attachment you can play with?).  But these are more
> cosmetic, the details above are serious.
> 
> Another approach would be to create a gtkimage and feed that the data
> (it MUST be from a 'pobject' callback), that way it could resize, but on
> the other hand then you'd have to re-implement the
> em-format-html-display popup menu somehow, since it wont know anything
> about it.
> 
I guess, i have done part of it. I have done it as a pobject call back,
and handle image/* attachment parts differently from other parts.

Probably, ill send out the running code by tomorrow.. for a initial
thought.

> On Tue, 2005-06-14 at 11:39 +0530, Srinivasa Ragavan wrote:
> > +       out = camel_stream_mem_new ();
> > +       if (out == NULL)
> > +               goto fail;
> > +       
> > +       content = camel_medium_get_content_object((CamelMedium
> > *)t->part);
> > +       if (content == NULL)
> > +               goto fail;
> > +       if (camel_data_wrapper_decode_to_stream(content, out) == -1
> > +           || camel_stream_flush(out) == -1) {
> > +               goto fail;
> > +       }
> > +       camel_stream_reset (out);
> > +       
> > +       loader = gdk_pixbuf_loader_new();
> > +       do {
> > +               len = camel_stream_read(out, buffer, sizeof (buffer));
> > +               if (len > 0) 
> > +                       gdk_pixbuf_loader_write(loader, buffer, len,
> > NULL);
> > +       } while (len>0);
> > +       
> > +       camel_object_unref(out);
> > +       out = NULL; 
>