INTERACT FORUM

Please login or register.

Login with username, password and session length
Advanced search  
Pages: [1]   Go Down

Author Topic: File Selection Change  (Read 20030 times)

leezer3

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 1589
File Selection Change
« on: February 11, 2016, 08:35:40 am »

Is this just me, or is pane tagging broken?

Open a standard Audio\Artist\Album view with top-level panes.
I always used to be able to click on a Album in the top-level pane, and it'd allow me to apply a tag to all the files in the album.

It's now just saying no files selected....
Have tried enabling and disabling Pane Tagging from the edit menu, and no dice.

(Sorry, haven't tried any major tagging in a few weeks, otherwise I'd be able to give you a better idea of when it broke)

-Leezer-
Logged

blgentry

  • Regular Member
  • Citizen of the Universe
  • *****
  • Posts: 8014
File Selection Change
« Reply #1 on: February 11, 2016, 08:49:43 am »

^ File selection has been different for several releases now.  It doesn't automatically select everything that's in the view.  You need to go down to the files area and select the files you want.  For selecting a whole album, this isn't too bad.  You can use a key combination to make it faster:  <tab>  <control>a

Tab moves you from the Panes to the files.  <Control>A then selects all files.

Brian.
Logged

JustinChase

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 3276
  • Getting older every day
File Selection Change
« Reply #2 on: February 11, 2016, 10:05:13 am »



^ File selection has been different for several releases now.  It doesn't automatically select everything that's in the view.  You need to go down to the files area and select the files you want.

I still don't like this change. I wish it could be optional.
Logged
pretend this is something funny

leezer3

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 1589
File Selection Change
« Reply #3 on: February 11, 2016, 04:25:26 pm »


I still don't like this change. I wish it could be optional.

At the moment, I'm basically considering it a workflow breaking change :(

My main images setup has 4 top-level panes. (Year ==> Album ==> Date ==> Model)
Generally speaking, my workflow has been to tag from the album level.
Using Tab drops me to the next pane down, and refines the selection, which I didn't want.

It's not so bad with small albums, but when dealing with large albums and calculated fields in the view, things get messy.

Customise View...

Customising a view here, removing categories... (MC maximised)

Hit the remove button, get a 'busy' cursor for a few seconds, customise view dialogue losing its skinning for a second, and "not responding" appears in the window title bar. Then the view updates, but the 'customise view' window has fallen behind MC. To bring it back, need to alt+tab or bring another app in focus and return to MC.
I can't reproduce here.

Final note:
The Rotten Tomatoes link 'issue' is the sort of thing that will get you flack on the public boards, no matter what you do on the subject.
I don't know what the solution is, but in your shoes I'd be tempted to run a simple replace operation on the user links file, and bump the version.
Changes to the default links have been rare enough that I think this is unlikely to cause code bloat.

-Leezer-
Logged

glynor

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 19608
File Selection Change
« Reply #4 on: February 11, 2016, 04:33:27 pm »

I still don't like this change. I wish it could be optional.

At the moment, I'm basically considering it a workflow breaking change :(

It does slightly alter workflows, but it is MUCH safer. It was discussed here:
http://yabb.jriver.com/interact/index.php?topic=102144.0
Logged
"Some cultures are defined by their relationship to cheese."

Visit me on the Interweb Thingie: http://glynor.com/

leezer3

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 1589
File Selection Change
« Reply #5 on: February 11, 2016, 05:05:30 pm »

It does slightly alter workflows, but it is MUCH safer. It was discussed here:
http://yabb.jriver.com/interact/index.php?topic=102144.0

Makes me wonder if a compromise solution could be made.
Something like:
Album level or below allows tagging.
Another possibility is the existing popups (Editing tag info for x files)- Could these be expanded to cover this a little?

IMHO, though, this rather defeats the whole purpose of the panes......
Sooner or later, you need to stop holding user's hands, and frankly this is one of those times.
If this triggers *nasty* bugs, these should be fixed/ prevented, not removing a feature :)

I'm by no means disagreeing that this has the potential to cause some destructive behaviour, but at the same time, there must be a level of user responsibility.
Where the balance lies with this is a very tricky one to solve.

That brings up another bug I've discovered whilst playing with that though (Related):
Edit a Filename (Name) field to a space. This trashes the file- Looks like it's only been prevented for the Filename field, which just gives a tagging error and reverts :)

-Leezer-
Logged

glynor

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 19608
Re: File Selection Change
« Reply #6 on: February 11, 2016, 05:59:26 pm »

Makes me wonder if a compromise solution could be made.
Something like:
Album level or below allows tagging.

I thought of that back when we were first discussing it, but I couldn't think of a way to make it work, other than by setting an arbitrary file count limit.

Here's the problem:

You're thinking of MC as a "music organization" application, and furthermore, as a "popular music organization" application, where things are divided up into "Artists" and "Albums".

But a whole bunch of my Views don't even contain [Artist] or [Album] categories at all. Some do, but they're used more like "sub-categories" than anything else (Photo Albums, Home Movies, and other circumstances). But then, for Audiobooks, an "album" in my Library may contain hundreds of files (the entire book).

At which point in using this view (which, by the way, Filters in Both Directions) does it decide I can tag without selecting, and where is it "protected"?


Or this one?


Or this?


All three of those are among the Views where I spend the vast majority of my time doing new Tagging, with the Tag AW open. So I have to learn different rules for how things behave when one View is open versus another?

It seems... Troublesome. I get that it is inconvenient when you have a small, defined set of files on the screen, which you consider to be a "unit". But... How does MC know when you're looking at what you consider a "unit" versus when you are looking at a "larger set" of some similar but lots of dissimilar files?
Logged
"Some cultures are defined by their relationship to cheese."

Visit me on the Interweb Thingie: http://glynor.com/

leezer3

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 1589
Re: File Selection Change
« Reply #7 on: February 11, 2016, 06:33:54 pm »

Most of my views don't contain Album either ;)
(Or at least use it in the 'conventional' sense)

Album seemed a reasonably explained and logical first-step compromise for the general user though-
It's a homogenous set of files, which we *ought* to be able to reasonably assume have all the same location, and similar metadata.
It's different on the other hand to for example Artist, which might contain a disparate set of on-disk files and metadata.

