Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[xen-uno]

I have figured out how to do a multi column sort in MC (B143) by using the sort modifier as shown here => sorting:[artist],[album],[filetype],[track #],[name]. I would like to use this in Media Library (and have) except that these rules and modifiers are SO FRAGILE in MC because they sit right on top and are easily destroyed (a weakness of MC's Smartlist's in general, IMO). Your first click into the search field highlights the whole string, and if you start typing...your rules/modifiers are blown away with no option to recover (if your in Media Library). This problem makes it a lot harder to find tracks fast via keywords (like typing in mazz to single out all the Mazzy Star tracks). I see this as an issue since there is no way to set default sorting via the Tree & View Settings like you can in MJ8.

Personally, I think that Smartlist rules/modifiers (aka criteria) should be setup like any of the following:

(A) Isolated...that is...criteria has it's own textbox below the searchbox.

(B) 1 level down (Out of the way and safe, searchbox is kept clean other than user entered search criteria) or hideable (displays criteria in searchbox when unhidden where it behaves exactly as it does now....while hidden, criteria is still fully functional but cannot be deleted, edited, or seen in the searchbox....Toggle would be Hide/Unhide option on wizard button menu).

(C) Lockable...by "locking" the criteria it still shows up in search box, but cannot be deleted, edited, or selected (appears as "greyed out"), yet still functions normally. Also when the searchbox is clicked on, the cursor moves to the end of the criteria string (if no user entered text exists) or highlights (selects) any and all user entered text. When unlocked, searchbox behaves as it does now. Toggle would be Lock/Unlock option on wizard button menu.

I prefer (C). Good protection yet you can still see the criteria easily.

10^-27

[xen-uno]

C'mon...

Does anyone else see this as a design flaw other than me? Is there an option I don't know about? JR, what do you think?

10^-27

[RemyJ]

I think there's a solution for the sort part anyway:  Now that you can do multi-column sorting using the column headers and it sticks to individual lists (smart or otherwise), don't bother with sorting using the rules anymore.  

[lee269]

You are not alone...

I certainly agree that the searching tools could use something of an interface revision to bring out their power to new users. Personally Id like to see the 'wizard' implemented as a standard Windows wizard, ie stepping through dialog boxes. The search bar would then be called 'the search bar' (or something), and for that you are right that there are some quirks in there that could be improved. Your option (C) seems like a good idea to me.

All for v9.1 of course.

[Matt]

Wide spread use of sort modifiers to specify your sorting isn't recommended.  If that's how you managed sorting in MC, using the program would be pretty wretched.

Ideally, now if you sort something, it'll remember how you did it and use it again. (sticky views)

If the sticky view system needs some improvements, start a thread and we'll hammer it out.

Thanks!

[xen-uno]

Roger that!

I'll try it. I still think JR ought to consider (C) for intermediate releases. It would make Smartlists more bulletproof and easier to use. Thanks.

10^-27

[RandyP]

Does anyone else see this as a design flaw other than me? Is there an option I don't know about? JR, what do you think?

I definitely agree. I personally find the difference between search criteria for View Schemes and Smartlists confusing - and a major violation of self-consistency within the program.

From what I read in this thread, if the Smartlists simply operated as the View Schemes do, we'd be 90% of the way there.

I really don't like having the program ask me if I want to save a Smartlist several minutes after I've modified it. It's so unexpected at times! I have to think back to what I did before I can reply.

If Smartlists worked like View Schemes, we could make temporary mods without disrupting the saved search critera. I'm surprised this isn't the way it works... I've read "consistency" a lot in the Interact forum, and this is a real inconsistency with no apparent raison d'etre. This is the time to fix it! We're in Beta, the time for users to work with the changes, validate them, and provide feedback.

re: sticky views... I'll go through them tomorrow and try to summarize my thoughts. They haven't worked the way I hoped and I find them problematic - even though I supported having them. If there's no thread, I'll start one.

Matt - is it time for icons?

[xen-uno]

> From what I read in this thread, if the Smartlists simply operated as the View Schemes do, we'd be 90% of the way there

yes

> I really don't like having the program ask me if I want to save a Smartlist several minutes after I've modified it

YES

> If Smartlists worked like View Schemes, we could make temporary mods without disrupting the saved search critera

YES!

I look at it this way. The criteria brings up the initial track set. User entered data is a way to narrow that set down further. Entering this data shouldn't affect the underlying criteria. As a programmer myself, I can't see the improvement on this front being any more than a minor code change. Randy...you nailed it.

R_x