Print

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

[glynor]

Where I disagree is the data type over which the Boolean edit type should be mapped.  You seem to be a proponent of using string types.

No. There is currently no mapping.  You can use whatever type you want.

I asked for integers at the outset, and all of my uses of it are integers.  You can use integers.  It is just not locked to that.

[glynor]

None of the rest of what you stated makes any sense to me.  How would you input the -1 value?

The fact that the Tag Action Window shows a numeric entry box for these fields was an oversight, and has already been corrected.  The next build that comes out will show a checkbox in the Tag Action Window for these as well.

So.... How would you input a -1 value, without making users deal with a three-state checkbox?

[6233638]

So.... How would you input a -1 value, without making users deal with a three-state checkbox?

Isn't the point that you don't?
 
‒1 would be an undefined/unused field
 1 would be what happens when you check the box
 0 would be what happens when you uncheck the box


-1 only ever applies when the field has not been used.
 
If the default state of an undefined field is unchecked, clicking it would display a check and the value would now be 1.
Clicking it again would be unchecked with a value of 0
Clicking it a third time would set it back to 1
 
You never get back to "undefined" unless you manually reset the field—which can be achieved by editing it in an expression column if you really needed to for some reason.
 
I do prefer the -1/0/1 state for the checkbox (or "empty" / 0 / 1) especially if we could set the default state for an undefined checkbox to be checked/unchecked/grayed out to invert the default click state. (e.g. defaults to "checked" so that clicking on it once sets the field to 0)
It's not a "three state" checkbox in the sense that clicking it three times gives you three different values—clicking it would only ever toggle between 1 and 0.
 
Using -1 instead of "empty" would mean that you can no longer evaluate the field with the IsEmpty() expression, but you can always use:

Code: [Select]

If(IsEqual([Check, 0], -1, 2), <undefined>, <defined as 0 or 1>)or

Code: [Select]

If(!IsEqual([Check, 0], 1, 2), <undefined or 0>, <set to 1>)

[glynor]

Isn't the point that you don't?
 
‒1 would be an undefined/unused field
 1 would be what happens when you check the box
 0 would be what happens when you uncheck the box


-1 only ever applies when the field has not been used.

No.  That's what I thought at first, which is why I said what I said above.  Read ruby's reply above again.  He wants them to import as 0, and then be able to be manually changed to -1 by some mechanism that I don't think is well thought out.

If new files imported with a -1 value, it would break my workflow, and over 10 years of history with MC.  All fields import with zero/blank values, if not otherwise specified in the file tags.  Aside from Carnac, which is special (and even those import as null or zero, they just get initialized by Carnac immediately afterwards)...  That is a firm rule, and always has been.  Many of my calculated field systems are built upon this assumption.  And, especially my uses of the new check edit type are built upon this assumption.

Fields import false.  -1 isn't false or null.  It is a value.

