Next Release In Development

I'm working on a new release of PopTrayU. It's going to have some more fun new IMAP features like moving spam messages to the server's spam folder on delete and likewise for trash. Hopefully "archive" on the server for gmail too if I can get that working.

But...I know there's also some lingering bugs in 5.1.5 that I haven't been able to stomp out yet. So now's your chance to hop on over to the PopTrayU discussion board on Sourceforge and weigh in about which are the most important bugs that I should prioritize.

[blackwind]

Not a bug (so I'm not posting it in that section), but something I'd love to see in light of your current IMAP focus: rule support for Gmail labels. My workflow would be greatly simplified if I didn't have to maintain one set of rules on Gmail and a duplicate set in PopTray.

[Jessica Brown]

Great suggestion. Can you tell me a little about what you envision as far as a use case of how you would want to use this feature?

Would you just want a new rule action "add gmail label" (and/or remove label?) Or would you also want to be able to select a message from the message list and add a specific label? Or view what labels are assigned to a specific message in the message list? Automatically display label information in some manner?

I'll probably start with just rule (and possibly toolbar) actions for adding or removing labels for now, because that's simple and some of those other features are...not :)

[blackwind]

I was hoping for a rule condition, actually. Specifically, I have a TON of different rules in Gmail to apply labels, and instead of duplicating those rules in PopTray, I'd prefer to just say, if Gmail label matches "Receipts", change tray icon to green. That said, I like all of your ideas as well, particularly label display in the message list.

Also, a %LABELS% macro for the Execute File action would be great.

[Ed P]

Maybe it's time for a new email app. One named IMAPTray. With all the bells and whistles an IMAP app can have. Let PopTrayU continue to access IMAP accounts but not with the sophistication a full fledged app can bring. Two small apps, rather than one big one, should be easier to maintain and each should run faster.

Something to think about.

[Horst]

Sorry, but this is not usefull at all.
There are many poeple which have a mix of Pop3 and IMAP accounts.
This users would have to run 2 tools instead of one.
I guess you are not really programming
because you would not expect PopTrayU to run faster with your suggestion.
There are many other possible enhancements which can be implemented.

[Ed P]

Yes, many of us have multiple email accounts but rarely are they of equal importance. The IMAP accounts are less secure than my POP3 accounts as such they are used for less important mail/notifications/etc and they are only checked a couple of times a day where as the others are checked several times an hour.

An efficient PoptrayU app will consume less resources than a blootted IMAP app and will thus not drag on other things that I am doing when checking for mail. When the IMAPTray app runs it can do more things with the IMAP accounts and will consume more of the CPU but since it will only be running a couple times a day it won't matter.

[Jessica Brown]

Fun idea, but from a development perspective, making two apps that do almost the same thing would require a lot of duplication of code under the hood, so it wouldn't work out as well for me the developer as it would for you the end user ;-)

For example, deciding which account to check when...both types of accounts need that. Reading all the settings from the ini file, processing the list of rules/whitelist/blacklist...duplicate again with maybe some very minor differences occasionally. Previewing a message, parsing HTML and email sections...again apply to both. And the list goes on and on.

Long term, I'm working toward being able to rewrite the mail-checking core to be properly multi-threaded so you can still operate on one account while other accounts are being background checked, but it's a monster big project. I think overall you'll notice a lot more performance benefits when I get that implemented than you would from having IMAP and POP in seperate applications ;-). And using the limit inbox size feature can also have a big impact on performance if you don't empty your inbox regularly too. If there's specific areas you think the app seems to be consuming more CPU/memory/resources/etc. than it ought, maybe there's areas I could focus on for performance tuning? Once I get a nice stable build again, I could also look into turning on some of the compiler optimizations too.

And not all new features are IMAP...Sure I've been adding the IMAP features I personally wanted to avoid having to log into gmail for secondary accounts to do basic functionality like "this is spam" ;-) Most of the new IMAP features will be lumped under a submenu like the spam button, so it won't greatly change the user interface for POP (not to mention since the toolbar is customizable anyway). But there's also other features coming on on my roadmap that apply to both types of accounts. While I was on vacation last month I came up with the design for account import/export. I've implmented export account(s) already, and I need to finish wiring up account(s) import so I can chase down some tab drag/drop problems.

[Ed P]

"making two apps that do almost the same thing would require a lot of duplication of code under the hood,"

Actually not really. The common source code could be kept as a separate module and each app would simply have an include statement for it when compiling.