Edit autoplaylist without actually envoking it [#5041]

[tomvincent@inbox.com]

I wish I could edit a autoplaylist without it actually starting to read tracks. I have a 150,000+ library and it can take many minutes before the list of tracks comes back when all I wanted to do was edit the list.

[Lowlander]

But the edit window comes right up, even if it takes a while to load the tracks.

I do agree that if you right click on a node it shouldn't activate it. Just like Windows Explorer (Windows Server 2003). Reducing unnecessary loading would always be welcome. This would also apply to any other node out there.

[nohitter151]

see http://www.ventismedia.com/mantis/view.php?id=5041

[Lowlander]

Great!

[ZvezdanD]

Date Submitted - 2008-12-14 23:10, Priority - urgent

[Dreadlau]

I hope the devs will fix this soon.

Today I used the "files to edit" --> unsynchronized tracks (which takes a while to calculate on a large library)
Then I right clicked on another node. And of course it has to change to the node I right clicked. Grrr
Frustrating!

[Dreadlau]

Hello

from http://www.ventismedia.com/mantis/view.php?id=6529

To summarize our options, we can:
1. Use the hack as implemented as of build 1315.
2. Implement non-focusing right-click on the main tree.
3. Leave it as it was in previous builds, i.e. right-click would always focus tree nodes.

I don't like 1. much, since it isn't consistent and as such it's probably inferior to any solution. 2. might be quite a good solution, but there are some reasons why not to use it:
a) Some users (if not many) are probably used to the current way it works and wouldn't like any change. We could add an option for this, but then it would be just one more option to maintain.
b) Technically it's not a completely trivial change, it's possible to implement, but there could be quite a number of regressions.
3. Is quite good, but 'Open in a New Tab' right-click menu item doesn't make much sense there, since it actually only doubles the newly focused tab.

Given all this, I'd prefer to use 3. and consider usage of 2., either for 4.0 final, in case there is a strong demand, but probably rather for some later version, when we decide how would this work on all platforms (i.e. Mac, etc.).

Pretty please go for solution 2.

a) Some users (if not many) are probably used to the current way it works and wouldn't like any change.

From what I read in the forum, people dislike the current behavior.

Also see:
http://www.ventismedia.com/mantis/view.php?id=5041
and:
http://www.ventismedia.com/mantis/view.php?id=5162

thank you.

[Dreadlau]

from http://www.ventismedia.com/mantis/view.php?id=6529

Re-opening for long term fix (item 2) since the hack is just a hack and we may not be able to retain it for MM4 because it's resulted in some relevant context commands being hidden.

Awesome

[Dreadlau]

Very bad news. Seems they won't make Mediamonkey have a standard behavior.
Pretty disappointing!

See: http://www.ventismedia.com/mantis/view.php?id=7367

We should revert this to MM 3.x behavior.

Already reverted in 1351

Why is it such a problem to fix this?