And, it matches the behavior of every programming language that pre-initializes values (so they're not null) that I've ever encountered.  New fields cannot import as -1.

[glynor]

Again.  I asked for this in the original post.  I was assuming it would be implemented as:

* A second Edit Type (we'd have "Check" and "Check (Three-State)" edit types).
* That fields would still come in False (0) by default.
* That the tertiary value would either be 2 or -1.  Didn't matter much which.

But that's not what they did, and Hendrik basically explained why.  I'm not sure why we're still discussing this.

[6233638]

No.  That's what I thought at first, which is why I said what I said above.  Read ruby's reply above again.  He wants them to import as 0, and then be able to be manually changed to -1 by some mechanism that I don't think is well thought out.

Well I don't see the point of that.
 
I thought -1 was supposed to indicate an "undefined" field, not 0, and the reason to use -1 rather than <empty> is because then you can evaluate the field as integer rather than string, which would be faster.
 

If new files imported with a -1 value, it would break my workflow, and over 10 years of history with MC.  All fields import with zero/blank values, if not otherwise specified in the file tags.

I'm happy with the field being empty on import rather than -1.
 
The only way that affects me is whether I use IsEmpty() or If(IsEqual([Check,0], -1, 2),,) to evaluate the field.
 
But if you can't set the default state for an undefined checkbox, it doesn't seem like there's much point in distinguishing between 0 and undefined anyway.
 
Personally, I don't know that I have a use for the checkbox field without the option to set it as checked by default.
Not 1, but checked for an undefined field - however you want to set "undefined" internally.



I will say that I don't see the distinction between two-state and three-state checkboxes, if the third state = undefined.
You can just use three-state for everything.

[glynor]

But if you can't set the default state for an undefined checkbox, it doesn't seem like there's much point in distinguishing between 0 and undefined anyway.
 
Personally, I don't know that I have a use for the checkbox field without the option to set it as checked by default.

We already addressed this, I thought.  I'm confused as to why you are confused.

You can initialize any field in Media Center, to whatever value you want.  If you want a particular field to initialize to 1 or "cheese" or -678, you can do this now, whether they have a check edit type or not.  Even better, you can, if you wish, do so only conditionally based on other field values, or by their source directory.

The way in which you pre-initialize fields is by making a Tag on Import rule.

That is, literally, why that feature exists (I know, I asked for it over and over and over for years on end).  If you define a new field that you want to default to 1 no matter what, it would take seconds per Watched Folder to set them that way in Auto-Import, and you'd be done forever.  We've absolutely spent way more time discussing it than it would take you to implement it, even if you had 30 watched folders!

[6233638]

Tagging all files in my library with a value by default, instead of having a preference for the undefined state is inelegant at best.
 
I want to write the tag to the file when it is changed, which I can't do if I'm setting every single file in the library to 1.

[glynor]

It isn't undefined.

It is zero, or an empty string (which is treated by the check edit type, and most other places in MC, as identical).  There is no undefined in MC.  All fields always have a value.  In the COM API, they never return null, even for files that don't exist.

[6233638]

It is zero, or an empty string (which is treated by the check edit type as identical).  There is no undefined in MC.  All fields always have a value.

Call it an empty string rather than "undefined" then.
 
What I want is a distinction between files which have not had the tag changed (undefined/empty/-1) and files which have explicitly been set to 0 or 1.
 
I can't do that if I set everything to 1 by default.

[glynor]

And I'm pretty darn sure you can do that.

If you leave the Data Type set to string, and set the Edit Type as Check, then each field will have one of three values:

* Empty string
* 0
* 1

Fields will only contain a literal zero if you explicitly check the box and then uncheck it again.  The checkbox's visual won't change between an empty string and a zero, because that would imply a three-state checkbox.  But you could test against it with an expression if you want, and display the results elsewhere.

I can't think of a single example where I would want it to act this way, but if you do, I'm pretty sure you can.  I think that's why Matt didn't lock the Check Edit Type to only Integer Values with 0 and 1 acceptable values, as I initially suggested.  Because it works the same, and provides this extra benefit to nerds, so why not leave it in.

It isn't as elegant as having a dimmed checkbox.... I'll grant you, but a 3-state checkbox cannot substitute for a 2-state one, and on or off only values are obviously the much more common case.

[6233638]

Yes, but an Empty String defaults to unchecked, which is why I'm requesting an option to set the default state. (not the default value)
 
Assume that you've never used the program before. In this track listing, would you expect Track 11 to be the only track which plays, or the only track which is skipped?
 

 
Or does it make more sense to present things the other way around, so that a positive indicator is not used for a negative effect?
 
I don't personally have a use for a dimmed checkbox as a third, default state.
I just want to be able to set the default state for an empty string to checked for certain fields.

Since it would be trivial to set the opacity to 50% I have no objection to adding the option for a grayed-out box as the default state for people who want it.

[glynor]

Make it an Integer field, and set the default value higher than 1 with a Tag On Import rule.

[6233638]

Make it an Integer field, and set the default value higher than 1 with a Tag On Import rule.

Will that be written to the file if it's set via auto-import?
 
If I manually change the status of a track to 1 or 0, I'd like it written to the file, but not by default.
I assume that if I set everything in the library to "2" it won't be written to the files if I only enable that option afterwards. (or do all tags get written any time there's a change?)

[glynor]

Tags get written when changed, if tag writing is enabled.  Tag on Import rules are changes.  They import empty/zero.

However, you can disable file tag writing as part of auto-import, if desired.

[6233638]

So the short answer is that this is going to require writing changes to every file in my library then.
 
That's why I'd prefer an option to set the default state (not value) rather than using a work-around that just happens to work.
 
EDIT: Hmm, looks like using an expression field with =[PlayStatus] does not allow me to edit the value to set it to 2.
 
That used to work for certain fields, but perhaps it's prohibited due to the field type?
 
Can't set it via the tagging pane either. How did you manage that?

[glynor]

I don't understand why your requirement is so absurdly specific.

You can turn off tag writing on import.  You could make the field not save to tags at all.  You could reverse your logic and not fight the system and default off.

If you really want a three state system like you're describing, you could make one with a ratings edit type (just shrink the column to be two stars wide).  MC doesn't have a way to do a true three state graphical display, so, no it won't be perfect.  Alas, life rarely is.

But a Boolean field would commonly be understood to initialize to false.  That's just the way it is.  A n-state edit type is a different type of request.

[glynor]

If you didn't think of it: You could make a second Has Been Set column, that checks the value of the editable field (for an empty string or whatever), and display that as a checkbox column too, if you want.  Or make it show a red star or something.

But it seems like a reach that a scenario with all of these very specific requirements is... I don't know.  How common could it be?  It just seems like thing after thing.

[glynor]

EDIT: Hmm, looks like using an expression field with =[PlayStatus] does not allow me to edit the value to set it to 2.
 
That used to work for certain fields, but perhaps it's prohibited due to the field type?
 
Can't set it via the tagging pane either. How did you manage that?

I used a tag on import rule.  The equals expressions should work too, I'd guess, though I didn't test it.

[6233638]

I don't understand why your requirement is so absurdly specific.

It's the one playback feature from iTunes that it gets right over every other player out there, in my opinion.
With the new boolean field we're so close to being able to replicate that now.
 
But the field needs to be checked by default. The worst possible UI you can have is to use a positive value (a checkmark) to indicate a negative effect. (don't play)

Pre-setting all values to 1 is not a good idea because:
a) It's going to write changes to every file in my library. (great, now I have to back up terrabytes of data to 5 drives)
b) I have no way of finding out which files I have interacted with. I can find out which tracks were set to 0, but not which tracks were set to 1.

