mailtomutt-devel Mailing List for MailtoMutt.app
Status: Alpha
Brought to you by:
nothingmuch
Menu
▾
▴
mailtomutt-devel — Developer's Mailing List
You can subscribe to this list here.
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(8) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|
|
From: Andre B. <an...@bo...> - 2004-06-28 07:28:38
|
FYI :)
----- Forwarded message from in...@ve... -----
Delivered-To: an...@lo...
Delivered-To: and...@ho...
Date: Sun, 27 Jun 2004 11:57:06 -0700
To: sou...@pr...
=46rom: in...@ve...
Subject: New Product Submission Approved
Your product submission of=20
MailtoMutt=20
has been approved. You should now be able to find the product at our site.
<!--if ("Changed category to Internet Utilities.
--Dan Daranciang")-->
The approver of your application included the following message:
Changed category to Internet Utilities.
--Dan Daranciang
Thank you,
TechTracker.com
----- End forwarded message -----
--=20
> YOU FUCK YOU FUCK YOU FUCK YOU FUCK YOU FUCK YOU FUCK YOU FUCK
> FUCK YOU FUCK YOU FUCK YOU FUCK YOU !!!!!!!!!!!!!!
Someone who does wallpaper designs for bordellos, apparently.
(Jess Anderson on spamassassin-talk to ch...@te...)
|
|
From: Andre B. <an...@bo...> - 2004-06-26 21:43:56
|
Shalom!
On Thu, Jun 24, 2004 at 07:14:08PM +0300, Yuval Kogman wrote:
> > /* Currently we cannot abstract the instance of the object into an
> > instance of mutt.
> > Why this? We could have some instance vars, like
> sure, but that's not abstracting a mutt process...
Well, then I don't see the pointn in using the word "currently" :)
> If mutt had some way of controlling it, like via distributed objects,
> or whatever, we could abstract a 'mutt' into a class... That's what I
> was talking about.
Forget it. Mutt will _never_ have such an API. Wait for Sven's bark :)
=20
> Abstracting a message - it's probably already been done. Since currently
> the message is written to a file, why not just use a real object, or
> write one, that knows RFC822 well (like Mail::Message on the CPAN),
> with which has a method called 'writeToFile', and have the Mutt class
> keepusing messageFromFile if it has something like that right now... =3D)
Ok, going this path brings us to something rather interesting. Suppose,
we write an RFC conformant class representing a message. Next, we write
a plugin class (if needed) and some plugins, Mutt.*, Pine.*, Elm.*, and
then we rename the project to MailtoConsole.
- url gets caught
- MailtoConsole looks up which console mail program to use and loads
the corresponding plugin
- In parallel, it creates a new instance of the message class. This
instance's functions get overridden by the plugin (or something like
this (don't know how the plugin thing works in Cocoa))
- Depending on the plugin, it decides how to create the proper mail
message and send it.
Man, that would be neat. We're not restricted to Mutt. I mean, what
"features" do we have to offer? Right now, its like "yeah, you can send
mails through mutt using a single click on a mailto: link". Later, it
would be "You can send a mail using ANY console mail program". We write
a proper API and let the other users write the plugins (if there are
any).
Of course, the list up there is maybe completely wrong. I am quite
tired and it was a hard Saturday. But to me, it sounds good.
Cheers & HAND
Andr=E9
--=20
matt (16:04:15): but, the alternative is that we all report to ken and then=
we
have a weekly conference call with 3000 participants. can you imagine the
combined noise of 3000 people trying to eat a kebab while pretending to lis=
ten?
(my chef matt in a jabber chat about flat hierarchi=
es)
|
|
From: Yuval K. <not...@wo...> - 2004-06-25 16:15:23
|
On Fri, Jun 25, 2004 at 17:41:29 +0200, Andre Bonhote wrote: > /* Currently we cannot abstract the instance of the object into an > instance of mutt. > * Hence all the methods are class methods, which return no value, and > start a new mutt in a new terminal window */ >=20 > Why this? We could have some instance vars, like sure, but that's not abstracting a mutt process... =3D) If mutt had some way of controlling it, like via distributed objects, or whatever, we could abstract a 'mutt' into a class... That's what I was talking about. > NSArray *toAddresses; > NSArray *ccAddresses; > NSArray *bccAdresses; > NSString *subject; > NSString *messageText; > NSArray *attachments; > ... >=20 > And one instance method: >=20 > (BOOL)newMessage; Abstracting a message - it's probably already been done. Since currently the message is written to a file, why not just use a real object, or write one, that knows RFC822 well (like Mail::Message on the CPAN), with which has a method called 'writeToFile', and have the Mutt class keepusing messageFromFile if it has something like that right now... =3D) my 2c --=20 () Yuval Kogman <not...@wo...> 0xEBD27418 perl hacker & /\ kung foo master: /me sneaks up from another MIME part: neeyah!!!!! |
|
From: Andre B. <an...@bo...> - 2004-06-25 15:41:36
|
Hi Yuval Didn't see you online now, thus I am asking here. There's a spot I don't understand in Mutt.h: /* Currently we cannot abstract the instance of the object into an instance of mutt. * Hence all the methods are class methods, which return no value, and start a new mutt in a new terminal window */ Why this? We could have some instance vars, like NSArray *toAddresses; NSArray *ccAddresses; NSArray *bccAdresses; NSString *subject; NSString *messageText; NSArray *attachments; ... And one instance method: (BOOL)newMessage; During init, we read out the URL and fill the newly created object. After that, we just call [self newMessage]; We could sort out all the "is defined?" stuff there. No need for 20 functions. Why did you mention this in the comment? Cheers Andr=E9 =20 --=20 "In the long run, every program becomes rococo, and then rubble." -- Alan Perlis |
|
From: Andre B. <an...@bo...> - 2004-06-24 07:40:14
|
Hi I got used to cvs commit after removing bugs, to always have a properly working version in CVS. So don't be astonished when I remove one line and commit. Old habit. Cheers Andr=E9 --=20 God is real, unless declared integer. |
|
From: Andre B. <an...@bo...> - 2004-06-23 11:11:47
|
On Wed, Jun 23, 2004 at 12:37:16PM +0200, Andre Bonhote wrote: > cvs on sf.net down? Stupid me. Commit done. --=20 Never laugh at live dragons. -- Bilbo Baggins [J.R.R. Tolkien, "The Hobbit"] |
|
From: Andre B. <an...@bo...> - 2004-06-23 10:37:18
|
cvs on sf.net down? -- Hope is a waking dream. -- Aristotle |
|
From: Andre B. <an...@bo...> - 2004-06-23 10:13:01
|
Hi I implemented the automatic logout after using mutt and the auto-quit. The latter brings in a problem. Although it's nice that mailtomutt quits after it has done its job - how do we want to introduce preferences when the app isn't running anymore? I suggest we add a preference pane to the system preference. What do you think? This gives us the ability to completely differentiate between the app and the prefs. Cheers Andr=E9 --=20 Real programmers use "cat > a.out" |