Even in first two your sample images, I'd still make exactly the same argument for this change:
Tag on album only :)
I'll admit this isn't perfect, but it would help a lot of the potential use-cases- On the flip side, it'd probably cause horrible confusion from people asking why tagging isn't working from a higher-level pane.....

Your other examples:
An audiobook (Got '00s of those)-
The metadata for the book doesn't change at file 50/100. The only fields that I'd expect to change are Track #, Disk # and potentially description. (I have some tagged with chapter descriptions)
Photo Albums/ Home Movies-
A lot more problematic, I'll give you. Most of my photo albums use the Album field, but that's mostly because it's easier to setup auto-fill rules this way.
I'd be tempted to filter on date for these, but it's adding complexity......


Another, rather simplistic solution:
Perhaps what this needs is a re-purposing of the Pane Tagging box checkbox, or perhaps a different additional mode?
Options proliferation is never usually a good thing, but there are two camps on this one, both with strong arguments :)

I'll stress that in my eyes, this functionality feels too valuable to loose.
People have lost data, but sooner or later there comes a point whereby protecting users from themselves breaks things for others. IMHO, this is one of those times-
I've consciously made a selection, and it feels really limiting for MC to decide that actually I didn't want to do that at all.....

Whilst on that subject, another of my pet gripes is the confirmation prompt when tagging large numbers of files  :D
Again, I very much get the fact that this is a useful too for many users, but it can sometimes feel incredibly painful that I have no option to not show this warning again (Even if just for the session in question)

It's little features like this (And for that matter the flashing panes.....), which make me sometimes feel that MC isn't quite sure where it wants to be.
It's brilliant catering for non-power users, and providing features to help them, but at the same time, many of these 'helpful' features are pushing away the power users, and making our lives more difficult.

A balancing act I wouldn't care to play myself  ;D

-Leezer-
Logged

glynor

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 19608
Re: File Selection Change
« Reply #8 on: February 11, 2016, 06:55:10 pm »

I'll stress that in my eyes, this functionality feels too valuable to loose.

This is where I don't agree. We didn't lose anything.

Something, which could be destructive, was made slightly less convenient. And far less so than other possible solutions, like showing a "Are You Sure?" prompt each time (ala Empty Recycle Bin).

I'll ask this... Can you, since it bothers you, describe workflow click by click?

What specific part of it is made more difficult? (Other than muscle memory, which I admit, is tough to break, but that's sometimes the price of change.) Perhaps there is some other way to crack the egg... Would a Select All Files in the Current View button in the Tag AW somewhere (to avoid the mouse click needed to select one file before selecting all) ease the pain? What about a Shift-Control-A keyboard shortcut variant that does the same? Or is it some other part of the "flow" that is tripping you up?

For me it is hard to consider, because I very rarely actually tag things as "groups" in the Tag Action Window with "All Files" selected. I'm almost always using the Panes to apply those kinds of "group taggings". Or, I apply them right inline in the Details File Listing. The main reason I do use the Tag AW on a group of files (with "All" selected) is to apply things like [Notes] to live concert recordings, or applying some expression (like Counter() in [Episode] or something).

But, when I do this, I'm usually applying them at the very end of a chain of other activities, essentially after everything else is tagged correctly, and I've already done Control-A (long ago) to select all of them in order to use Pane Tagging.
Logged
"Some cultures are defined by their relationship to cheese."

Visit me on the Interweb Thingie: http://glynor.com/

blgentry

  • Regular Member
  • Citizen of the Universe
  • *****
  • Posts: 8014
Re: File Selection Change
« Reply #9 on: February 11, 2016, 07:08:14 pm »

If enough people feel like Leezer and Justin, then a switch is the obvious solution.  It could be:

Tools > Options > General > Behavior > Panes Selections Select All Matching Files

Or:

Edit > Panes Selections Select All Matching Files

Or choose another location.   Alternate wording:  Clicking In Panes Selects All Matching Files .

Then of course I wonder if someone else does this in Categories views, or other places that are NOT Panes.

Brian.
Logged

glynor

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 19608
Re: File Selection Change
« Reply #10 on: February 11, 2016, 07:12:47 pm »

I think if they're selected it should, at least, show them as selected in the file listing.

An Option is always an option, but it often isn't the right solution.
Logged
"Some cultures are defined by their relationship to cheese."

Visit me on the Interweb Thingie: http://glynor.com/

leezer3

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 1589
Re: File Selection Change
« Reply #11 on: February 11, 2016, 07:16:51 pm »

This is where I don't agree. We didn't lose anything.

Something, which could be destructive, was made slightly less convenient. And far less so than other possible solutions, like showing a "Are You Sure?" prompt each time (ala Empty Recycle Bin).

I'll ask this... Can you, since it bothers you, describe workflow click by click?

What specific part of it is made more difficult? (Other than muscle memory, which I admit, is tough to break, but that's sometimes the price of change.) Perhaps there is some other way to crack the egg... Would a Select All Files in the Current View button in the Tag AW to select all files in the current view (to avoid the mouse click needed to select one file before selecting all) ease the pain? What about a Shift-Control-A keyboard shortcut variant that does the same? Or is it some other part of the "flow" that is tripping you up?

It depends :)
I can fill approximately 1/2 of my desired metadata using auto-import rules.
This leaves approximately 10 fields for each album to be filled.
If I have time, these get filled from at import.
If not, I've got a calculated view, which shows all files lacking the tags in a reasonably standard panes view. At any time, this might have anything upto 40-50 albums in it.

My basic workflow then looks like this:
1. Check the first pane for non-tagged, or misspelt genre tags. Click on any of these I find, and edit the whole genre field as appropriate. (I use Genre as the base category- Audiobook, TV Show etc.)
2. Check the 'Unassigned' list for anything that the auto-rules have missed. In general, click on each Album, and assign a genre.
3. Select a genre (Audiobook) and check for misspelt/ non-standard artist names. Click on any and edit as appropriate.
4. Select an artist, and then album. Tag all files in album with missing fields.

In essence, I'm being forced into using Select All 3-4 times each time I drop down a level, when before I could just tab or click between panes....
When this is multiplied by several artists or genres, it gets nuts.

A similar thing happens when I'm consolidating or changing tags.

My whole tagging workflow revolves almost entirely making a selection in the top-level pane, and editing at the level I've selected. This is *usually* Album or an equivilant, but not always.
It's relatively rare that I actually want to edit the tags for a single file.

Most of the time, I don't actually use the file list below the panes at all, other than for basic confirmation that everything is where it should be.
Any playback is done through a set of smartlists (Music, Images), mobile devices (Audiobooks, Music) or the TV (Films, TV, etc.)

-Leezer-
Logged

blgentry

  • Regular Member
  • Citizen of the Universe
  • *****
  • Posts: 8014
Re: File Selection Change
« Reply #12 on: February 11, 2016, 07:17:33 pm »

I think if they're selected it should, at least, show them as selected in the file listing.

Agreed.  The previous behavior of "invisibly select all" seemed like a bug to me.  At the very least it was incredibly unclear.

Quote
An Option is always an option, but it often isn't the right solution.

MC already has more options than many applications.  I sometimes think it has too many.  But as I learn what they all do, they make more and more sense.  Part of the appeal of MC is it's nearly unlimited flexibility.  So I see both sides.  On one hand, I hate having 300 check boxes in Options (exaggerating).  On the other hand, if *enough* people want this, it's probably worth doing.  But I'd agree with the above.  If it becomes an option, have it show what it is doing by highlighting all files that are auto-selected.

Brian.
Logged

leezer3

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 1589
Re: File Selection Change
« Reply #13 on: February 11, 2016, 07:33:56 pm »

I'm also in agreement with highlighting the files if this returns :)
That seems eminently reasonable.

I do wonder if those who have 'suffered' at the hands of this feature have a little negative bias towards it?
I completely understand that there is danger here, but as I noted a couple of posts up, things like the filename problem should be considered bugs in their own right, rather than children of this behaviour :)
Sure, there have been the odd tales of woe, but on the whole, if this had been as bad and as dangerous as it's being made out, surely a bigger fuss would have been kicked up over the last 10 years?
(Please don't take this personally, it's really not meant that way!)

