Re: [Evolution-hackers] invoking composer via bonobo...

[Not Zed <notzed ximian com>]

On Wed, 2003-07-23 at 17:43, Karl Pitrich wrote:
> On Tue, 2003-07-22 at 18:45, Not Zed wrote:
> > On Wed, 2003-07-23 at 02:23, Karl Pitrich wrote:
> > > On Tue, 2003-07-22 at 18:40, David Woodhouse wrote:
> > > > On Tue, 2003-07-22 at 12:28, Karl Pitrich wrote:
> > > > > 
> > > > > i found composer.c (by miguel) in some old cvs somewhere,
> > > > > and am trying to make it work with evolution 1.4.
> > > > 
> > > > P'raps I'm being dim -- it's not entirely unheard of... but what does
> > > > this do that isn't also achieved by 
> > > > 
> > > > evolution-1.4 "mailto:address example com&subject=Fish&cc=pit root at
> > > 
> > > well, i need to make a mozilla plugin, providing a JavaScript
> > > LiveConnect object that interfaces to evolution.
> > > 
> > > the main problem is, "mailto:..."; cannot add attachments or set
> > > the body content type.
> > 
> > You can actually set attachments, not sure about the content-type thing,
> > or setting the body content.
> > 
> > I think you use a parameter like: attach=filename (or gnomevfs uri)
> > 
> > If you're just going to exec a program anyway you should probably use
> > that, and additional parameters could be added I guess.
> > 
> > If you want a programmatic interface, then thats another issue ...
> 
> 
> it's a lot more complicated. for instance, the document to be attached
> needs to be retrieved via webdav and locked via soap.

So you can't just copy it locally and then use the local copy?  I'm not
saying its ideal, just a workaround.

> > 
> > Are you saying show_composer works, but setting any headers doesn't?  Or
> > does nothing work?
> 
> right, Composer_show() works, setHeaders, setBody do not work they
> segfault.

I guess backtraces might help find out whats going wrong ...

> > 
> > Actually the composer is part of the mailer, which is a shlib object, so
> > you can't really instantiate it outside of the shell anyway.  Otherwise
> > you'll get another copy, which could interfere with the existing copy in
> > nasty (tho probably non data-destroying) ways.
> 
> why other copy? can't i just open a new composer window from an existing
> evolution instance and fill in the fields?
> thats what the mailto: does, i guess...

Because bonobo-activation, which is used to instantiate the object,
can't do singleton instances of shared library factories.  I think
anyway.

The mailto: thing goes via a different interface which talks to its
private instance of the mail object, effectively.  If you could get a
mail object from the shell object and then a composer object from the
mail object, then things might work - none of the interfaces exist
currently however.  For 2.0 we want to work on adding such interfaces I
think.

> > So I think the 'current way' is to get hold of the shell (or mail
> > component?) object and do a 'send to url' method, which is for all
> > intents exactly the same as exec'ing evolution with the url.
> 
> so i have to instate a shell object via bonobo?

I dunno - something like that I guess.

corba_shell =
bonobo_activation_activate_from_id("OAFIID:GNOME_Evolution_Shell", 0,
NULL, &ev);

then something like
GNOME_Evolution_Shell_handleURI(corba_shell, uri, &ev);

with a mailto uri.