from the If-only-s/he-provided-an-e-mail-address dept.
Hello! I fairly recently wrote MailTask, an email client that fits my needs better than the ones that had previously existed, and which I hope may be useful to other people as well. I think the program has the potential to be especially useful for other people who have to deal with a lot of email on a day-to-day basis and for power users, a category which I'm sure most of SoylentNews's readership falls into.
Overview:
When you start MailTask, the program puts up a window allowing you to view any of the top-level "folders" recognized by the program. These folders include the INBOX and Sent folders of any IMAP accounts you have the program configured to use, allowing you to view any emails in these folders, and also the "Tasks" folder, which is where the program expects you'll be spending most of your time.
The "Tasks" folder is a list of tasks, not of emails. A task contains a title, any notes-to-self related to the task, any number of unsent draft email messages related to the task, and any number of links to received or already sent email messages related to the task.
General Workflow of MailTask:
First, an email comes in. MailTask puts this message in the appropriate INBOX folder and either attaches this email to an existing task it can tell is related to the received email -- for instance, perhaps the received email is a reply to an email an existing task links to -- or it creates a new one and puts a link to the just-received message in the just-created task. The user looks at the task that has either been created or activated, looks at and possibly revises any notes-to-self, looks through the thread of related messages, composes a draft response to the received message, and sends the response. MailTask at this point will hide the task in question so that it doesn't clutter the view (there's a shortcut that lists you see hidden tasks), but will only make it visible again if new emails come in that are related to it. If an email ever comes in that doesn't need a response, you can manually hide or delete the task that was activated or created. Thus, the "Tasks" folder should ideally only ever contain "stuff you have to deal with and haven't".
Of course, the program is more flexible than that. You can create tasks that aren't related to any emails at all -- like a shopping list, for instance. You can set a task to be related to a meeting. If you do, the meeting will be added to your Google Calendar, the meeting task will go to the top of the task list so you don't miss it, and the meeting task can be used to hold notes for the upcoming meeting, unsent drafts related to the upcoming meeting, and sent/received emails related to the upcoming meeting. You can do a similar thing with tasks that are not meetings but have deadlines of some kind. You can also blacklist a certain sender, so emails from that sender are never added to tasks in the task list unless you do it manually. Alternatively, you can blacklist an entire account, but whitelist particular senders so that emails from them don't get blacklisted just because they were received by the blacklisted account.
The Code:
The code itself is extensible, so, if you're a Python programmer, the sky is the limit. The code related to dealing with incoming emails is all dispatched from a single function in the file mt_scrtry_rn.py. You don't need to know the entire internals of MailTask to add new features to the task handler. I added support for Google Calendar and blacklists/whitelists after the original design was long finished, and the support was easy to add. I also added support for adding a note to a created task stating which class of mine a student is in, based on the sender address of the email, since they almost never tell me. One thing I haven't done yet but know would be very easy to do is an autoreply feature.
A little bit more on the internals. The program itself is actually three related Python scripts. server.py is an IMAP client, and is in charge of syncing the other components with regard to emails that come in and tasks that are changed. client.py is the program that brings up the GUI and that the user interacts with -- it's expected there may be multiple clients running at a time, one on each of the user's computers. mt_scrtry_rn.py is the "utility client" which is in charge of updating the tasks in the task list based on newly received and sent emails. Both client.py and mt_scrtry_rn.py are "clients" in that they need to connect to the server run by server.py over TCP/IP. server.py needs to open two ports for the clients to connect to; the numbers of these two ports are configurable.
The UI:
The user interface is entirely keyboard shortcuts. If you look for the definition of valid_shortcuts in client.py, these shortcuts and their actions should be reasonably self-explanatory. If you have questions, please comment, and I'll answer them.
Installation:
To install the program, you'll need Python 2.7, the FLTK library, pyFLTK, which is a Python binding for the FLTK library. The hardest one of these to get working seems to be pyFLTK. I've successfully run the program on both Linux and MacOS X, and I expect Windows and other UNIXes will also work, but Windows is untested and there could possibly be problems. Comment if you have trouble, tell me what OS you're on, and I'll do my best to help.
Suggestions for improvement are greatly appreciated. I hope you like it! :)
(Score: 0) by Anonymous Coward on Monday May 29 2017, @10:37AM
Thank you for coding an actual application rather than going the Electron route!
(Score: 2) by Nerdfest on Monday May 29 2017, @11:13AM (5 children)
Always nice to have another email client available. I'm a KMail user these days, but may give this one a try. Seeing a name like "mt_scrtry_rn" makes me hesitate to try to extend it though :)
(Score: 1) by linuxrocks123 on Monday May 29 2017, @04:59PM (4 children)
I should maybe rename that file :) It's "MailTask Secretarial Runner", and I decided to just take out all the vowels.
(Score: 3, Insightful) by Nerdfest on Monday May 29 2017, @06:10PM (3 children)
Please don't do that. I get flashbacks to bad experiences with mainframe people who do that, whether the original names fits or not. making things unreadable is not generally a good idea. While on the topic of unsolicited code quality advice, i find the monolithic files for client, server, etc a bit hard to deal with, The code inside them actually looks pretty good other than the odd name and some magic numbers for some array offsets, etc. The large files will make it a bit of a pain to deal with merging code if you ever have people other than yourself working on it, in my opinion.
But of course, do what you want; you actually put the effort into making a nice email client. One of the bonuses of rolling your own solution is you get to be a dictator.
(Score: 2) by linuxrocks123 on Monday May 29 2017, @08:17PM (2 children)
Ha ha ... understood. It's probably not the best name, but I was having a hard time coming up with a good one. mt_sec_run.py didn't seem much better; mt_secretarial_runner.py was too verbose; etc.
Thanks for the advice. The largest file by far, and the only one above 1000 LOC, is client.py, and client.py is still only 2265 LOC. client.py should probably be split into two files, one with the UI component and one with the networking component, but I don't expect most "extension"-type code to need to touch client.py at all, so I haven't bothered refactoring it like that.
Even if the program isn't split up into as many files as it should be, there's not a lot of code duplication. mt_scrtry_rn.py actually imports client.py and uses its networking component, for instance.
(Score: 3, Insightful) by Nerdfest on Monday May 29 2017, @10:04PM
If you're okay with more unsolicited advice, I'd use "SecretaryRunner.py". The MT, for MailTask, is a little redundant as that's part of the git structure. If you're importing the networking code from Client, that section of code should be in its own file. It has little to do with duplication and everything to do with extracting units of re-use. It really helps for unit testing as well, as you can to things like mocking the networking code for doing testing.
(Score: 0) by Anonymous Coward on Tuesday May 30 2017, @08:08AM
> mt_secretarial_runner.py was too verbose
There is no such thing as too verbose :-) Bits are cheap. Tab completion does the typing.
All IMHO of course :-)
(Score: 2) by Nerdfest on Monday May 29 2017, @11:15AM
Seems to be missing. I only see "MailTask", the Android Taster module.
(Score: 0) by Anonymous Coward on Monday May 29 2017, @11:17AM (2 children)
A link?
(Score: 3, Informative) by takyon on Monday May 29 2017, @11:20AM (1 child)
Googled this one, will add to summary:
https://github.com/linuxrocks123/MailTask [github.com]
[SIG] 10/28/2017: Soylent Upgrade v14 [soylentnews.org]
(Score: 1) by linuxrocks123 on Monday May 29 2017, @04:53PM
That is indeed the link. Sorry for not including that, I meant to :(
(Score: 2) by ledow on Monday May 29 2017, @01:55PM (13 children)
I'm looking for a replacement for Opera, the old versions of which used to do mail as well as browsing.
Nothing yet comes close to the simplicity, and the rapid-narrow-search that it can do over nearly 20 years of email archives over dozens of different IMAP/POP3 accounts.
The problem I have, though, is that there's not even a hint at simplicity here. Servers and clients, python installs, and no screenshot to see the UI? How does it handle HTML email in modern HTML dialects? I'd be better off with Pegasus Mail (which I've tried, but which is definitely still stuck in the 1990's in UI terms).
The thing that gets me? Opera's mail client is the most boring and simple interface ever. And yet nothing seems able to replicate it.
I now run Vivaldi for a browser and Opera for a mail client and it's annoyingly disjointed. I long for the days where the two are merged again.
(Score: 1, Disagree) by Anonymous Coward on Monday May 29 2017, @03:16PM (4 children)
screenshots [atlassian.com]
(Score: 1, Disagree) by Anonymous Coward on Monday May 29 2017, @03:47PM
Screenshots are actually here: https://marketplace.atlassian.com/plugins/pl.com.tt.mailtask.MailTask/server/overview [atlassian.com]
The "Screenshot slideshow" link in "Media" has nine images.
(Score: 2) by linuxrocks123 on Monday May 29 2017, @04:36PM (2 children)
That's a different application. I don't have screenshots uploaded at the moment, but I'll upload a few.
(Score: 3, Informative) by linuxrocks123 on Monday May 29 2017, @04:56PM
Screenshots are uploaded to GitHub: https://github.com/linuxrocks123/MailTask/blob/master/screenshot1.png [github.com]
(Score: 2) by butthurt on Monday May 29 2017, @11:55PM
-- http://www.infoworld.com/article/2663734/applications/google-loses-gmail-trademark-case-in-germany.html [infoworld.com]
(Score: 3, Interesting) by el_oscuro on Monday May 29 2017, @04:30PM
Just looking at the code at https://github.com/linuxrocks123/MailTask/blob/master/html2text.py [github.com]
It looks like it converts html to markdown style text. Probably more secure too as most phishing schemes rely on hyperlink abuse.
SoylentNews is Bacon! [nueskes.com]
(Score: 2) by linuxrocks123 on Monday May 29 2017, @04:43PM
ledow,
The install could be simpler, but I think the actual day-to-day usage of the program is pretty simple. I'll be posting screenshots of the UI in a bit -- this is complicated by the fact I don't really want to publicly post my inbox to the Internet -- but I can assure you it's very no-frills.
HTML email is handled through html2text, a very nice library written by the late Aaron Swartz.
(Score: 0) by Anonymous Coward on Monday May 29 2017, @07:16PM
Sorry to be AC- I have a login but I'm weary of the low-life personal attacks here on SN.
I'm still using Old Opera for all pop3 email (the bulk of my email) and most browsing, and Vivaldi (with lots of blockers / privacy extensions) when / where I'm forced to. I don't mind the "lack of integration" - I'm not sure what that means anyway. In the rare case that I want to send an email to an address on a Vivaldi-rendered webpage, I just right-click the link, copy, and paste it into Opera mailer. I'm sure I could tell Windows I want Opera to be my mailer, but I don't trust Windows with that kind of information (all that "integration" seems to be the mechanism of much malware).
I keep thinking I need to migrate to Thunderbird but I fear things breaking, code bloat, and Opera mail ain't broke so why fix it?
(Score: 2) by ledow on Monday May 29 2017, @07:58PM (4 children)
Thanks for the replies, all the below.
Sorry, but this is just not going to be for me. The screenshot looks worse than some of the prototype mail clients I knocked up for personal use to test library functionalities 15 years ago.
And if it can't render HTML, pretty much that's ludicrous in this day and age (security is quite easy in HTML email - don't load scripts, and pretty much you're done - HTML/CSS has a purpose in a formatted, non-interactive message, Javascript does not).
Don't get me wrong, I've spent years with Linux on desktop and servers, I've even collected email over "telnet" when it's been necessary. A UI is certainly not the thing for some jobs and nothing REQUIRES a UI.
But in the modern era, a mail client that can't render formatted email and doesn't have a useful UI is really just a development project.
Even the "big-name" mail clients that are decades along can feel unworkable because of missing features or UI elements. Something like this is just a glorified newsreader from the 90's.
But I would pay through the nose for a proper mail client, even an open-source one. None of the ones you've ever heard of (whether ThunderBird, Pegasus or Outlook) are as workable as a three-pane Opera instance with IMAP/POP3 accounts.
(Score: 0) by Anonymous Coward on Tuesday May 30 2017, @12:39AM
I don't have html mail enabled on just about everything.
What ads are you deliberately reading that you get in mail?
That is the entire reason I don't use HTML in my email client. I also have HTML mail rendering disabled on my phone; I can't block pixel retrieval over the cell network and so I don't want to worry about such marketing/tracking.
Most emails that use HTML are fairly readable unless it's got a zillion constant contact or whatever marketing tracking links integrated. I can't really imagine what you need in email that is best served via a web page.
(Score: 3, Insightful) by boltronics on Tuesday May 30 2017, @03:45AM
I currently use Mutt, and have been for years. I'll give this program a look, although I'll be hard-pressed to switch (I'd probably be using Emacs for e-mail by now if I were going to).
If you need HTML just to read e-mail, you're doing it wrong (or at least, the people sending e-mail to you are).
It's GNU/Linux dammit!
(Score: 2) by linuxrocks123 on Tuesday May 30 2017, @03:53PM (1 child)
ledow,
I'm a little surprised to get criticism of the UI from this site. I agree it's not a piece of art, but I can assure the UI is more than functional, and I think that's the most important thing. Honestly, what the UI needs more than anything is a few more keyboard shortcuts. I find myself often doing repetitive click sequences to go into a task and look at the sole Related message it was created to link to. A few Ctrl-key sequences to handle that would be better. Maybe one day soon, when it finally annoys me enough and I have time to do something about it because it's summer, I may add some sequences to deal with that annoyance. Regarding the HTML email thing, it does render HTML email; it just renders it as MarkDown text using the html2text library.
But, hey, if you're happy with your current setup, that's the main thing. I will say that MailTask isn't a traditional email client, so stuff like a pretty UI, tabs, etc., are not where I put my focus. I wrote MailTask not because I thought Thunderbird and the rest were bad per se, but rather because I needed more management, organization, and filing capabilities than just custom IMAP folders and filters. Organizing related emails together and merging them into tasks (or "action items" I guess) is what I personally get out of MailTask that I couldn't get out of other email clients.
(Score: 2) by linuxrocks123 on Tuesday May 30 2017, @04:11PM
Additionally, here's what I think of HTML email (from line 1336 of client.py):
#VILE CREATURE, THOU DURST CALL UPON ME?
#WALK NO MORE, PERVERSION OF NATURE!
if body.get_content_type()=="text/html":
payload = mt_attache.text_html(body,mt_attache.FLTK_ENCODING)
else:
payload = mt_attache.text_plain(body,mt_attache.FLTK_ENCODING)
(Score: 0) by Anonymous Coward on Monday May 29 2017, @05:00PM
it's probably not for me, but good job on the license.
(Score: 0) by Anonymous Coward on Monday May 29 2017, @08:56PM
Are the hooks into the NSA database neatly integrated or do they use an obscure hack that crashes the system or chews up CPU and bandwidth?
(Score: 2) by NCommander on Tuesday May 30 2017, @10:00AM (3 children)
I may be willing to try this as a replacement for Thunderbird if a few things are added:
- USENET (more specifically NNTP support)
- GnuPG and S/MIME support (I use both for different purposes)
- KB controls so I can treat it as a graphical mutt.
I used (al)pine and later mutt for awhile before going back to Thunderbird due to usability annoyances.
Still always moving
(Score: 0) by Anonymous Coward on Tuesday May 30 2017, @03:54PM
As a suggestion, that you've likely already thought of, have you tried gnus(emacs)?
It seems to match your three requirements. In particular, it is designed around being a nntp reader. It also supports GnuPG and is KB control first, mouse second. On the downside it does have a decent learning curve and has all the flaws (and benefits) that is emacs.
(Score: 2) by linuxrocks123 on Tuesday May 30 2017, @04:07PM (1 child)
NCommander,
All of those are doable additions, and GnuPG support is already on my TODO list. There are a lot of keyboard shortcuts already, which you can find on line 1573 of client.py. The current shortcuts are roughly based on Emacs, but you could of course change the mappings if you wanted. I'll have to look more into how Mutt handles things in order to figure out what if anything beyond hacking the mappings is needed to make it mimic Mutt more closely.
USENET and S/MIME were not on my radar before, but I don't expect they would pose significant problems to implement. From an internals standpoint, GnuPG, S/MIME, and any keyboard shortcut modifications would go in client.py, and USENET support would go in server.py. If I have time near the end of the summer, I may be able to add support for those things. I'll contact you if/when those features are added.
Out of curiosity, what are you using USENET for?
(Score: 2) by NCommander on Tuesday May 30 2017, @09:12PM
I actually read newsgroups (comp.misc), GMane, and a few development newsgroups.
Still always moving
(Score: 2) by maxwell demon on Tuesday May 30 2017, @09:47PM (7 children)
So it only works with a Google account? What if I don't want to use Google Calendar?
The Tao of math: The numbers you can count are not the real numbers.
(Score: 2) by linuxrocks123 on Wednesday May 31 2017, @02:02AM (6 children)
The Google Calendar integration is totally optional. It actually won't even work unless you set up the Google Python bindings with a Developer ID.
(Score: 2) by maxwell demon on Wednesday May 31 2017, @05:38AM (5 children)
But is it Google Calendar or no calendar? Or is there a general calendar interface?
The Tao of math: The numbers you can count are not the real numbers.
(Score: 2) by linuxrocks123 on Thursday June 01 2017, @10:15PM (4 children)
Right now, Google Calendar is the only calendar supported. What is the other calendar you want to use?
(Score: 2) by maxwell demon on Sunday June 04 2017, @01:15PM (3 children)
One on my local computer.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 2) by linuxrocks123 on Wednesday June 07 2017, @12:55AM (2 children)
Okay. What kind of calendar? Owncloud or something?
(Score: 2) by maxwell demon on Wednesday June 07 2017, @07:22PM (1 child)
Currently I'm using tkremind for my calendar needs.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 2) by linuxrocks123 on Wednesday June 07 2017, @08:17PM
Is that just a flat text file managed by a command line program? Support for something like that should be trivial to add. You want to be a guinea pig?
(Score: 2) by Common Joe on Saturday June 03 2017, @02:29AM (2 children)
linuxrocks123, I have a question: You chose 2.7 over 3. Why?
My reason for asking is that I'm thinking about coding something in Python. I actually thought about using the language back 2009, looked at the war between 2 and 3, and decided to use something else. I've been busy with other things and haven't been back to learn it... until now. I haven't started learning it or coding up my new project yet, but I'll probably start in a couple of weeks.
I'm merely interested in your thoughts on the choice you made. It looks like version 2 will be deprecated in 2020.
(Score: 2) by linuxrocks123 on Wednesday June 07 2017, @01:35AM (1 child)
Hi.
Good question: inertia. Python 2 was the current version of Python when I learned it, and I just didn't feel like 3.x brought enough to the table for me to bother switching, so I kept using what I was familiar with.
Looking toward the future regarding the deprecation of Python 2.7 in 2020 ... my response is basically "yeah right". Even if the Python team does decide to abandon Python 2.7, making sure Python 2.7 still compiles and runs on modern platforms is not a lot of work, and I'm confident someone will do it. Not only that, there is already a fork of the language, called Tauthon, which has actually taken the 2.7 codebase and added features from 3.x in a backward-compatible way ... which is really what those jokers who made Python 3 should have done to begin with. Tauthon aka "Python 2.8" will just get more traction if 2.7 is actually killed off for good.
However, in the unlikely event 2.7 is really killed off, and no one picks up the maintenance baton, and Tauthon also dies, I do know enough Python 3 to know that the MailTask codebase could be ported to Python 3.x without much trouble.
Now, regarding your getting into Python: I'm sorry to hear that the language war scared you off back in 2009. Python 2 and 3 are both excellent languages, and learning either one would be an excellent choice. Python is one of my two favorite languages, and I can't say enough good things about it. Python has a shallower learning curve than almost any other language I've come across, yet is also an impressively powerful tool, so, if you're still interested in learning Python today, then, first, good, please do! You'll love it!
Second, learn Python 3, not 2. Making Python 3 an incompatible upgrade to 2.7 was one of the worst decisions the core team ever made, and that decision caused massive damage to the language's community, including your decision to steer clear of the whole mess in 2009, but that decision is at this point is a sunk cost, which has already been paid. Python 3.x in 2017 is an ever-so-slightly better language than 2.7, with ever-so-slightly less cruft, and Tauthon/2.8 is at least currently a one-man show. The massive time and effort spent by third-party developers upgrading their libraries to be compatible with 3.x would have been entirely unnecessary but for the core team's arrogant and inconsiderate attitude, but they've already spent that time, so you might as well use the result of their work.
If you learn 3 and then later do want to contribute to a 2.7 project, like MailTask, you won't have much trouble. From the perspective of a 3.x developer, 2.7 is just a subset of 3.x with a few missing features.
(Score: 2) by Common Joe on Wednesday June 07 2017, @03:09AM
Thank you for the info. I greatly appreciate it.
Based on what I recently read, it had looked like that 3 was the way to go. I had pretty much already decided to use it, but your comment gave me a brief pause. I had assumed it was inertia, but asking you directly was an opportunity I couldn't pass up.
About a year ago, I read some documentation about the Python language as a prep to learn it, then life got in the way. This time, I think I have enough time to actually code something.
Change of topic: I'd like to give MailTask a try when I have a moment. I use Outlook at work and Thunderbird at home. I'm not happy with either. Like for instance, when forwarding a message, neither of them can seem to get it right. They both completely mangle the forwarding process so the original email looks like a mess. I keep thinking to myself, "How could they screw up something so simple?"
I read in a comment above that you use Markdown. Interesting choice. One of the things that bug me about modern day Email programs is they want to do everything a browser does. I just want a simple, safe way to communicate with the ability to do everyday things like bolding and bullets. Inline pictures is about as complicated as I'd go. (And only if I choose to allow the email program to load the pictures.) If I want something more complex in a document, I don't see why (as a society) that we shouldn't be attaching an odt or docx document or whatever we want. But that's me ranting. I'm curious to see exactly what you did with Markdown and the choices you made.
I have no idea what your program does and when I see it, I won't be overly critical. I know it isn't polished yet and it's a work in progress. Thanks for putting your labor of love out there. I hope to do the same thing one day with some ideas I have. I can't wait to use Python and make that a reality.