I think it's also telling that we've had threads from regular users on this front-
It's something that's been there since at least MC12, and some of us are missing it :P

-Leezer-

Logged

glynor

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 19608
Re: File Selection Change
« Reply #14 on: February 11, 2016, 08:09:30 pm »

It isn't just Filenames though. That was particularly destructive because it trashed files. But erasing all of my [Track #] or [Season] tags, or worse some that aren't captured in the Filenames, would be basically just as terrible for me.

The main reason I said adding an option isn't always the best solution is more than just Option Creep (though that's a huge issue too). It's also a problem because then you "split" your user base, and divide your development resources a bit at a time. It ties your hands, and often points that the "best way" lies somewhere else.

This is, though, not always the case. Sometimes users have fundamentally conflicting needs. It's hard to decide when it is best to do, and not. I don't know where this falls.
Logged
"Some cultures are defined by their relationship to cheese."

Visit me on the Interweb Thingie: http://glynor.com/

leezer3

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 1589
Re: File Selection Change
« Reply #15 on: February 12, 2016, 07:19:59 am »

It isn't just Filenames though. That was particularly destructive because it trashed files. But erasing all of my [Track #] or [Season] tags, or worse some that aren't captured in the Filenames, would be basically just as terrible for me.

The main reason I said adding an option isn't always the best solution is more than just Option Creep (though that's a huge issue too). It's also a problem because then you "split" your user base, and divide your development resources a bit at a time. It ties your hands, and often points that the "best way" lies somewhere else.

This is, though, not always the case. Sometimes users have fundamentally conflicting needs. It's hard to decide when it is best to do, and not. I don't know where this falls.

Track # is another field I'd actually argue to protect in any multiple-selection scenario.
The only thing I can think of that could be argued for is clearing it altogether- Can anyone else think of any time you'd want to edit the Track # for multiple files to the same value?

Season is problematic, I can absolutely see this being edited in multiple-selection mode.

All I can really do is make my points the best way I can :P
Ultimately, I'm not the one doing the development.

-Leezer-
Logged

blgentry

  • Regular Member
  • Citizen of the Universe
  • *****
  • Posts: 8014
Re: File Selection Change
« Reply #16 on: February 12, 2016, 08:48:52 am »

I don't think any pure metadata field should be "protected" in multiple selection mode.  Undo will fix any mistakes that are made, as long as you catch them right away.  A database restore will fix any problems you find later, though you'll lose your work.  That's the price of enabling the big boy option to highlight all Panes Selections.  Which is why it should be off by default.

Now fields that impact the file system are different.  Frankly, editing fields in MC that affect the file system shouldn't be allowed at all in my opinion.  Why would anyone do this intentionally?  As Glynor says, it's not the old days of struggling with pointy sticks and fire and not knowing what the wheel is!  :)  We have the Rename, Move, and Copy tool for file system operations.  Editing the file system, via tags is an outdated dangerous idea.

Brian.
Logged

glynor

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 19608
Re: File Selection Change
« Reply #17 on: February 12, 2016, 11:29:40 am »

I don't think any pure metadata field should be "protected" in multiple selection mode.  Undo will fix any mistakes that are made, as long as you catch them right away.  A database restore will fix any problems you find later, though you'll lose your work.  That's the price of enabling the big boy option to highlight all Panes Selections.  Which is why it should be off by default.

Assuming an option is added, +1 to all of this.

Here's an example of why:

Can anyone else think of any time you'd want to edit the Track # for multiple files to the same value?

Absolutely. Basically every time I edit [Track #] or [Episode] manually I select a set of files and enter: =Counter().  While it outputs a different value for each file, the input system doesn't "know" this, and as far as it is concerned, would be "all the same value".

I've also been known to select-all and reset to 0 in certain circumstances (if the data there is junk), or copy from another field.

Now fields that impact the file system are different.  Frankly, editing fields in MC that affect the file system shouldn't be allowed at all in my opinion.  Why would anyone do this intentionally?  As Glynor says, it's not the old days of struggling with pointy sticks and fire and not knowing what the wheel is!  :)  We have the Rename, Move, and Copy tool for file system operations.  Editing the file system, via tags is an outdated dangerous idea.

