TreeView: multi select handling request


#1

Hey,
could we have an option to control the multi select feature of TreeViews, to choose if it should be based on commandModifier or not? Something like:

and change

[code]const bool cmd = modifiers.isCommandDown();

item->setSelected ((! cmd) || (! item->isSelected()), ! cmd);[/code]
of the TreeViewContentComponent in the TreeView.cpp to:

[code]const bool cmd = modifiers.isCommandDown();
if (! needsCommandModifier)
cmd = !cmd;

item->setSelected ((! cmd) || (! item->isSelected()), ! cmd);[/code]

This would give a bit more possibilities to customize the way the TreeView works. (In the preview of the code section of this post the “!” is shown as “|”. I hope you see the right characters, otherwise the code could be a bit confusing…)


#2

Hmm, I’ve never used a treeview that did a multi-select whenever you clicked on it - surely that’d be really annoying…?


#3

I’m using the TreeView for an xml based complex preset manager, where you can filter the shown presets, files, loops… by several categories and in this case it is much more intuitive to the user if more than one filter within a category could be selected just by selecting/unselecting the items without the command key. Of course this is a special case and for things like a file browser or something like that the way the TreeView works is perfect, but since the suggested change wouldn’t break any existing code and give some more flexibility to the TreeView, it might be a helpful feature for other, too. (I hope my explanation was not to confusing, I think in german I could say it much more precisely :oops: ).

P.S.: the latest Native Instruments preset managers work in a similar way, for exmple the FM8.


#4

Maybe my first suggestion could make problems if someone subclassed from TreeView, so it would be better to leave setMultiSelectEnabled(const bool canMultiSelect) as it is and just add a setMultiselectUsesCommandKey(const bool shouldUseCommandKey) function…


#5

I don’t like the idea of complicating the base class with that kind of thing - it’s just too ‘niche’ to warrant that. Maybe you could suggest a clean way I could virtualise something, so that you could create a subclass that behaves like this?


#6

I see your point, handling special cases in a base class should be avoided. Unfortunately I can’t think of a way to do it with a virtual because virtualising something in TreeView or TreeViewItem wouldn’t help. The TreeViewContentComponent::selectBasedOnModifiers (or alternatively TreeViewContentComponent::mouseUp and TreeViewContentComponent::mouseDown) need to be changed to get the desired behaviour. But since the TreeViewContentComponent is pretty strong connected to the TreeView class, virtualising and subclassing TreeViewContentComponent doesn’t help unless I would reimplement almost the whole TreeView and TreeViewItem.