Re: [evolution-patches] Revised mailing list actions plugin

[Not Zed <notzed ximian com>]

On Sat, 2004-10-30 at 12:23 +0200, Meilof Veeningen wrote:
> Hello,
>
> I have done a revised mailing list actions plugin based on NotZed's 
> comments:
I'd like to see the errors in an e-error file, everything else at least marked for translation, and not using strings to pass the function type - which wont work if you want to deal with a different type of list engine (for reasons i explained last time).

>   http://home.wanadoo.nl/meilof/filez/mailing-list-actions.tgz
>
> Some comments:
>
> > - it would be really nice to send the mail automatically, not have it
> >just bring up a composer, which doesn't really explain what you need to
> >do to use it.  This is a feature for 'newbies', so it should be fairly
> >fullproof and easy to use.  Like if its a mailto: link, it could run the
> >mailto, and then pop up a window explaining what it did and what to
> >expect (e.g. 'you should receive a mail with help soon' or whatever).
> >To do this you create a message, then append it to the outbox, and then
> >trigger a queue send (em_reply_to_message goes through all of these
> >steps through various (async) callbacks).  Creating a message is a bit
> >painful but not impossibly so.
> >  
> >
> Yes, I thought about that, too, but I guess you'd need a dialog box 
> first in which the user can choose from which e-mail address to send the 
> message to (in the case of multiple e-mail addresses). Sending it from 
> the address the mailing list message was sent to will usually work, but 
> especially for subscribing it would be nice to have a choice. I should 
> be able to hack together such as dialog box, but it would mean a lot 
> more code. This dialog box could contain the "You should receive a mail 
> with help soon" remark though.
A druid would fit the bill here - wouldn't it?  It could explain what its doing and finish with the last bit.  Although druids are such a pain to code and use.
> Another thing: for the "Mailing List" menu item in the popup menu, I 
> /had/ to specify a callback method, otherwise Evo would crash on load
> the menu... Currently I have activate="", but this is probably something 
> that should be fixed in evo?
I'll have a look into that.  Although in general a plugin could crash evo as much as anything else so if it isn't tested i guess thats just bad luck.
> Finally, in the message view dialog, due to my plugin hook, the "Action" 
> menu shows up before the other File, Edit, ... menu's. Is there a way to 
> control that behavior?
Thats bonobo stuff, you might even need a different bonobo xml file thing.  In the main view it shouldn't be at the end of the menu either, it should probably be in the second to last section.  Don't ask me how to do it though i have no idea with bonobo menus.

--

Michael Zucchi <notzed ximian com> "I'm stuck in a reality I can't imagine could be real." Novell's Evolution and Free Software Developer