A slightly less enthusiastic +1 on this. First off, we'd absolutely need to retain the ability to directly edit [Filename] via MC's various APIs (COM, MCWS, etc).

Also, there is one thing you can currently do with [Filename] inline (in Tag AW or inline in File Details View) that can be problematic (or at least non-intuitive) to do in RMCF: replace the existing values directly, with an expression.

You can do Find & Replace, which usually covers it, but if you want to do some kind of "advanced" manipulation of values (perhaps with a RegEx() or something) and you need to be able to just plain replace what is there with the output of an expression, this would be clunky in RMCF as it is currently.

To do that without a new "Replace Existing Path" Template, I think you could use:
* Directories Template: with no Rule but a base path
* Filename Template: with your expression in the Rule

But, that isn't super-obvious and I'm not sure how you'd do it at all if you want the expression to even include the base path.

A new Replace Existing Path with a single rule box, which does the same as editing them directly, could fix this. Of course, that would be an even more dangerous RMCF template than the others (which, despite being powerful, do "hold your hand" a bit).

I'm not sure how important this one exception is, though. Frankly, if I ever needed it, making a little COM utility to directly replace [Filename] would be no biggie, so... Meh?
Logged
"Some cultures are defined by their relationship to cheese."

Visit me on the Interweb Thingie: http://glynor.com/

marko

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 9168
Re: File Selection Change
« Reply #18 on: February 12, 2016, 11:40:37 am »

I'm already on record as struggling with this. For me, the solution should have been to prevent MC from trashing files, not put speed bumps in the way of the user.

A quick example...

Error checking tags:
Before, it was simply a case of selecting an album in the album pane, and then simply press the down arrow moving through the album pane, watching the tag window to make sure no "[varies]" cropped up.

You just wouldn't even try that now. ctrl+a is not going to work because focus is in the album pane, and tabbing around inside MC is so hit and miss I just don't go there.

I still struggle to get my head around whatever it was that was destructive. I tried clearing the filename field on some test files, and nothing happened. In 13 years of using MC, I never bumped into an issue with how things used to be. If, after all that time, someone found an issue, then, imo :), that issue should have been addressed rather than take away something unique to MC's outside-the-box way of doing some things.

I also love being able to have editable access to the filename fields via the tag window. I don't think it's dangerous or outdated. I think it's super convenient, especially so as you can drop an expression in there and quickly deal with any errant filing mistakes as soon as you see them. Maybe it's just me that's outdated and dangerous :D

-marko.

glynor

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 19608
Re: File Selection Change
« Reply #19 on: February 12, 2016, 11:07:22 pm »

I still struggle to get my head around whatever it was that was destructive. I tried clearing the filename field on some test files, and nothing happened.

Clearing, I believe never caused it. Whitespace, or any "invalid path", was the problem. They've since added some kind of protection for this to the [Filename] field, but as Brian pointed out earlier, this doesn't apply to [Filename (name)]. You can test it now if you want. Select a file you don't care about (or have a backup for), open [Filename (name)] in Tag AW and edit it. Type a space and Enter.

In 13 years of using MC, I never bumped into an issue with how things used to be. If, after all that time, someone found an issue, then, imo :), that issue should have been addressed rather than take away something unique to MC's outside-the-box way of doing some things.

As I said above, my issues weren't even with just this particularly grievous example. But I've made other dumb mistakes because of this over the years. Many of them, deleting huge swaths of metadata accidentally. Or, somewhat worse, changing things. Its all fine if you notice that you've done it when you do it. That's, as was said, fine and you can usually back out of it somewhat unscathed.

