I guess that this is normal behavior for the built-in mail app?
If you check it to automatically check then it will continue to do so, even if the mail app is closed?
I never used the built-in email app like this before, just did manual checking.

Both the default mail app and Modest have a setting in "Settings..." that controls if mail is automatically updated and how often.

Report whatever you find (just, as always, be sure to search first). At worst, it'll serve as a marker for fixed bugs, and at best, you'll alert the dev to something that may otherwise have been overlooked.

I added two feature requests so far. But it would be nice to know the roadmap to figure out what is already planned or supposed to be done - in the first case there would be no need for a FR, in the second, it would be a bug rather than a FR.

That's supposed to be the point of tinymail (the library on which Modest is built): it's fully abstracted through an MVC pattern, so headers are only loaded when physically visible (perhaps with some wider view port to support scrolling).

If it's not doing that it's either a) a bug which needs reporting, b) a design decision to break the point of tinymail or c) I've got the wrong end of the stick. Any are possible ;-)

Observed bug(s):

Modest and the default Mail program seem to be arguing over the automatic download of mail setting; despite having set both OFF, one or both of them still does.

In addition, the default Mail application also loads and downloads mail headers, sets the LED flashing.

I've been experiencing "Too many applications open" dialogs popping up since installing Modest, plus lack of responsiveness of some desktop icons (notably the browser icon).

So I've removed modest for now; but if it would solve my issues to disable the default mail application, I'd be happier to do that and keep running modest. Is there a sane way to go about that?

/me waves his flags in the direction of http://bugs.maemo.org

Thanks General,

Great idea. I went to do this, but am a little unsure how to proceed. I didn't see a bug that describes the symptoms above but don't want to open a new bug unless it's necessary. Do you (or any reader) happen to know if a bug has been opened yet! If not, I'm happy to be the first, thanks!

Bugs is lovely if you already have an id or happen to be able to spend the time waiting for an account email from Maemo.org to make it through spam filters and greylisting, or aren't doing it from the IT itself (and thus able to do a more thorough job not to mention navigating bugzilla more easily).

Posting it here is better than forgetting about it altogether, I figure.

But point taken, I did create an bugzilla account. However at this point I've had to remove modest; if I can disable or fix the built in mail client to prevent it from running / colliding with modest, I'd be happy to reinstall and will report whatever I find.

I'll probably write up a wiki article on this subject at some point (assuming there isn't one available already), but for now:

Modest is a new addition to bugzilla, so there shouldn't be much on there right now. If a keyword search doesn't turn anything up, you can also check using a component search for Modest (Communication:Modest), as there aren't many bug submissions so far.*

If your bug hasn't already been submitted, then you can go ahead and create a new one. Component should be Communication:Modest, then go ahead and fill in all the other fields (IT OS for OS and your device for platform).

The summary and comment fields are probably the two most important fields. Use a lot of keywords when you write your summary (while being clear with the nature of the bug ), as this is what people search by default.

The comment field is where you write out a full description, expected and actual outcomes, and steps to reproduce (if relevant). bugzilla provides you with a template, which you need to fill in (and edit). Under the "STEPS TO REPRODUCE THE PROBLEM" heading, enter a step-by-step howto guide on how to reproduce the bug (this is very important, as it'll make the difference between your bug being fixed and developers being unable to reproduce the problem). Be very clear here.

The next two headings, "EXPECTED OUTCOME" and "ACTUAL OUTCOME" are where you describe how the software should work and how it actually works due to the bug (Expected: the automatic retrieval setting is off, so Modest will only retrieve mail manually. Actual: Modest retrieves mail regardless of automatic retrieval setting).

The "REPRODUCIBILITY" heading is used to indicate how often the bug occurs (usually "always" is the case). Please remember to delete the "(always/sometimes/once)" selections before you submit your bug. These are only recommendations and should not appear in submitted bugs (even Quim is guilty of this misstep, so I can't really blame people too much for it ).

The "EXTRA SOFTWARE INSTALLED" isn't always relevant, if you think that something you've installed has had a hand in the bug, then mention it, if not, delete the heading.

The "OTHER COMMENTS" is where you add additional comments, use this for whatever you think is relevant. If you don't use the field, delete it!

If you need further clarification on any of the features of bugzilla, please feel free to contact me!