realbasic-nug
[Top] [All Lists]

Re: musings about an RB community email client

To: REALbasic NUG <realbasic-nug at lists dot realsoftware dot com>
Subject: Re: musings about an RB community email client
From: Joe Strout <joe at inspiringapps dot com>
Date: Thu, 29 Nov 2007 13:16:49 -0700
Delivered-to: listarchive at realsoftware dot com
Delivered-to: realbasic-nug at lists dot realsoftware dot com
References: <8F17E477-B386-492D-B5F3-A2F02BC93A62 at inspiringapps dot com> <191F6F50-52DD-4D10-BB5C-E8807236E868 at bradrhine dot com>
On Nov 29, 2007, at 12:03 PM, Brad Rhine wrote:

> When wielded properly, the HTMLViewer is great. I use it in a couple
> of projects and have not encountered all that many issues. For simple
> display of HTML mail (in which clicks on external links would
> presumably be passed off to the default browser), I think it would
> suffice.

It might.  We'd certainly want to code the display area (probably  
itself a ContainerControl) in such a way that we can easily try  
several different ways of displaying message content.  One of the fun  
things about this project would be trying different approaches and  
seeing what works best.

> I think SQLite is the way to go for storage. It would make searching a
> (very fast) breeze. I agree about a way to export to mbox, though.

By SQLite, you mean the current REALDatabase, yes?  I can see some  
sense in that.  Break the message up into parts: one row for each  
header of each message, plus another row for the body.  Then you can  
quickly search by any combination of headers and/or body.   
Reconstituting the message won't be too hard either.

I'm just a fan of the mbox format because it's the Unix standard,  
it's simple and reliable, and when something goes wrong the user can  
fix it because it's human-readable.  But I recognize that it's not a  
very good design for searching when thousands of messages are  
involved.  So, OK then, store in REALDatabase but export (perhaps  
regularly) to mbox.

> On Nov 29, 2007, at 12:09 PM, Bart Silverstrim wrote:
>>
>> As I understand it, RB doesn't have an "inline" ability in a text  
>> field
>> to do something like spell checking on the fly (feature request?)

Geez, there's another Mail bug with quoting -- I copied the above out  
of a reply to Bart, pasted it in here, and Mail insists on adding  
another level of quotation, as if Brad were quoting Bart, which is  
not the case.  And I have no way of correcting this manually as far  
as I can see.  We can do better!  :)

But to your point, Bart, there are a couple of solutions out there  
for spell checking in an EditField.  I haven't used most of them, so  
we'd need to investigate (or maybe get Charles on board -- I think he  
wrote one of them).

>> Wouldn't a lot of the features similar to Apple Mail require that  
>> kind
>> of functionality?  The latest version (or so I've heard rumor) has  
>> the
>> ability to extract something like a meeting date and subject, click a
>> button, and it will automatically add it as a notice in iCal, for
>> example.

That's no big deal.  It's easy to see (via CharPosAtXY) what the  
cursor is over, extract the date or username or whatever, and do  
something with it.

> On Nov 29, 2007, at 12:12 PM, Louis G5 Batayte wrote:
>> Eudora had a feature I liked. It would show the text of the email and
>> would offer the reader to "Open in a Browser" for the HTML stuff.  
>> This would let you see the HTML code without executing it.  If you  
>> wanted to see the html page it would ship it off to your default  
>> browser.


I kinda like that idea.  There are actually two ways to do this: most  
clients that send HTML email also include a plain-text part.  So you  
could either show the plain-text part, or extract the text out of the  
HTML.  Maybe give the user the choice.  But then include an "Open in  
Browser" widget the user can click to save the message to a temp file  
and ShowURL it.

This could be an alternative content viewer, which we can try out in  
parallel with the HTMLViewer-based one that Brad's going to write for  
us.  :)  If they both work well, and people can't agree on which is  
best, we include them both and let the user choose.

Anyone else interested in this, as a developer or a potential user?

Best,
- Joe

--
Joe Strout
Inspiring Applications, Inc.
http://www.InspiringApps.com



_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>


<Prev in Thread] Current Thread [Next in Thread>