Setting them to 2 at least fixes B, though I can't find a way to do that outside of the auto-import rules.
 

You can turn off tag writing on import.

Right, but if I change any other tag it will write [PlayStatus] = 2 into the files?
 
If I've made a decision and set it to 0 or 1, I would like it written to the file so that it doesn't disappear.
I don't really want to be writing 2 or some other value to it.
 

You could reverse your logic and not fight the system and default off.

Don't play? Yes!
or
Play? No.

As I demonstrated above, the reverse just looks wrong and is the worst thing you can do from a usability standpoint.

MC doesn't have a way to do a true three state graphical display, so, no it won't be perfect.  Alas, life rarely is.

I don't even want three states displayed, just a way to set the default state to checked rather than unchecked when the field is empty, so that the first click sets it to 0 rather than 1.
 
That way only tracks which have been interacted with will have an 0 or 1 written to the files, instead of setting every file to 2.

[glynor]

Oh, I get what you're after.  Why do you need, for that, it to ever write that field to the tags?

User defined fields don't write to tags by default.  You can enable or disable this on a case by case basis.

PS. I'm on my iPad not my computer, but I think you're doing the edit a non editable field trick wrong.

[6233638]

Oh, I gt what you're after.  Why do you need, for that, it to ever write that field to the tags?