But I've had it happen a time or two, not to [Filename], when I didn't even notice it happening. I remember one specific instance where I somehow changed the [Episode] tag on a huge swath of my TV Episodes to the output of a Counter(). If I remember correctly, there were a bunch of Movies and Home Videos that got whacked too, because that's how I eventually noticed it. The thing was, I didn't notice it for a few weeks. It didn't apply to any of the Series I happened to be actively watching at the time. It did apply to a huge swath of "new" files, but it didn't apply to any of the "newest" stuff that was recorded after the "incident" (it wasn't "ongoing"), so I also didn't notice it in my "new media" Views. Those files had scrolled down past my "notice" from some big import that happened in the interim.

I was able to restore a good portion of them with the metadata from the filesystem. But the rest, which was hundreds of files, were recordings dumped in my M:\Recordings folder, which hadn't yet had a RMCF preset applied to them, and there was no simple way to get the [Episode] tag back on those. I eventually resorted to pulling up TVDB in a web browser and MC on the other monitor, looking for Episode Titles in the Season listings, Series-by-Series, and dragging episodes around in a Playlist to get them in the right order, and then applying =Counter() to them to get them back in shape. I could have restored a Library Backup (and considered it) but naturally, I'd done a bunch of view and smartlist work in the interim, and some big imports that (mentioned above) that required their own big tagging job.

Looking back afterwards, I think I know what happened. I do clearly remember posting on Interact, around the timeframe when the issue seemed to have occurred, about using the Counter() function to tag things. So, I suspect what happened was some version of:

* I had MC open in the background and was posting on Interact trying to help someone. MC was "largely forgotten" and I was just using it to refer back and forth and provide concrete examples in my post. It was, almost certainly, sitting open on my New Video import management view (based on what happened).
* I was pasting some expression copied from the Wiki, I believe, or another post maybe, into a post.
* Somehow (an errant mouse-click, some kind of crazy fumbled keyboard shortcut, or just clumsy) I got MC pulled into the foreground when I didn't think it was, and the [Episode] field highlighted in the Tag AW. I know I had the Tag AW open because I'd previously been referring to it and copy-pasting out of it into my post. But I didn't really see it was in the foreground. It was over on the side in another monitor. Anyway...
* Paste. Nothing. Huh. That's weird, it didn't paste. I thought I had it on my clipboard. Click on Firefox to copy it again from the other tab. Paste. Ahh, there it goes. All good. Save.

And MC was happily writing tag changes to 1200 files in the background over there on the side.  :(

Maybe not. Maybe it was some other crazy mistake. But, the point remains that it would have been far less likely to happen to a huge set of files if MC didn't behave in this odd and unexpected way.

I only post this as an illustration that focusing on the one [Filename] example misses the point. Destroying data is really, really bad. Particularly when it can do so in a way that is:
* Counter to the way basically all other applications behave.
* Counter to the way MC itself behaves in other situations.
* Swift and silent.
* Sometimes, difficult to reverse (especially as a side effect of being swift and silent).

I feel fairly strongly that at the very least, it must show the files as selected when they're selected. But, pretty obviously they thought of that when it was first designed. It was a tradeoff to do it the way it worked all along, because it would look terrible to highlight the whole file listing every single time you refilter a View with the panes! That's why they don't show as selected, because it'd look all highlighted blue all the time! So it "implicitly" selects them all, until you select a file explicitly.

I get it. Totally get why it is handy. I've used it a ton over the years, and understood how it worked. Still, despite understanding it, filtering a view (in my brain) is logically distinct from the action of selecting files (and most of the time, I did the Control-A out of habit anyway). But, to me that relatively minor productivity gain is not worth one single occurrence of anything like the above, no matter what field it happens to trash. And, while I only encountered impacts as severe as the one described above a time or two (that one and the time I did delete files and trash a whole bunch of content are the ones that stand out in my memory), based on "weird and unexplained" tagging issues I've seen over the years, I bet it has happened to me 7 or 10 times in one way or another over the past decade. That's me. What about people who don't live on Interact and have no idea what just happened?

If they want to add a non-default option, especially in light of how long-standing the behavior has been, I'm absolutely not voting against that. But, since we're discussing it, I wondered if there was some kind of undiscovered third way. That's all. I don't have any brilliant ideas right now, though, if the Shift-Control-A idea isn't doing it for you.  :-\ ?
Logged
"Some cultures are defined by their relationship to cheese."

Visit me on the Interweb Thingie: http://glynor.com/

glynor

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 19608
Re: File Selection Change
« Reply #20 on: February 13, 2016, 12:49:55 am »

It doesn't, I should add, require a "and then something crazy happens and the Tag AW accidentally gets highlighted" (aka glynor had too much wine) to happen.

I'm pretty sure most of the times when I've been "bitten" have been when I was using Split Views (especially on my laptop, where I often use Split Views, and have a less precise input device). If you are intending to edit tags, so working in the Tag AW intentionally, but you have split views open, and you aren't very careful which "side" of MC is active every single time you type anything in there?

You can easily trash a field's contents on not just one file, but hundreds or tens-of-thousands. That is particularly troublesome because the files you intended to have selected, but in the non-active split, look visually still like they're selected.

Since figuring out the cause (until the "fix") it made me very gunshy about doing any tag edits at all with split views open. But, I like to use Split Views, sometimes while I'm tagging. So... Meh. That stinks.
Logged
"Some cultures are defined by their relationship to cheese."

Visit me on the Interweb Thingie: http://glynor.com/

marko

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 9168
Re: File Selection Change
« Reply #21 on: February 13, 2016, 01:54:51 am »

I tried that, on the [filename] and the [filename (name)] fields... I got the following two messages...




But the file itself was fine. It remained on the drive, and was not renamed. Clicking away from it in MC, and reselecting it, restored the correct info in the tag window.
I remember years ago, messing around with expressions that resulted in an invalid filename (no drive letter, colon, double backslash) and MC took all those files and dumped them in the Windows\System32 folder, which made me chuckle. I think Matt fixed that.

As far as split views go, I'm with you. I stopped using them extensively because of the fact that focus has a nasty way of shifting between views arbitrarily, and back then when I was messing with them, the view didn't even need to be in view.

I'll open a second view if my current workflow benefits from it, but turn split views off as soon as I'm done. That ought to be fixed, really.

How selected files look similar whether focussed or not is why I started making my own skins. I set about it after accidentally deleting over 10,000 image files using shift+delete --> enter (thank the lord for a religious backup regime)!

This change, it's not a deal breaker, but it really takes away from the fluidity MC used to have. There are many areas where I might need protecting from myself, but I don't think this is one of them and I still find it frustrating. I would do a happy dance if this was put back the way it used to be, but, although I'm clearly not the only one who feels this way, it hasn't exactly set the forum on fire has it.

It was good of leezer3 to give me the opportunity to have another grumble about it in the privacy of this forum. If it gathers any momentum out there though, I'll pile right on in on it :) ;)

leezer3

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 1589
Re: File Selection Change
« Reply #22 on: February 13, 2016, 06:15:41 am »

Glynor-
From a first glance, your stated use of Counter() could *potentially* be replaced with the Fill Track Numbers from List Order tool?
That of course falls over if you're using the increment or start value arguments  :(

Like the other suggestions though, this is a kludge, and it makes certain assumptions about what you're trying to do...

I don't disagree with the logic of your points at all, but my impression remains that you're projecting your own data loss onto the feature as a whole.
I think Marko's point that he's managed to delete 10,000 image files by a message with a specific 'are you sure' prompt is proof that no matter how many safeguards you put into place, someone will sooner or later mangle their library, and unfortunately, this is just the way that's bitten you the hardest.

Sooner or later, you have to trust the user with the loaded gun, even if it is hidden behind an option.
This is one of those times :)

Final note-
Will be very strongly considering rolling back MC on the main machine if this is not changed.
Could Jim or Matt comment at all from a developer's POV?

-Leezer-
Logged

glynor

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 19608
Re: File Selection Change
« Reply #23 on: February 13, 2016, 08:42:49 am »

I hadn't re-tested the nuking of files with whitespace, but it was definitely happening before. They did do something to fix it for [Filename], as I said above. It does look like Brian was wrong about [Filename (name)], though as I can't reproduce it now. MC is now replacing whitespace with underscores, and now refuses to modify the filename as described above if the resulting path is invalid. I wonder if Brian is seeing a Mac vs Windows difference?

In any case, like I said, I get it too. I'm not opposed to an option.

I will also say that the way they disabled it, I don't like. My suggestion was to make the Tag AW read-only until a file was selected, so it could still be used as an informational display. Perhaps that wasn't easily architecturally possible?
Logged
"Some cultures are defined by their relationship to cheese."

Visit me on the Interweb Thingie: http://glynor.com/

glynor

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 19608
Re: File Selection Change
« Reply #24 on: February 13, 2016, 08:52:58 am »

From a first glance, your stated use of Counter() could *potentially* be replaced with the Fill Track Numbers from List Order tool?

No, because I don't want the counter in [Track #]. I use Counter() all the time! I don't want to go back to the bad old days, before the Liberace Rubber Chicken build, where I had to fill [Track #] and then Move/Copy the field over to where I really wanted it.

Anyway, that was also just an example, from years ago.
Logged
"Some cultures are defined by their relationship to cheese."

Visit me on the Interweb Thingie: http://glynor.com/

blgentry

  • Regular Member
  • Citizen of the Universe
  • *****
  • Posts: 8014
Re: File Selection Change
« Reply #25 on: February 13, 2016, 08:58:54 am »

It does look like Brian was wrong about [Filename (name)], though as I can't reproduce it now. MC is now replacing whitespace with underscores, and now refuses to modify the filename as described above if the resulting path is invalid. I wonder if Brian is seeing a Mac vs Windows difference?

I was not the one that made that observation.  It might have been Justin?  Not sure.  I've never experienced this particular behavior.

Brian.
Logged

glynor

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 19608
Re: File Selection Change
« Reply #26 on: February 13, 2016, 09:00:57 am »

he's managed to delete 10,000 image files by a message with a specific 'are you sure' prompt

If it previously had an "Are You Sure" prompt (just like enabling Pane Tagging does in the Panes), then we wouldn't be having this conversation because I'd have never brought it up.  Sure, with a warning prompt, people can still make dumb mistakes. But at least it warns them.

The Pane Tagging warning prompt has saved me literally hundreds of times. I absolutely would not check the "do not prompt" box on that if it had one. Speaking of which, I'd be perfectly happy with this solution:

It goes back to the way it was. But, when no file is selected and you edit a tag in the AW, it prompts with a dialog confirming that you want to edit all files (with an associated "go away and don't come back" checkbox). That would also match the behavior of the Panes, and would give me that one extra sanity check (requiring a second Enter).
Logged
"Some cultures are defined by their relationship to cheese."

Visit me on the Interweb Thingie: http://glynor.com/

glynor

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 19608
Re: File Selection Change
« Reply #27 on: February 13, 2016, 09:01:28 am »

I was not the one that made that observation.  It might have been Justin?  Not sure.  I've never experienced this particular behavior.

Oops. Sorry. I was too lazy to scroll up and look. But I know someone up there or in one of the other threads said that.  ;D
Logged
"Some cultures are defined by their relationship to cheese."

Visit me on the Interweb Thingie: http://glynor.com/

JustinChase

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 3276
  • Getting older every day
Re: File Selection Change
« Reply #28 on: February 13, 2016, 12:36:33 pm »

I also don't know the solution here. I fully understand why the change was made, and can't necessarily fault it, but as has been pointed out, it's been the way it was for well over a decade, and it was one user on the main board asking about his problem that brought this to Matts attention, and resulted in a change.  dozens of power users had been (mostly) fine with the behavior for a dozen years or more, so it's not as terrible as it might seem.

With that said, like Glynor mentioned, it's bitten me in the past also, so the 'danger' is real.

I really, really prefer the old behavior, since moving to select the correct part of the window, then ctl-a every time I want to update a group of files is hugely annoying.

Perhaps some kind of per session permission to allow the old behavior for a 'tagging session' but a default, and perhaps return to the current situation is a decent compromise.  Perhaps a warning if more than a dozen or 20 or 100 files will be changed at once?

**While I'm on the subject of many files changing at once; I really, REALLY, REALLY want a way to see what tags are being changed, and the ability to stop it.  I've too often seen xxxx tags updating along the bottom of the window, but don't know what tags or files are being changed, and when I have made mistakes in the past, and triggered this, the ONLY way to stop the bulk change is to hard-kill MC in task manager.  I suggest we should have more control of the current tagging process.  (feel free to move to a new thread if discussion of this is warranted.  i only mentioned it here since it's very related)
Logged
pretend this is something funny

Afrosheen

  • Regular Member
  • Galactic Citizen
  • ****
  • Posts: 313
Re: File Selection Change
« Reply #29 on: February 24, 2016, 11:34:47 am »

Count me onboard for reverting this change back. It's become increasingly frustrating to use.
Logged

Otello

  • World Citizen
  • ***
  • Posts: 204
Re: File Selection Change
« Reply #30 on: March 14, 2016, 12:22:58 pm »

Guys, can you please address me to the last stable version before the file selection change?
The new behavior is really frustrating.

Thanks...
Logged

phalanthus

  • Galactic Citizen
  • ****
  • Posts: 461
Re: File Selection Change
« Reply #31 on: March 15, 2016, 02:11:03 am »

20.0.132 is fine

"The new behavior is really frustrating"

i have dumped the latest version i paid money for - maybe a future version will fix this
Logged

Matt

  • Administrator
  • Citizen of the Universe
  • *****
  • Posts: 42449
  • Shoes gone again!
Re: File Selection Change
« Reply #32 on: March 15, 2016, 09:10:20 am »

Coming next build:
Changed: The logic that takes the selected files for the Action Window will allow none to be selected if the entire set of files is one album (otherwise it'll still say no files selected).

It's a little complicated to explain, but basically if a single album is selected the files will show in the Tag window instead of saying no files selected.
Logged
Matt Ashland, JRiver Media Center

leezer3

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 1589
Re: File Selection Change
« Reply #33 on: March 15, 2016, 09:46:19 am »

Coming next build:
Changed: The logic that takes the selected files for the Action Window will allow none to be selected if the entire set of files is one album (otherwise it'll still say no files selected).

It's a little complicated to explain, but basically if a single album is selected the files will show in the Tag window instead of saying no files selected.

Whilst I think is is better than the previous try, an option for this to apply globally or not at all would still IMHO be better.

-Leezer-
Logged

JimH

  • Administrator
  • Citizen of the Universe
  • *****
  • Posts: 72550
  • Where did I put my teeth?
Re: File Selection Change
« Reply #34 on: March 15, 2016, 10:06:08 am »

Whilst I think is is better than the previous try, an option for this to apply globally or not at all would still IMHO be better.
Can you see a solution that doesn't involve another option?
Logged

Otello

  • World Citizen
  • ***
  • Posts: 204
Re: File Selection Change
« Reply #35 on: March 15, 2016, 10:20:10 am »

Whilst I think is is better than the previous try, an option for this to apply globally or not at all would still IMHO be better.

-Leezer-


+1

Sorry Jim, maybe I missed something, but I understand you made this change because of a possible big issue if you edit the path field...
Why don't you try to disable editing of path field if more than one track is selected?
Logged

Matt

  • Administrator
  • Citizen of the Universe
  • *****
  • Posts: 42449
  • Shoes gone again!
Re: File Selection Change
« Reply #36 on: March 15, 2016, 10:29:29 am »

+1

Sorry Jim, maybe I missed something, but I understand you made this change because of a possible big issue if you edit the path field...
Why don't you try to disable editing of path field if more than one track is selected?

It's editing any field that's a problem.  "I accidentally picked all my files [even though none were selected!] and cleared the genre.  Help!"
Logged
Matt Ashland, JRiver Media Center

Otello

  • World Citizen
  • ***
  • Posts: 204
Re: File Selection Change
« Reply #37 on: March 15, 2016, 10:39:19 am »

It's editing any field that's a problem.  "I accidentally picked all my files [even though none were selected!] and cleared the genre.  Help!"

if you clear the genre you do not delete the files; I mean: it's an issue, but not a BIG one. ;)
Logged

glynor

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 19608
Re: File Selection Change
« Reply #38 on: March 15, 2016, 01:38:26 pm »

Deleting data is a big deal and metadata is data. See above for a ton of explanations.
Logged
"Some cultures are defined by their relationship to cheese."

Visit me on the Interweb Thingie: http://glynor.com/

glynor

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 19608
Re: File Selection Change
« Reply #39 on: March 15, 2016, 01:56:33 pm »

Can you see a solution that doesn't involve another option?

I proposed one above, which I think is actually better than both an option or the current behavior:

Speaking of which, I'd be perfectly happy with this solution:

It goes back to the way it was. But, when no file is selected and you edit a tag in the AW, it prompts with a dialog confirming that you want to edit all files (with an associated "go away and don't come back" checkbox). That would also match the behavior of the Panes, and would give me that one extra sanity check (requiring a second Enter).

That would be better in a few ways:
* It would protect us from ourselves (and apply equally to all fields).
* It would match the behavior of the Panes.
* It would not require an option.
* It would let the people who really want this and aren't afraid to put it back the way it was without bothering the rest of us.
Logged
"Some cultures are defined by their relationship to cheese."

Visit me on the Interweb Thingie: http://glynor.com/

Otello

  • World Citizen
  • ***
  • Posts: 204
Re: File Selection Change
« Reply #40 on: March 15, 2016, 02:25:23 pm »

Well, Glynor, I'd be perfectly happy with your solution, too,  
but, so to speak, deleting files is a big disaster, deleting one tag is just a question of restoring the last JR library  backup and redo the last operations.
Logged

blgentry

  • Regular Member
  • Citizen of the Universe
  • *****
  • Posts: 8014
Re: File Selection Change
« Reply #41 on: March 15, 2016, 02:38:54 pm »

I advocate an option as I think that's what it calls for.

That being said, I think Glynor's solution is probably just as good.  So I vote for Glynor's solution if an option is exceptionally undesirable for some reason.

Brian.
Logged

leezer3

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 1589
Re: File Selection Change
« Reply #42 on: March 15, 2016, 05:41:34 pm »

Can you see a solution that doesn't involve another option?

Personally, I'd roll this straight into the existing Pane Tagging option.

Advantages:
  • Clearly states that the contents of the panes are being tagged in the option title
  • Matches behavior of the panes, especially as it relies on a selection within a pane
  • Not default behavior- Single existing keypress to activate though.

A 'Don't ask again' checkbox is not IMHO a good option, unless it's permanent.


Either way, these are just opinions. Feel free to lock this if you disagree-
Jim, it's your playpen :)

Edit:
Final note- I very much agree with the metadata is in your backups assesment.
By all means protect from deletions, but metadata is to me easily replaceable.

-Leezer-
Logged

ferday

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 1732
Re: File Selection Change
« Reply #43 on: March 15, 2016, 05:42:36 pm »

Coming next build:
Changed: The logic that takes the selected files for the Action Window will allow none to be selected if the entire set of files is one album (otherwise it'll still say no files selected).

It's a little complicated to explain, but basically if a single album is selected the files will show in the Tag window instead of saying no files selected.

This is fair.  Most of the time I'm tagging by album anyways and I would suspect so are most once the initial big tagging of an existing collection is complete

Logged

glynor

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 19608
Re: File Selection Change
« Reply #44 on: March 15, 2016, 05:57:03 pm »

deleting one tag is just a question of restoring the last JR library  backup and redo the last operations.

Final note- I very much agree with the metadata is in your backups assesment.
By all means protect from deletions, but metadata is to me easily replaceable.

Sigh. Again... This was addressed at length above (and in previous threads):

That only works if you notice the problem right away. What if you change all of the values of a particular field in your Library, and then don't notice it for days, weeks, or months later? What if you notice 10 minutes later, but you'd already done a massive Rename of many files in your Library (something I often do while tagging, I'll add)? There are literally hundreds of ways to make a Library Backup not a fail-safe, and especially with Split Views, it only takes one errant click to cause massive destruction.

In those cases, restoring from backup is likely to be worse. Then you'll have a Library strewn with the correct metadata, but tons of broken links. To me, destroying metadata is far, far worse than deleting the files. Files can be restored from backup (or re-acquired from their original source in many cases) and it doesn't much matter what happened in the intervening time. The metadata system is fragile, and without it, the files might be useless.

This has happened to me. This has happened to others. Destroying data is destroying data. It may not be a "big deal" to you, but you can't know how it might impact others. As I said above:

I only post this as an illustration that focusing on the one [Filename] example misses the point. Destroying data is really, really bad. Particularly when it can do so in a way that is:
* Counter to the way basically all other applications behave.
* Counter to the way MC itself behaves in other situations.
* Swift and silent.
* Sometimes, difficult to reverse (especially as a side effect of being swift and silent).

I think matching the behavior of the Panes makes the most sense, and is the most flexible. Show a warning. Include a "go away" checkbox like many of the other warnings have already, and it is done.
Logged
"Some cultures are defined by their relationship to cheese."

Visit me on the Interweb Thingie: http://glynor.com/

leezer3

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 1589
Re: File Selection Change
« Reply #45 on: March 15, 2016, 06:27:29 pm »

Whilst I'm not trying my hardest not to argue, I think it's clear we have a fundamental difference of opinion :)

For the record:
I *never* rename or move any files.
Things are moved manually once from an incoming location to a drive, and never touched again, except in case of drive upgrade of failure.
All data is in the metadata, and the metadata is served to the other machines in the house by library server and backed up. *Nothing* alters tags other than the main PC.
I completely agree that renaming massive numbers of files at once is not a good thing, as this will always stuff any backup, and I've specifically argued against editing the filename field in this scenario.

With my library setup, there's simply no way to not notice a change of that magnitude.
Every view depends on at least one calculated field, and that sort of change would break something.

If you're that worried about the absolute integrity of your data, and the consequences of re-enabling it as an option for causing mass destruction, perhaps you should be considering a twin backup solution for both the library and the media?
ZFS file versioning or NTFS shadow copies might even be what you're after- Whilst this takes up a little more space,

Again, I'm not trying to belittle your losses, but I think that perhaps they are coloring your view.
There are absolutely things that should be done to protect data and metadata, but sooner or later you run into a situation whereby they hamper other users.

Other software:
Bringing other software into the argument is a double-edged sword; MC is at heart what I'd term a power-user application, rather than Kodi (XBMC) or WMC which put a much prettier face onto a more limited backend.
If we consider power-user software for a minute, there are plenty of apps which can trash a whole system with just a few keystrokes.
Open up a Linux command prompt, and run this command:
Code: [Select]
sudo cd / && rm * -rfWhole system bulldozed with just a password prompt :)
Similarly, SQL will let me run a command which modifies thousands of records without a single peep.
Windows Registry editor, the list goes on.

Once again, these are personal opinions only.
This is Jim's playpen, and he and the MC team will make the final decision on this. I can only make my points.

(Note: I have RTMd this, the discussion is perhaps getting a little out of hand?)

-Leezer-

-Leezer-
Logged

JimH

  • Administrator
  • Citizen of the Universe
  • *****
  • Posts: 72550
  • Where did I put my teeth?
Re: File Selection Change
« Reply #46 on: March 15, 2016, 06:37:29 pm »

Remain calm at all times.  We will find a way to improve this.

Jim
from the playpen
Logged

marko

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 9168
Re: File Selection Change
« Reply #47 on: March 15, 2016, 07:13:18 pm »

I think matching the behavior of the Panes makes the most sense, and is the most flexible. Show a warning. Include a "go away" checkbox like many of the other warnings have already, and it is done.
That would work for me. But give me it all, not just 'per album'.

Tag the old way or the new way? Don't ask again.
I also believe that the root of this issue is that MC will insist on randomly changing the active view in a multi-view setup. If that got fixed, most, if not all of this hullabaloo would be unnecessary.

-marko

glynor

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 19608
Re: File Selection Change
« Reply #48 on: March 15, 2016, 08:13:31 pm »

That would work for me. But give me it all, not just 'per album'.

Tag the old way or the new way? Don't ask again.

I'm sure you didn't mean this, but I want it to ask over and over again, just like enabling Pane Tagging does when you check the little checkboxes. With that "sanity check" I'll use the feature again (as I said above, I did use it all the time).

I don't know how easy it is to do the "sanity check popup" but where to place it is pretty simple. Matt gave pseudo-code showing how it decided on selection before and it amounted to:
Code: [Select]
If selection == null then selection = GetFilesInCurrentView()
You just change this to:
Code: [Select]
If (selection == null) then
     If ShowWarning() then
          selection = GetFilesInCurrentView()
          TagFiles(selection)
     Else
          Cancel
Logged
"Some cultures are defined by their relationship to cheese."

Visit me on the Interweb Thingie: http://glynor.com/

glynor

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 19608
Re: File Selection Change
« Reply #49 on: March 15, 2016, 10:52:21 pm »

This is fair.  Most of the time I'm tagging by album anyways and I would suspect so are most once the initial big tagging of an existing collection is complete

I'd like to point out that I don't really like Matt's new solution (as a solution). I'm okay with it, I guess, but it certainly doesn't help me, and it makes MC have another "secret behavior" which is non-intuitive and oddly limited. I think either the warning or the option are better solutions.

If it applies to [Album] why not [Season] (which is the same thing)? What about [Opus]? And so on and so forth...

I proposed one above, which I think is actually better than both an option or the current behavior

I feel like I didn't explain why I think the warning prompt is better than an Option, and I figure that's worth pointing out in case it isn't obvious:

Because with an Option, I'm forced to choose. I can either (1) be safe, or (2) have a more efficient way to use the Tag AW on multiple files. With the Warning method, I can choose both.

Again, a good corollary is the Pane Tagging. If there was no warning there and I had to choose between either (1) the checkboxes are always active (and so an errant click will retag files), or (2) Pane Tagging is turned off, I'd choose safety every single time. I know this would be the right call because I've gotten that warning dialog 100s of times over the years when I didn't intend to activate Pane Tagging (I sloppily tried to re-filter a View and hit the checkbox by accident).

But Pane Tagging is absolutely awesome. That's how I do the vast majority of my non-automated tagging. The warning dialog box lets me have my cake and eat it too.
Logged
"Some cultures are defined by their relationship to cheese."

Visit me on the Interweb Thingie: http://glynor.com/
Pages: [1]   Go Up