GNOME Bugzilla – Bug 512623
Message list issues on trunk
Last modified: 2013-09-13 00:57:27 UTC
1. Shift Left/Right on message threads doesn't collapse/expand. Neither +/- 2. Lots of messages tend not to reflect the actual message status. For Example, if a message (expanded) is marked as read, the bold status remains. This happens for marking mails as Important also. The view/list doesn't reflect it. But when you right click, it shows the right status in the menu items. This doesn't happen on all mails all times. But at time. I have seen that when I read a mail it remains bold independent of click on the unread icon, Ctrk+k everything but on restart it works all fine.
Created attachment 103908 [details] [review] proposed evo patch for evolution; as srinidhi said on IRC, it added GDK_MODE2_MASK to key->state when Num Lock is on, but because you said it didn't help you to turn off it, then I added all GDK_MODEx_MASK-s, just in case. Can you check, please?
I think it is very close now. It should work only on Shift Left/Right. It now works with out that also. Also +/- should work. In my keyboard, it has [- _] [= +] - [WITHOUTSHIFT WITHSHIFT] It works on -/= but it should be -/+
i wonder if this will have impact on bug 272342
Right, it should fix it (is a duplicate of such old bug) ;)
Created attachment 103947 [details] [review] proposed evo patch ][ for evolution; another attempt. Works for me, but you can think it's wrong idea to do it in this way. Anyway, it works similar to folder tree.
Milan it works all fine. Just one small glitch. It currently accepts '_' and not '-'. Which means.. it works for 'SHIFT'AND'-' means '_' but it should be simplly '-'. It works fine for 'SHIFT' AND'=' means '+' Otherwise, looks great.
I changed it because my keyboard returns underscore, does yours return something else?
oh!. Milan, shouldn't we just listen to +/- and ignore any type modifiers? I'm lot confused here. I'm happy that it started working for me again.
So, it depends, if you are fine with that, then probably we can, but it will be either ('+' and '_') or ('=' and '-'), the first for the variant with Shift, the second for variant without Shift. Or both of them, it depends. But notice the '+' and '-' on numeric keyboard would work even without a modifier. I also think the returned values are correct for English keyboards respecting the shift button. So maybe this is not such a big workaround as I thought before. If you want to drop the modifiers check, then it will work regardless of that, so say Ctrl+Shift+'_' will does same as Shift+'_', which may be confusing.
Ah!, I'm confused. Lets commit Left/Right first. I would say that then just +/- and don't bother about anything else.
Committed to trunk. Committed revision 34944.
*** Bug 272342 has been marked as a duplicate of this bug. ***