Print

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

[wig]

Yes, but I don't see the usefulness in Media Center outside of the example I presented, which is not really "voting".
Voting is useful when you have a lot of users rating a single piece of content. Not a single user rating many pieces of content. And its discussion doesn't really belong in this topic.

I think you're taking 'voting' a bit too literally. It's another method to set the same three states that are being dicussed with the checkbox, but in a friendly, familar format.

As far as relevance, I feel confident that Jim will spin it off if it needs it own topic. 

[6233638]

I think you're taking 'voting' a bit too literally. It's another method to set the same three states that are being dicussed with the checkbox, but in a friendly, familar format.
As far as relevance, I feel confident that Jim will spin it off if it needs it own topic.  

Are you simply talking about having graphics like this:
or

Instead of this?

 
Because I don't see how that is useful, and it could be defined by the skin.

[wig]

Are you simply talking about having graphics like this:
or

Instead of this?

 
Because I don't see how that is useful, and it could be defined by the skin.

I'm suggesting something like this.





Icons and Colors aren't important. It's the functionality I'm after.

[6233638]

I feel like that could probably be handled by skinning the checkbox, but I really don't see the usefulness of that compared with the regular field, or using the ratings field.
How is a track three stars, but unpopular? It should be 1 or 2 stars.

[glynor]

You can default them however you want with Tag on Import rules.

I don't think what wig is asking for has much of anything to do with the Boolean field I wanted.

[6233638]

You can default them however you want with Tag on Import rules.

Hmm, I suppose that's true.
What do you think "undefined" should be represented by then?

[glynor]

What do you think "undefined" should be represented by then?

There is no undefined.

Undefined is zero.  You're thinking that MC treats Integers as a nullable type.  It does not.  When it displays an Integer-type field, if the value is Zero, it shows it as blank.  Once set, there is no way to make it "blank" again, because it never was blank.