User defined fields don't write to tags by default.  You can enable or disable this on a case by case basis.

Because my decision to skip those tracks is something which is unlikely to change, and it's probably going to be set for more than a handful of tracks.
 
I have not yet checked to see whether iTunes reads/writes that setting to a tag (probably not) but it's certainly not something I want to have to set again after losing it the first time (moving to MC) so I'd like it written to the file tags.
 
 
After being burned many times when moving from one player to another—not that I plan to move away from MC any time soon, and not that it guarantees that another player will be able to do anything useful with these tags—I would much rather have information like that stored in the file.
 
I've used too many programs in the past where the data was only saved to its own database or a proprietary format, and was a nightmare to get my data out of it later. I don't anticipate that being an issue with MC, but who knows, maybe my MC library and backups explode and I'm left just having to re-import the tracks.
I don't write everything to the files, but this is something that I'd like to—though only for files where I've actually made a decision, not for all tracks.

PS. I'm on my iPad not my computer, but I think you're doing the edit a non editable field trick wrong.

You could be right.
 
EDIT: No, looks like it's uneditable if it's a check field. After changing the type it worked.
 
Also, if the value is set to 2, clicking it sets it to 1 rather than 0, so it remains checked.

[glynor]

I also don't understand why, if you're really after just replicating the iTunes checkboxes feature, why you can't just have them all set to 1.  Does iTunes expose what you're requiring?

Does it even write this to tags ever?  Even if it does exactly what you're asking for, what exactly in the enable/disable playback checkbox feature requires you to have it written to files, but only when explicitly enabled, but it is cool if you accidentally check and uncheck one to have that destroy the "never touched" state and write tags.

If you want the tags to be written, then you want them to be written. If you don't, then, you know, don't turn that on.  It doesn't do it by default. The part of the request that seems tortured is the specificity of the tag writing, on top of the default state, on top of the detecting which have never been touched...

[glynor]

I delete those files.  The iTunes checkboxes are baffling to me.  I know Matt has said much the same before.

But anyway, you can do it.  It is the weird tag writing religion that is blocking you.  To me, if the tag is important enough to write to a file, it should always be included.  Full stop.

Set them all to one.

[glynor]

PS.  MC has robust metadata export capabilities.  You will never have data locked in.  You can export the whole Library to XML.  You can copy paste to excel. You can export to MPL, or CSV, or all sorts of crazy things.  There's a REST API.

The tags are only one tiny piece of that.  I like them too, but they're not sacred.  And they're not the only escape valve.

[glynor]

Actually, even with all of those (in my opinion, tortured) requirements, it is still possible:

1. Make your field.  Set it to standard edit type.
2. Disable tag writing globally.
3. Set this field for your entire Library to 2.
4. Add a Tag on Import rule to set any new files to 2.
5. Disable the option in Auto-Import to write tags.
6. Make your field a checkbox edit type.
7. Re-enable global tag writing.
8. Profit!

[6233638]

I delete those files.

I generally play albums. There are tracks which are good (rating of 3+ stars) but are so overplayed that I don't want to hear them.
 
An example of that might be Queen's "Another One Bites the Dust". Right now, I could go without hearing that ever again, even though it's a good track.
 
It doesn't mean that I want to delete the track from my library since it breaks the "complete" status of the album. It's easier to "waste" 25MB of disk space and keep the track than dig out the CD and re-rip it at some point in the future - if the CD still works by then.
 
 
The other example would be when I have decided that I don't like a track, but revisit it in a number of years. There was a period of time maybe 10-15 years back where I got into a bad habit of buying discographies. Heard more than a couple of tracks from an artist that I liked? Ended up buying all of their studio albums.
 
That may not have been the smartest decision, because sometimes you end up with an album where you only like one or two of the tracks, but it's done now. However upon revisiting some of those albums 5-10 years later, my opinion of them has completely changed - some of them are now even tracks I'd call favorites.
 
