Comment 1 Andre Klapper 2009-10-14 20:27:23 UTC

Confirming. Interesting bug. :-)

Internal ticket is closed as WONTFIX as
"That happens due to technical limitations. Is the same reason why you cannot
move forward/backward in the list of emails."

Hmm, I wonder what that 'technical reason' is. Seems a bit strange to me.
Anyway, it's a bit unfortunate, because we all know spam filters aren't perfect
:)

"Technical limitations" is IMO not a good reason to close this bug. It's
software, so technical limitations can be removed. Also I think this bug was
there on Diablo as well, so there was enough time to fix it.

The missing delete button is on my personal Top-10 list of annoying N900 bugs,
so it still gets my vote. Please consider reopening.

(In reply to comment #3)
> "Technical limitations" is IMO not a good reason to close this bug. It's
> software, so technical limitations can be removed. Also I think this bug was
> there on Diablo as well, so there was enough time to fix it.
> 
> The missing delete button is on my personal Top-10 list of annoying N900 bugs,
> so it still gets my vote. Please consider reopening.

Yeah, sorry for the lack of explanation. This is the technical issue. In
tinymail you can easily get a TnyMsg (which represents an email message) from a
TnyHeader (which corresponds to an email header that you can see listed after
clicking on an email folder). 

But when we receive a new email notification, we have the TnyMsg but not the
TnyHeader. There is no current way in tinymail to get the TnyHeader from the
TnyMsg. The problem is that to mark a message as deleted we need the TnyHeader.

Hope that it helps

(In reply to comment #4)
> Yeah, sorry for the lack of explanation. This is the technical issue. In
> tinymail you can easily get a TnyMsg (which represents an email message) from a
> TnyHeader (which corresponds to an email header that you can see listed after
> clicking on an email folder). 
> 
> But when we receive a new email notification, we have the TnyMsg but not the
> TnyHeader. There is no current way in tinymail to get the TnyHeader from the
> TnyMsg. The problem is that to mark a message as deleted we need the TnyHeader.

Thank you for your answer. I've noticed there is tny_msg_get_header function in
tinymail. Why does this not work? Does this have to do with the note about
tny_folder_transfer_msgs_async() in the tinymail API reference?
http://tinymail.org/API/libtinymail-1.0/libtinymail-tny-msg.html#tny-msg-get-header

Is there no way around this?

(In reply to comment #5)
> (In reply to comment #4)
> > Yeah, sorry for the lack of explanation. This is the technical issue. In
> > tinymail you can easily get a TnyMsg (which represents an email message) from a
> > TnyHeader (which corresponds to an email header that you can see listed after
> > clicking on an email folder). 
> > 
> > But when we receive a new email notification, we have the TnyMsg but not the
> > TnyHeader. There is no current way in tinymail to get the TnyHeader from the
> > TnyMsg. The problem is that to mark a message as deleted we need the TnyHeader.
> 
> Thank you for your answer. I've noticed there is tny_msg_get_header function in
> tinymail. Why does this not work? Does this have to do with the note about
> tny_folder_transfer_msgs_async() in the tinymail API reference?
> http://tinymail.org/API/libtinymail-1.0/libtinymail-tny-msg.html#tny-msg-get-header
> 
> Is there no way around this?

You cannot use tny_msg_get_header because the instance you'll get is a
TnyCamelMsgHeader. The instance you need is a TnyCamelHeader. You can only get
the later using tny_folder_get_headers().

Both TnyCamelHeader and TnyCamelMsgHeader are implementations of TnyHeader but
they're actually quite different objects. The former is an instance of the
folder summary information for one message while the later is just the
information about the headers of a TnyMsg. That is one of the problems of
Philip's initial design of Tinymail. We'll have to change them to avoid
missunderstandings in people that starts to hack in tinymail as it's a very
common doubt.

*** Bug 5754 has been marked as a duplicate of this bug. ***

Comment 8 Andre Klapper 2009-10-27 20:49:00 UTC

*** Bug 5854 has been marked as a duplicate of this bug. ***

In Diablo the mail was opened out of context in a singe window. There was some
kind of logic (far far away :D), that you couldn't delete/navigate. But now in
freemantle it only confusing. There isn't a close button anymore. If you click
in the right top corner, there is a arrow which brings you to your inbox. there
you can click on the same mail again and it opens the same view again, but now
with active delete/navigation buttons. I hope you see my point. 

I see the technical problem, but aren't you interested in good UI? I agree with
Cornelius. Why we not try to overcame the technical difficulties? Maybe we need
to fix it in tinymail, so you got your header :D

Comment 10 Andre Klapper 2009-11-23 20:58:39 UTC

*** Bug 6299 has been marked as a duplicate of this bug. ***

*** This bug has been confirmed by popular vote. ***

I also understand the limitations, but for the sake of ease of use, please
please try to find a way enable delete functionality for this.  It's most
annoying having to close the message and then wait for the mail application to
load.

This is a top annoyance for me, too. I'm voting this.

I'm voting for this too. Either: 1) escalate it to Tinymail; 2) fork Tinymail;
or 3) find another email library from which to build a client.

Comment 15 Andre Klapper 2009-12-04 18:29:49 UTC

(In reply to comment #14)
> I'm voting for this too. Either: 1) escalate it to Tinymail; 2) fork Tinymail;
> or 3) find another email library from which to build a client.

Well, we do "escalate" to tinymail (in fact the tinymail maintainer(s) is/are
around in Maemo anyway), forking does not make sense when manpower is missing
to keep up a fork, and finding another library and porting to it also misses
manpower. Hence it's WONTFIX, even if that may suck.

Comment 16 Attila Csipa 2009-12-04 18:53:26 UTC

Can't we at least think about a workaround ? Like for example making the delete
operation asynchronous - the delete button would 'schedule' the deletion
(record a SHA hash of the msg header/body or sorts in a queue) and then when
the mail client is retrieving the 'full' messages it conveniently skips (and
deletes in the background) the message ?

Guys Modest is the main consumer of tinymail, we're also developers (and
maintainers of tinymail) so no need to scalate anything.

I wouldn't close this as wontfix for the moment, as we're preparing a very nice
improvement using IMAP BODYSTRUCT, that will most likely allow us to fix bugs
like this (I agree is annoying BTW)

I only found this happen on Nokia Messaging account.
Is this bug presence for all other accounts?

Happens for me with GMail.

Comment 20 Neil MacLeod 2009-12-14 13:58:08 UTC

*** Bug 6949 has been marked as a duplicate of this bug. ***

(In reply to comment #18)
> I only found this happen on Nokia Messaging account.
> Is this bug presence for all other accounts?

I think so - it happens for me using my local IMAP server (dovecot) on a new
N900.

(In reply to comment #18)
> I only found this happen on Nokia Messaging account.
> Is this bug presence for all other accounts?
> 

I have 3 pop, 1 imap (google) and hotmail account(I think this one pop too). It
happens with all of them.

Have to agree this is a very annoying bug.  Should be a fix.

Finally managed to get this long awaited fix ready :-)

Fixed in
modest-3-2 (PR1.2): 72837e1033f6d83756b524fa691dc5ee6b740ebd
master (community): dd3db058530966c0d28def9c3bd1af04fc32ba6f

Comment 25 Andre Klapper 2010-01-12 15:25:39 UTC

Congrats! :)

I'm glad it's fixed. One of the most annoying bugs on the N900 for me.

Comment 27 Andre Klapper 2010-01-22 19:51:37 UTC

*** Bug 8137 has been marked as a duplicate of this bug. ***

This has happened a few times for me on 2.2009.51-1, but not as often as
before. I've got screenshots of this, but I guess you need more data to
reproduce this ...

Comment 29 Andre Klapper 2010-01-22 20:51:23 UTC

No need to reproduce at all. It's fixed internally already, see the previous
comments and the status of this bug report.

*** Bug 8626 has been marked as a duplicate of this bug. ***

Comment 31 Andre Klapper 2010-02-02 13:32:58 UTC

Fixed in package
modest 3.2.11-2+0m5
which is part of the internal build version
2010.05-4

*** Bug 9095 has been marked as a duplicate of this bug. ***

*** Bug 9220 has been marked as a duplicate of this bug. ***

Comment 34 Andre Klapper 2010-03-15 12:35:57 UTC

*** Bug 9547 has been marked as a duplicate of this bug. ***

Comment 35 Andre Klapper 2010-03-15 20:56:02 UTC

Setting explicit PR1.2 milestone (so it's clearer in which public release the
fix will be available to users).

Sorry for the bugmail noise (you can filter on this message).

*** Bug 9807 has been marked as a duplicate of this bug. ***

*** Bug 9804 has been marked as a duplicate of this bug. ***