---- Reported by chaz@yorba.org 2012-12-17 14:52:00 -0800 ----

Original Redmine bug id: 6138
Original URL: http://redmine.yorba.org/issues/6138
Searchable id: yorba-bug-6138
Original author: Charles Lindsay
Original description:

If you select multiple conversations in Geary and then either try to drag them
to a label or right click on them to get the context menu, it unselects all
but the conversation that you last clicked.

In other words, with multiple conversations selected, Geary shouldn't deselect
them all when you right click or click to drag. This would let you drag or use
the context menu to operate on any number of conversations in a folder.

Related issues:
related to geary - 7129: Inconsistent behavior in conversation list
context menu w... (Fixed)
duplicated by geary - 7396: context menu can't act on multiple
conversations (Duplicate)



---- Additional Comments From geary-maint@gnome.bugs 2013-08-29 16:09:00 -0700 ----

### History

####

#1

Updated by Jim Nelson 11 months ago

  * **Category** set to _client_
  * **Priority** changed from _Normal_ to _High_
  * **Target version** set to _0.3.0_

There is one way to make this work: If you Ctrl+Click multiple conversations,
then on the last Ctrl+Click you hold the button down, you can drag all the
conversations.

However, this isn't ideal, and we should try to make this more intuitive.

####

#2

Updated by Jim Nelson 9 months ago

  * **Subject** changed from _allow drag and drop of multiple conversations at once_ to _With multiple conversations selected, click+drag unselects_
  * **Priority** changed from _High_ to _Normal_

####

#3

Updated by Jim Nelson 9 months ago

  * **Target version** changed from _0.3.0_ to _0.4.0_

####

#4

Updated by Jim Nelson 8 months ago

  * **Target version** changed from _0.4.0_ to _0.5.0_

####

#5

Updated by Adam Dingle 3 months ago

This is pretty annoying, and I hope it might not be so hard to fix - any
chance we could attack for 0.4?

####

#6

Updated by Charles Lindsay 3 months ago

  * **Subject** changed from _With multiple conversations selected, click+drag unselects_ to _allow multiple selection clicking in the conversation list_
  * **Description** updated (diff)

####

#7

Updated by Jim Nelson 3 months ago

  * **Category** changed from _client_ to _ux_
  * **Target version** changed from _0.5.0_ to _0.4.0_

I believe what we're seeing here is the underlying behavior of GtkTreeView --
we're not doing anything special in the code to prevent this from working, and
I believe we're activating all the right settings to enable multiple
selections. My guess is we're going to have to work around GtkTreeView (once
again) to get this fixed.

Note that you if you select multiple with Shift+Click and continue to keep
Shift pressed when you right-click, the selection won't change and the context
menu will appear.

I'll move this to 0.4 and see if we can get something cooked up.

####

#8

Updated by Adam Dingle 3 months ago

Jim Nelson wrote:

> Note that you if you select multiple with Shift+Click and continue to keep
Shift pressed when you right-click, the selection won't change and the context
menu will appear.

Aha - I didn't realize that. That's a useful workaround for now.

####

#9

Updated by Avi Levy 3 months ago

  * **File** 6138v1.patch added

If I'm understanding the code correctly, we should return `true` after drawing
the popup menu (to indicate that we handled the event). By making this change,
it seems that right-clicking respects the selection now. However, this means
that right-clicking no longer selects conversations (so you should make your
selection, then right click). This could be fixed by adding a check for the
current number of selected conversations: if it's at most 1, then use the old
behavior (i.e. return false). If it's more than 1, use the new behavior
(return true). Let me know which behavior is desired.

To solve drag and drop, we would need to change over to using the button
release handler (instead of button press) because at the moment there is no
way to distinguish a click from a drag (without a time machine).

####

#10

Updated by Adam Dingle 3 months ago

  * **Priority** changed from _Normal_ to _High_

Thanks for the patch! I think that right clicking should continue to select
conversations, for consistency with other GNOME applications such as Nautilus,
where (for example) right clicking a file both selects the file and opens a
context menu.

####

#11

Updated by Jim Nelson 3 months ago

  * **Assignee** set to _Avi Levy_

We have a winner! Good catch.

I agree with Adam, we really want the right-click to go through and select the
item it's over. Can you investigate that? Thanks!

####

#12

Updated by Avi Levy 3 months ago

  * **File** 6138v2.patch added

Forget what I was saying about checking the number of selected conversations -
that's completely irrelevant.

As you both have pointed out, we still want right click to select
conversations. When either no modifier keys are pressed, or when shift is
pressed, any click selects a conversation.

However, when ctrl is pressed, any click toggles the current conversation.
This is desirable for left clicks, but not for right clicks. So we would like
right clicks to always perform a select, whereas left clicks either select or
toggle depending on the modifier keys.

The attached patch seems to implement the desired behavior.

####

#13

Updated by Jim Nelson 3 months ago

Avi, this isn't quite right either. There's one subtle missing behavior here.

When right-click is pressed, your patch will select the clicked on element,
even respecting the modifier keys: Shift for a ranged select, Ctrl for point-
by-point select, unmodified for single selection. That's good. But the one
exception case here is an unmodified right-click on an already-selected item.
With your patch, the right click deselects all other elements and selects the
element beneath the mouse cursor. For left-click, that's the desired behavior,
but for an unmodified right-click, it's slightly different:

  * Unmodified right-click on a selected element should simply show the menu -- no selection change at all
  * Unmodified right-click on an unselected element should deselect the others, select the element, and show the menu

See Nautilus' List View for an example of this behavior. As as I said, subtle,
but important.

####

#14

Updated by Avi Levy 3 months ago

  * **File** 6138v3.patch added

Looks like I can implement this behavior by **removing** code from the last
patch.

####

#15

Updated by Jim Nelson 3 months ago

  * **Status** changed from _Open_ to _Review_

It's a good feeling.

I made one small change to your patch in the interest of concision. Otherwise:
perfect-o.

####

#16

Updated by Avi Levy 3 months ago

  * **Status** changed from _Review_ to _Fixed_

Applied in changeset 59df8a4b47f7f6e99d45b1a3063ba09a6d2a7687.

####

#17

Updated by Avi Levy 3 months ago

  * **Status** changed from _Fixed_ to _Open_

Awesome! Definitely glad we looked into this for 0.4

####

#18

Updated by Avi Levy 3 months ago

  * **Status** changed from _Open_ to _Fixed_



--- Bug imported by chaz@yorba.org 2013-11-21 20:24 UTC  ---

This bug was previously known as _bug_ 6138 at http://redmine.yorba.org/show_bug.cgi?id=6138
Imported an attachment (id=260850)
Imported an attachment (id=260851)
Imported an attachment (id=260852)

Unknown milestone "unknown in product geary. 
   Setting to default milestone for this product, "---".
Setting qa contact to the default for this product.
   This bug either had no qa contact or an invalid one.