So I don't want to delete or hide these tracks, but I don't want them to start playing if I just hit play on an album or start playing random tracks either.

The iTunes checkboxes are baffling to me.  I know Matt has said much the same before.

Well it means I can just hit play on an album and then not remove the two tracks off it that I don't want to listen to.
Or those tracks won't sync to a mobile device when I copy over an "artist" or "album" instead of micro-managing what gets copied over and what doesn't.
 

Set them all to one.

Well if I just wanted to replicate the iTunes feature, that would work I suppose.
But now I'm used to Media Center's library management features and would find it useful to be able to discriminate between tracks which have and have not had a value set.
 
And as before, I'd like to write changes to the file when I have made a decision, but not write to all files by default.

3. Set this field for your entire Library to 2.

2 doesn't work.
When you click a check field set to 2 it is set to 1 and stays checked, rather than changing to 0.

7. Re-enable global tag writing.

Doesn't that mean 2 would get written to the files if any tag is changed, and not just [PlayStatus]? (or whatever I end up calling it)

[glynor]

I didn't say it would be perfect, but possible.  But those compromises are only needed because of all of the other requirements.

You could also do any of these things:

1. Set them all to 1.
2. Not write that field to tags or always write it.
3. Not care if 2 gets written sometimes in certain rare situations.
4. Call the field [Skip] and reverse the logic.
5. Rate them 1 star and set MC to hide 1 star tracks in most views, and all shuffles (I don't hide them, but that's essentially what I do in the same situation with albums).
6. Flag them with a string type field with acceptable values of Blank, plus and minus.
7. Flag them with a Keyword instead (which is likely to be usable by other applications in the possible future).

[6233638]

4. Call the field [Skip] and reverse the logic.

Even if you call it skip, a ticked box is a bad indicator to show that a track is not going to play.

6. Flag them with a string type field with acceptable values of Blank, plus and minus.

This would work if I could set the default state to be checked instead of unchecked, so that clicking sets 0 rather than 1.

7. Flag them with a Keyword instead (which is likely to be usable by other applications in the possible future).

The checkbox is ideal for this, both as an indicator and for its ease of use. Managing keywords for this gets awkward as I use keywords quite a lot for other indicators. (e.g. Bonus, Live, Remix, Demo, Remastered etc.)
 
 
I'm really not trying to be awkward about this. It seems like we're spending more time going back and forth over this than it would take for Matt to add an option to set the default state for an empty string.

[glynor]

By the way, the first thing I did when they released this build, was converted my existing "Exclude from Views" Keyword special-value to a Checkbox-style custom field.

All of my top-level views (except Advanced, which always shows everything together), and Play Doctor, and shuffles, and smartlists all exclude these files.  It was easy to do, I have all of my existing shuffles, smartlists, and Play Doctor setup and whatnot filtered against a single "Never Include" smartlist (which also includes 1-star ratings and a few other flags that prevent files from being included in automated things).  So, I just had to change this one Smartlist.

Then, I just converted the existing [Keywords] does not contain "Exclude from Views" filters on the top-level Audio, Images, and Video media views to [Exclude from Views]=0.

I use this, combined with 1-star ratings, to accomplish the same goal as you described with the checkboxes.

If I check the [Exclude from Views] box (which is nicer now than my old method of adding that special "magic keyword"), the file vanishes forever from all of my "regularly used views" and is excluded from all of my automated shuffles, smartlists, handheld transfers and all of that jazz.

If I want the file to be kept, and still shown in my Views (so that I can find it easily in a party situation where someone requests it or whatever), but never to be played automatically mixed into a shuffle, I rate them 1 star.  As I said, I have the "Never Include" smartlist exclude 1-star tracks as well, so they're never automatically synced to my iPhones, or included in shuffles, or anything like that, but they aren't filtered out of my regular views so they still show up in Albums and stuff.

