After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 765458 - Ctrl+Shift+click, when selecting files in dirdiff, behaves just like Ctrl+click
Ctrl+Shift+click, when selecting files in dirdiff, behaves just like Ctrl+click
Status: RESOLVED OBSOLETE
Product: meld
Classification: Other
Component: dirdiff
3.14.x
Other Windows
: Normal enhancement
: ---
Assigned To: meld-maint
meld-maint
Depends on:
Blocks:
 
 
Reported: 2016-04-23 09:52 UTC by Tanguy P
Modified: 2017-12-13 19:17 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Tanguy P 2016-04-23 09:52:56 UTC
On the file explorers of Windows and Ubuntu alike, I'm used to the Ctrl+Shift+click shortcut for adding a range of files to the current selection.

I believe most people are familiar with that behaviour, but I will clarify anyway. Suppose I have these files:
A
B
C
D
E
F
G

If I click on file A, then hold Shift and click on file C, my selection is now [A,B,C].
If I then hold Ctrl and click on file E, my selection becomes [A,B,C,E].
If I then hold Ctrl+Shift and click on file G, I expect my selection to become [A,B,C,E,F,G].

This Ctrl+Shift behaviour is the one observed across many applications on different OSs, and I would have expected to find it in Meld too. Meld's dirdiff applies the standard behaviour for Ctrl+click and Shift+click, but Ctrl+Shift+click behaves just like Ctrl+click, i.e. in my above example the last selection is [A,B,C,E,G] instead of [A,B,C,E,F,G].

I get the same behaviour in Meld on both Windows and Ubuntu. I'm not filing this as a bug because maybe it was just never considered to add this shortcut to Meld?

Thanks for your insights,
Tanguy
Comment 1 Kai Willadsen 2016-04-24 21:47:23 UTC
Meld doesn't do anything special with tree selection handling. We're using the default GTK+ treeview and its selection handling, so best I know, any application doing things differently has customised the selection handling somehow.

I think adding support for the behaviour you describe would make sense. However, to be honest I'm unlikely to spend time on it any time soon. If someone else wants to pick this up, that would be cool.
Comment 2 GNOME Infrastructure Team 2017-12-13 19:17:46 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/meld/issues/107.