When it imports a new file, all Integer type fields are "initialized" as zero (not manually, that's just the default value of integers).

If you leave it set to a String-Type field, I suppose there is techically a way to tell the difference between one actually set to zero, and one that hasn't ever been touched.  But, again, since it is a two-state checkbox (and three-state checkboxes are confusing and, even if they added that feature, would have to be optional) there are better ways to do that.  Make it a String Type Field, with a regular Edit Type, and give it an Acceptable Values list instead.

Though, I would add... If you find yourself doing this a lot, where it doesn't make sense to use a String-Type field with an Acceptable Values list, then you should really kind of reconsider what you are doing.  The best bet is to design "flag" fields like this so that they default right most of the time from the get-go, and don't require manual tagging except in the "exception" case.

You can often accomplish this by simply reversing what you wanted to "name" the field in the first place (and so, reverse what True and False do).  That way, you only have to "tag" the exceptions-to-the-rule, and the more-common cases are already right.

If you want to display the reverse in a Column or Theater View or something, to make it look nice, that's fine.  Just make a Calculated Field that displays what you want it to display based on the setting in the "real field".

[6233638]

As a string there is an "undefined" state, which is the same as 0 in appearance, but evaluates as "empty" rather than "0"
 
rudyrednose's suggestion for it to be -1 instead of empty seemed like a good idea, and I can imagine where that might be useful.
 
I personally don't see the need for it to have a third appearance, and am happy for it to appear the same as 0.
 
If it's currently an unintended feature, I'd leave it as-is rather than remove it.

[glynor]

If it's currently an unintended feature, I'd leave it as-is rather than remove it.

I suspect Matt left it as a possibility for exactly this reason.  He could have locked it to Integer types, but why?  Then someone is just going to yell at him, and it doesn't really matter what you have it set to, as either will work in the simple case.

And, it does leave open this possibility to "detect" the difference if you really care.  It won't show the difference, but you can detect whether something was manually set false versus auto-set false, so... That's handy for nerds maybe, so leave it in.

[glynor]

I thought I'd mention one super-awesome side effect I noticed.  This works just fine:



So, you can make a new Calculated Field that spits out 1 or 0, and set the Edit Type to Check, and it'll display in Columns as a checkboxes.  You just have to switch back to User Data for a minute (it doesn't lose the Expression if you've already added it), and set the Edit Type there.

[wig]

I feel like that could probably be handled by skinning the checkbox, but I really don't see the usefulness of that compared with the regular field, or using the ratings field.
How is a track three stars, but unpopular? It should be 1 or 2 stars.

I've considered skinning the 5 Stars (Ratings) field for this type of purpose, but I still use it for it's intended purpose (mainly because it's important for Play Doctor).  Is there any way to 'clone' the 5 Stars field and skin that?

The tri-state checkbox would be a good solution for me. Hendrick's post suggested we're not likely to see it, so I offered an alternative interface providing the same results. It is not proving popular 

BTW, in my example Popular refers to 'chart' popular, not my personal rating. I hate lots of popular songs. 

[6233638]

I thought I'd mention one super-awesome side effect I noticed.  This works just fine:

http://glynor.com/img/screenshots/MC20/Calculated_Library_Field-Edit_Type_Works.png

So, you can make a new Calculated Field that spits out 1 or 0, and set the Edit Type to Check, and it'll display in Columns as a checkboxes.  You just have to switch back to User Data for a minute (it doesn't lose the Expression if you've already added it), and set the Edit Type there.

That's nice, but it doesn't seem like you can interact with it, which limits its usefulness.
 
I created a "DoNotPlay" tag and then a calculated field which inverted the status of DoNotPlay so that all tracks appear enabled by default rather than disabled.
 

 
While it displays correctly, you can't click the box to set DoNotPlay to 1. (DoNotPlay would normally be hidden)

I really don't like the idea of having a field that should be undefined for most tracks, and setting that tag to 1 on all files in the library and adding it to all of my import rules to make it checked by default. (and editing auto-import rules is such a chore)
 
I'd still prefer an option for the field which sets its undefined appearance as checked or unchecked. (or grayed out if you want undefined to be a third state)
 
And of course, there still has to be some way of actually telling Media Center to not play these tracks, which I haven't figured out yet.

[rudyrednose]

That is exactly why I originally proposed an Integer based field in my previous post: http://yabb.jriver.com/interact/index.php?topic=92678.msg639412#msg639412

In all programming languages I have dealt with, a new instance of an Integer is initialized as 0 (and a boolean value is a short Int).

0--> unchecked
1--> checked
-1--> undefined (greyed box) for those who want to use it.  Others would never have to deal with this third state 

And the extension of all positive values showing as checked and all negative values showing as greyed would insure consistent operation and no "out of bounds" issues...

[glynor]

0--> unchecked
1--> checked
-1--> undefined (greyed box) for those who want to use it.  Others would never have to deal with this third state.

No.  That would break basic functionality for all of the fields I've crafted, where it is assumed that new files come in (as they always have in MC since I've been using it) with a default value of zero in all Integer fields.

In all programming languages I have dealt with, a new instance of an Integer is initialized as 0 (and a boolean value is a short Int).

Right.  Integer Fields in MC are initialized to zero.  There's no such thing as an "empty" Integer field (integers are not nullable in MC, as I said above).

But, you said in what you "wanted" that undefined would be -1.  If there IS a three state checkbox, undefined would have to be 0, right?  But zero is always false and 1 is always true (because, you know, binary).  How would MC know for the user if you wanted a three-state checkbox or a two-state checkbox?  How would it know what to toggle when clicked, unless there was another mode?

I still think it would be better in nearly all cases to use a string type field in these cases.  You CAN detect a never-before touched field (if you use a string-type field, because isempty() can be set to parse the difference between a null string and a zero), you just can't display it with the checkbox because it is a two-state checkbox (a normal one).

If they want to give us the three state checkbox, then awesome (I suggested it in my very first post), but it would HAVE TO BE a new and separate Edit Type for the field.  You'd need Two-State Check and Three-State Check.

It sounds like Hendrik agrees with me, at least, in that I'd almost never use them because they confuse most people.

[glynor]

That's nice, but it doesn't seem like you can interact with it, which limits its usefulness.

Calculated fields are almost always read-only.

There is one exception, but it wouldn't apply in this case, I don't think.  You can write to a calculated field if it is only a pointer to another field (that's why the =[Number of Plays] trick used to work, and you can use it to write to other read-only fields).  For complex expressions, though, I don't think it works.

You might be able to pull it off with an expression column somehow, but I'm not sure.  We'd need MrC to come back to confirm for sure.

[6233638]

Calculated fields are almost always read-only.

I was sure I had a bit on the end of that sentence saying "which was what I expected, being a calculated field" but content from a lot of my posts seems to be disappearing lately.

You might be able to pull it off with an expression column somehow, but I'm not sure.  We'd need MrC to come back to confirm for sure.

Again, if we could set the default state for an undefined field to be checked, it would avoid any of the complication of trying to find a work-around, or assigning a value to every file in the library by default.
As an Integer undefined = 0 (currently, anyway) but as a String, undefined is empty while unchecked is 0.

[rudyrednose]

No.  That would break basic functionality for all of the fields I've crafted, where it is assumed that new files come in (as they always have in MC since I've been using it) with a default value of zero in all Integer fields.

Glynor, I think we have a misunderstanding here...
I agree with you, I said that new Integer fields have an initial value of zero (like everywhere).  I know very well that there are no null or undefined Integers, I used to design HW in high end telecom equipment...
I agree with you, we do not need a new data type, but that the Boolean Edit type can and should use an existing Data type.

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.
I think that using Integers would make using Booleans in filtering expressions be much more efficient and fast (Integer ops vs String manipulation ops).

In my -1,0,1 scenario, a new instance, being based on an Integer data type, would have an initial value of 0, yielding an empty checkbox (not greyed, not checked) if shown as a Boolean edit type.  They would not be instanciated as undefined (value=-1) !

A newly imported library record (media file if you want) would show an empty checkbox on a field (column) shown as Boolean, and the user could check the field with a left click and uncheck the field with a left click (toggling only between those two value in Pane tagging mode), but more advanced users would still have access to three possible values (0,1,-1) shown as unchecked, checked and greyed, respectively if that Integer data type (shown as Boolean edit type) is modified in the Tag Editor.

My point is really if a greyed checkbox is so confusing to a beginner, then he will never see one if he does not actively pursue that state through the tag editor (third choice of 3 in a tag editor drop down menu), as simply toggling with a mouse in Pane Tagging will never present that possible value.  But you would not prevent more advanced users of accessing and using that third state.

Even if the powers that be still think an undefined checkbox is not desirable and too confusing, so be it, but please do implement a Boolean checkbox in a fashion similar to C language and all its derivatives (the boolean data type is always a form of Int) for the sake of speed and efficiency...

[JimH]

Split: To Play or Not to Play

It wasn't a clean split.

[glynor]

Thanks, Jim.

I was going to do that today.

[cncb]

I am not getting a checkbox in the Tag Action Window, only an empty dropdown list.  I do get a checkbox in the Details view column.  Is this supposed to work in the Tag Window?

[cncb]

Anyone?

[blgentry]

I am not getting a checkbox in the Tag Action Window, only an empty dropdown list.  I do get a checkbox in the Details view column.  Is this supposed to work in the Tag Window?

As far as I know, the checkbox edit type only works in the list section of a view or other list (playlist, etc).  As you said, when you open the Tagging Pane, that field becomes a drop down list that you can select from, much like other list types. 

Whether or not that would be a good feature... I'm honestly not sure.  To me the whole point of the check box type is quick access.  Which means I'm going to check the box right there in the list, as opposed to opening the tagging pane and doing it one by one.  It's faster even if you are selecting a range of files.  Just select the files and then click the check box next to one of the files and it then applies to all of them.

Are you trying to do something specific that's hanging you up, or is this just curiosity?

Brian.

[cncb]

Thanks for the reply.  I am trying to make it easy for other users (family members) to mark images for deletion that I can later actually delete myself.  We always view images as thumbnails or in the Preview Mode.  It seems the easiest way to do this would be to have a boolean field with a checkbox in the tagging window that they could easily check.  A dropdown would work but would be more "difficult".

[blgentry]

Thanks for the reply.  I am trying to make it easy for other users (family members) to mark images for deletion that I can later actually delete myself.  We always view images as thumbnails or in the Preview Mode.  It seems the easiest way to do this would be to have a boolean field with a checkbox in the tagging window that they could easily check.  A dropdown would work but would be more "difficult".

Makes sense.  I'm not doing much with images in MC right now, so I'm sort of simulating your use showing album thumbnails, which I think is going to be just the same.  Except I haven't tested preview mode; I'm not sure how that would work.

What I've tested is showing thumbnails in a Panes view.  If you add your checkbox field as a pane, then you can use Panes Tagging to check the value next to your field for deletion.  The catch is, it can't be a checkbox type!  It needs to be a List type in order for Panes tagging to have a checkbox next to it.  Give it a try and see what you think.

Brian.

[cncb]

What I've tested is showing thumbnails in a Panes view.  If you add your checkbox field as a pane, then you can use Panes Tagging to check the value next to your field for deletion.  The catch is, it can't be a checkbox type!  It needs to be a List type in order for Panes tagging to have a checkbox next to it.  Give it a try and see what you think.

I can't get Panes tagging to work in an easy way since it will only show current values.  So, for example, I have to check "New To Delete" and select from the drop down in the dialog each time when nothing is already marked to delete.

However, you did give me an idea. When I set both the Field type and Edit type to List and supply one Acceptable Value of "Yes", then when I click it in the Tag Window it expands the field and shows a "Yes" checkbox at the top as an option.  One additional click compared to having a checkbox directly in the Tag Window, but this should work fine.  Thanks.

[blgentry]

I can't get Panes tagging to work in an easy way since it will only show current values.  So, for example, I have to check "New To Delete" and select from the drop down in the dialog each time when nothing is already marked to delete.

You have to select something first.  Click on an image or two to select them.  Then the Pane with New To Delete will show it's values as check boxes that you can select.

Brian

[cncb]

You have to select something first.  Click on an image or two to select them.  Then the Pane with New To Delete will show it's values as check boxes that you can select.

I know, but if nothing is already assigned to "Yes", then "Yes" won't show up as a possible selection until I check "New To Delete" and then select "Yes" from the dropdown in the dialog which is even more difficult to understand.

[Matt]

This is only lightly related to the things you were talking about above, but it seems like this thread is a good home for it.

Next build will have this change:
NEW: Editing a checkbox type field in the new Tag Action Window will show a checkbox instead of a dropbox.

[blgentry]

I know, but if nothing is already assigned to "Yes", then "Yes" won't show up as a possible selection until I check "New To Delete" and then select "Yes" from the dropdown in the dialog which is even more difficult to understand.

Ah ok.... I should have known that's what you were trying to describe.  I was using a Panes view that shows everything and was limiting it to show only certain items by clicking in the Panes.  I just tested it your way, and of course you are correct that it doesn't work as anticipated.  Darn.  But Matt seems to be fixing this for you in the next build so that checks work in the Tagging Pane. 

Brian.

[blgentry]

Next build will have this change:
NEW: Editing a checkbox type field in the new Tag Action Window will show a checkbox instead of a dropbox.

Do you mean just the normal Tagging Pane, or the "new" hidden Tagging Pane?

Brian.

[Matt]

Do you mean just the normal Tagging Pane, or the "new" hidden Tagging Pane?

Brian.

Just the experimental Tag window.  You get to it by holding Shift down.

Not sure if we'll update the old tag window or not.  Not today at least.

[blgentry]

^ ...and I thought that new Tag window was a secret!   I would probably use the new Tag window more if there was a pure keyboard shortcut to get to it.  Maybe I should just try it out for a while and see if I want to switch to using it full time...

Brian.

[cncb]

Any chance Shift could be a toggle and it will open the last used version of the Tag Window until you toggle it again?

[Matt]

Any chance Shift could be a toggle and it will open the last used version of the Tag Window until you toggle it again?

Sure.

Next build:
Changed: Opening the new Tag Action Window with shift held will then always open the new tag window after that (just press shift again to switch back).

[ferday]

awesome, thanks Matt

i just discovered the new tag window when i read this thread.  so far i think it's pretty fantastic