Those are my two tiers.  I usually use the Exclude from Views method for giant piles of new files that I haven't "dealt with yet" (gotten tagged enough that they don't cause havoc in my view systems).  I usually use the 1-star method for the types of files you described (a decent song in a good album that I'm sick of for whatever reason, or a bad song on an otherwise fantastic album that I want to keep but not hear unless I "ask" for it).  But, I do also occasionally use the Exclude from Views method for things more like the discographies example you provided.  "I don't want to delete this, really, but I don't want to ever be bothered by it until I go hunting for it."

Or I delete them.  If I really don't like it, and never will, and my wife never will, and I don't really care about the "album integrity" that much, then I delete them.

[glynor]

Even if you call it skip, a ticked box is a bad indicator to show that a track is not going to play.

That's an opinion.  I'd prefer it to having a bunch of checkmarks.  I like checkmarks to stand out (highlight the exception, not the rule).  That's fine if it is your opinion, but you've stated it as incontrovertible fact a number of times.

I don't think it is even close.  You're just used to the iTunes way.  Again, that's fine, but it doesn't make it gospel.

I'm really not trying to be awkward about this. It seems like we're spending more time going back and forth over this than it would take for Matt to add an option to set the default state for an empty string.

Neither of us know how hard it would be.  That could have huge impacts for reasons we can't conceive of, just be really hard, or he might already have it on his list.  Dunno.

But, I don't see a bazillion +1s here for it either.  I did the please give me some +1s thing maybe three or four times over three or four years before getting the fancy new checkboxes.  

[6233638]

That's an opinion.  I'd prefer it than having a bunch of checkmarks.  I like checkmarks to stand out (highlight the exception, not the rule).  That's fine if it is your opinion, but you've stated it as incontrovertible fact a number of times.

I don't think it is even close.  You're just used to the iTunes way.  Again, that's fine, but it doesn't make it gospel.

If it were an X or some other negative indicator, I'd agree, but it's a checkmark.
 
While you can word it however you want, if you look at the information presented without parsing the header, the default assumption would be that checked tracks are the ones which would play, not unchecked tracks, since they have the "positive" mark next to them, not a "negative" one.
 
Just because the text indicates otherwise, does not change the default assumption for it.
A checkmark is not a neutral indicator that should have dual meanings.
 
It's not a case of being the same as iTunes, it's a case of basic assumptions about how things work.
That's why you look at something like this and it feels instinctively wrong, or why it's a pain every time some web designer flips around the position of the next/cancel buttons in a web form.
 
I'm not saying that you can't use it that way, or that it wouldn't work, but that it's not intuitive.
  

But, I don't see a bazillion +1s here for it either.  I did the please give me some +1s thing maybe three or four times over three or four years before getting the fancy new checkboxes.  

It would just be a shame that after all that time we get the check field, but have to come up with crazy workarounds to use it in a certain way.
 
Of course that depends on your use-case, but most of the things I can come up with when I'm trying to think about how I could use it—not just trying to replicate this iTunes feature—would make more sense to be checked by default rather than unchecked.
 
And again, I'm not saying it should be 1 by default, but having an option to set the default appearance/behavior for an empty string would be very useful.

[glynor]

By the way, I'm not trying to be difficult. I'm trying to help you get an acceptable solution assuming that they don't implement what you're asking for.

It won't hurt my feelings if they do add some new way to override a particular field's default value.  But I think it somewhat unlikely based on what I've seen them implement before.  People were asking for exactly that before, including me, and they listened and gave us Tag on Import.

So, they probably have considered and rejected that option before for whatever reason.

[glynor]

Check marks are not inherently positive to me. They're boolean.  Sometimes they "include" and sometimes they "exclude".  It is a flag. Yes/No. True/False. 0/1. The rest is all contextual based on the question (heading or field name here).

I don't think it is as universal as you think it is.  Maybe I'm weird.  But maybe you're used to iTunes.

[6233638]

I haven't used iTunes for more than a few minutes (backing up/restoring/updating an iOS device) in a long time now.
 
A checkmark is inherently positive, just as an X is inherently negative.
Maybe not to a programmer type, but to most people.
 
https://en.wikipedia.org/wiki/Checkmark

[glynor]

I don't dispute that a checkmark often means on or 1 or True, versus false or off or 0.  Though it can also mean done or completed.  Check that off the list.

But the question is relevant. That you assume the check means "Play" and not "Skip" and say it can't be the other way is where I dispute your point.  It is weird for a checkmark to mean "not played".  It is not weird for it to mean Skip.  Depends entirely on how you look at it.  You assume the check means "play".  That's fine, but it isn't inherently "right".

I can't think of any examples, at all, where I'd prefer them to be checked by default.  To me, that means the logic needs to be reversed.  The idea of seeing a column mostly filled with repeating checkboxes is ugly to me.  That's terrible visual noise.

But, again, I gave you 7 possible ways.

If it were me, and I did want them all checked in a particular instance, I don't see why just marking them all 1 is a deal breaker.  Mark them one.  Write the tags if you want them tagged.  Done.  Next thing.

[glynor]

Tagging all files in my library with a value by default, instead of having a preference for the undefined state is inelegant at best.
 
I want to write the tag to the file when it is changed, which I can't do if I'm setting every single file in the library to 1.

This is the part that I think is weird and somewhat unreasonable.

You want them to be displayed as 1 but not to give them the value of 1.  It just sounds weird.  And I don't, at all, understand why you'd want a field to write tags, but only sometimes.  Write it or don't.  The value either matters and you want to protect it in the tags, or it doesn't.

I find it very weird when people treat the in file tags as sacred. If the tags ever don't match MC, to me something bad happened.

[6233638]

But the question is relevant. That you assume the check means "Play" and not "Skip" and say it can't be the other way is where I dispute your point.

Think of it in the reverse.
If you see a track marked with a red X next to it, would you expect that track to be played even if the field was "Skip"?

This is why UX designers exist. It's not enough to say "read the field and apply true or false to it".
The checkmark is inherently positive, and the positive action would be to play a checked track, not to skip it even if you word things so that it becomes "Skip? Yes".

I can't think of any examples, at all, where I'd prefer them to be checked by default.  To me, that means the logic needs to be reversed.  The idea of seeing a column mostly filled with repeating checkboxes is ugly to me.  That's terrible visual noise.

My next request is that they are skinnable. (and to mention that they are not currently being scaled up)
 
I do agree that they contribute some visual noise to the look of the program, especially in their current state where they appear to be a retina-sized graphic that is not optimized for display at 1× size.
 
I do have MC configured/skinned in such a way that eliminates a lot of the default visual noise (and for some people, it would be too much) so I can stand to add it.
 
An example of that would be the removal of the pips for rating stars and disabling the gridlines.
You could even do something similar with checkmark fields if you only need them as an indicator, so that they only display something when selected. (though they would probably need a hover state for most people to know they exist)
 
If they were skinnable and you really wanted to change their meaning, you could do something like this:
 

 

You want them to be displayed as 1 but not to give them the value of 1.  It just sounds weird.  And I don't, at all, understand why you'd want a field to write tags, but only sometimes.  Write it or don't.  The value either matters and you want to protect it in the tags, or it doesn't.

Well that's why someone else requested that the checkboxes be grayed out by default, having neither a positive or negative value associated with them, instead of acting as though they are set to 0 when undefined, as they currently are.
 
It only seems like weird behavior to you because being equal to 0 suits your intended use, while being equal to 1 would suit my intended use.
 
1 or 0 is a value I want to store. Undefined is not.
If "undefined" = 1 as you suggest I do, then all files get these tags written whether I have made a decision or not, and I am unable to create a view which only displays items that have a PlayStatus assigned to them. (or ones which do not)

[glynor]

Goodnight.