INTERACT FORUM
More => Old Versions => JRiver Media Center 21 for Windows => Topic started by: glynor on October 18, 2014, 01:20:04 pm
-
I've asked for this a ton of times in the past.
I want a Boolean Edit type (or Data Type) for user-created Library fields. When displayed in MC's interface, it should show with a checkbox (a checkmark or dot in Theater View).
I don't care how this value is actually stored internally, but if it were me writing it, I'd leave MC's actual field storage system alone, and just implement them as Integer fields, with the Acceptable Values automatically set to 0 and 1 only. If you make it so the checkbox can also be a three-state checkbox (-1, 0, 1) then even better, though I won't ask for the world here. ;)
Right now, you can kinda hack it (http://yabb.jriver.com/interact/index.php?topic=62843.msg422276#msg422276) by using Edit Type stars and making the column two-stars wide, but this looks dumb and doesn't work as well in the Tag Action Window and other places in MC where you might want to display this information.
This thread reminded me that it annoys me:
http://yabb.jriver.com/interact/index.php?topic=92573.msg638001#msg638001
I use these kinds of boolean fields a few places (particularly with my at-work Library), but the lack of a checkbox edit type means it is clunky and you have to be a nerd to use them.
-
I betcha if I get a bunch of +1s they'll listen.
-
I betcha if I get a bunch of +1s they'll listen.
+1
+1 +1+1
+1+1+1 +1
+1 +1
+1+1+1
-
Add me to the list of people who would love this.
-
+1, definitely.
-
+1 :)
-
Do
{+1}
While [Boolean_User_Field_Type != implemented]
-
I would find this to be useful.
+1
-
Yes please.
-
+1.
That would be handy.
-
+1
It would be great if we had both boolean AND Boolean (two-state and three-state), but a simple two-state bool would be sufficient.
-
Ok... Just for Glynor...
+1
-
Would be very useful. +1
-
++1
-
+1
-
--1 = +1 ;D
-
+1
-
Given the nature of the OP I think that rather than +1 he was actually asking for the following..
TRUE
OR NOT FALSE
-
Next build:
NEW: Library fields can be configured to have the edit type "Check" and then a checkbox will show for the field.
-
Next build:
NEW: Library fields can be configured to have the edit type "Check" and then a checkbox will show for the field.
This is how awesome you are. (http://www.youtube.com/watch?v=AZKpByV5764)
-
Check ++!
...and Glynor, I need some sort of palette cleanser after that video.
-
Awesome!
I just came to the forum to ask (again) for this very feature.
Very exciting!
-
+1
Yep!
-
Next build:
NEW: Library fields can be configured to have the edit type "Check" and then a checkbox will show for the field.
Thanks so much for this feature Matt. I'm starting to play around with it and have some feedback for you.
- Check Box fields don't work unless I leave the Acceptable Values field blank. Is this the proper setup?
- How do we use the Check Box fields in Smartlists and other queries? They don't seem to assign a value when checked
- The check box system is a major step forward, but I'm finding my tagging is designed around a 3 state configuration (On/Off/Unset) which is going to limit my use of it.
- What I love about this feature is the ability to quickly edit a tag without having to right-click or slow click. If you could expand this feature to open a drop-down box and display Acceptable Values (instead of simply turn a value on-off} it would be a homerun in my book.
What value does It looks like we need to leave the Acceptable Values field blank?
-
- Check Box fields don't work unless I leave the Acceptable Values field blank. Is this the proper setup?
Yes. Don't fill the acceptable values.
- How do we use the Check Box fields in Smartlists and other queries? They don't seem to assign a value when checked
The value is "1" when set.
-
The value is "1" when set.
Ok, I'm seeing that now.
I use a Calculated Data field to spit out the contents of a bunch of fields, so I was concerned that a bunch of "1" value would blow up that system. But using conditional expressions like this one in the Calculated Field will fix that for me.
if(isequal([Popular (Check)], 1, 1]), Popular, )
-
As mentioned here (http://yabb.jriver.com/interact/index.php?topic=92764.msg638949#msg638949), unchecking the box seems to clear the field rather than setting it to 0.
This means that you cannot evaluate the field with IsEmpty()
I also think that there needs to be an option for whether the field is checked or unchecked when empty, with a value of 1 or 0 being set when it changes.
-
As mentioned here (http://yabb.jriver.com/interact/index.php?topic=92764.msg638949#msg638949), unchecking the box seems to clear the field rather than setting it to 0.
Unchecking sets the field to "0".
-
Unchecking sets the field to "0".
Huh, I could have sworn that it was being cleared when I tried this yesterday.
-
I don't care how this value is actually stored internally, but if it were me writing it, I'd leave MC's actual field storage system alone, and just implement them as Integer fields, with the Acceptable Values automatically set to 0 and 1 only. If you make it so the checkbox can also be a three-state checkbox (-1, 0, 1) then even better, though I won't ask for the world here. ;)
Here's one more plea for the three-state setup.
I've tried converting my custom fields to the Check Box setup, but without the Off setting it just isn't the same. My smartlists are as much about exlusion as inclusion.
Green Check, Red Cross?
(http://www.psdgraphics.com/wp-content/uploads/2009/09/check-and-cross-icons-300x225.jpg)
-
I think in the vast majority of cases, using a String Type Field with a provided Accepted Values list is a better solution than a three-state checkbox (which are confusing to most normal humans).
Then, the labels can actually say what they are: Off (blank), State 1, State 2.
There is currently one issue with this relating to how field values display in the Panes, but that's a separate issue.
-
Huh, I could have sworn that it was being cleared when I tried this yesterday.
Remember, Zero == Clear (http://wiki.jriver.com/index.php/Media_Center_expression_language#Field_Values:_Empty.2C_0.2C_and_1) for Integer Type fields.
Your best bet is probably to use IsEqual() to test these fields. However, you can use IsEmpty() if you're careful to set the mode appropriately for your goal. All Integer Type fields will be set to Zero for any "untagged" (newly imported) item.
-
Is there an undefined (greyed) value ?
Am I ok to assume:
-1=undefined
0=unchecked=false
1=checked=true
-
Is there an undefined (greyed) value ?
Am I ok to assume:
-1=undefined
0=unchecked=false
1=checked=true
There is not. They did not implement that part of it. Values are 0 (unchecked) and 1 (checked). That's why I said this:
I think in the vast majority of cases, using a String Type Field with a provided Accepted Values list is a better solution than a three-state checkbox (which are confusing to most normal humans).
Then, the labels can actually say what they are: Off (blank), State 1, State 2.
-
I agree that tri-state checkboxes are confusing, which is why I would be reluctant to offer them.
-
Remember, Zero == Clear (http://wiki.jriver.com/index.php/Media_Center_expression_language#Field_Values:_Empty.2C_0.2C_and_1) for Integer Type fields.
Your best bet is probably to use IsEqual() to test these fields. However, you can use IsEmpty() if you're careful to set the mode appropriately for your goal. All Integer Type fields will be set to Zero for any "untagged" (newly imported) item.
That must be it. The first time I created a field must have been integer, and the second time will have been string.
IsEqual() doesn't really help since the checkbox field is empty by default.
0 or 1 would not be empty, while an unchecked field that had never been used would be.
But if it's simply a case of using string rather than integer for the field type, it's not a big deal.
I still think it is important to be able to set a field as checked by default (with no value) rather than unchecked.
This would be my main use-case. (http://yabb.jriver.com/interact/index.php?topic=92764.0)
What is the intended function of these tri-state checkboxes? Would -1 be equal to "empty" as I am using it above? (I'd prefer empty rather than -1)
-
I think in the vast majority of cases, using a String Type Field with a provided Accepted Values list is a better solution than a three-state checkbox (which are confusing to most normal humans).
Then, the labels can actually say what they are: Off (blank), State 1, State 2.
There is currently one issue with this relating to how field values display in the Panes, but that's a separate issue.
Is this a polite way of saying I'm abnormal? :P
I actually agree with you. Almost all of my custom 'tag' fields are String Fields like you describe. The problem is that updating them takes SOOOOO LOOOONG. I have to use the slow-click method or the keyboard to update the tags, and it's an ungainly process. I love the simplicity of the Check Field, but it's not just versatile enough in it's current setup.
In my perfect solution, I would to be able to choose from my Acceptable Values quickly, and using only my mouse. I've suggested a drop-down carrot that appears when you hover over a field, but I'm sure there are other solutions that would work.
What is the intended function of these tri-state checkboxes? Would -1 be equal to "empty" as I am using it above? (I'd prefer empty rather than -1)
Here's how I would use them. I have a custom field called Popular. It's starts empty, but I can then choose between 2 Acceptable Values, Popular and No. Those 3 states (Positive, Negative, Unset) are very handy when creating Smartlists for different types of listening.
-
OK, I wasn't misunderstanding then.
It is a three state checkbox, if you use string as the data type instead of integer.
It's empty rather than -1 though.
If you use integer you get <empty> or 1, not 0 or 1.
However this seems to persist if you change the data type.
I toggled some check marks while the type was set to integer, and they were set to 0 rather than empty when I changed it to string.
-
I agree that tri-state checkboxes are confusing, which is why I would be reluctant to offer them.
After doing some more reading about tri-state checkboxes, I realize I'm actually using that term wrong.
What I was proposing is actually closer to a voting mechanism, like on YouTube.
(http://hotspur.us/albums/misc/vote.png)
A simple positive/negative model would be fabulous.
I had to admit, though, that while looking at my post preview and seeing the numbers next to the thumbs, the ability to 'vote' more than once would be extremely cool. It would open up all sort of filtering possiblities for stats nerds like me. ;D
-
Well that's something very different.
I have previously suggested an alternate rating system loosely based around that idea, but I don't think there are any plans to change the current one.
What I proposed would not be upvote/downvote, but better/worse/equal.
Is the currently playing track better, worse, or equal to the last?
I am useless when it comes to assigning hard 1-5 values for tracks - the values I assign often just depend on my mood, and I don't find Media Center's rating scale useful at all. (2 should be a neutral rating, not 3)
However I have no trouble making a better/worse/equal decision when comparing the current track to the previous one, which Media Center could then use to figure out a ranking for the tracks, instead of a basic 1-5 rating.
-
Is this a polite way of saying I'm abnormal? :P
I thought about asking glynor for the phone number of this "normal" human being so we could hire her.
-
If you use integer you get <empty> or 1, not 0 or 1.
Thats to be expected, 0 in an integer field behaves the same internally as empty, as a plain integer doesn't have a "empty" state, it has to be some number.
-
Tristate checkboxes can be very useful.
Default to unchecked, but have greyed as an option for users that want to use it !
If we base it on type integer (signed) we can have, whithout creating a new datatype AND WITH NO AMBIGUITY if there is a residual value:
value of 0 --> "unchecked" or false
value positive (1 to 0x7FFFFFFF) --> "checked" or true
value negative (0xFFFFFFFF to 0x80000000) --> "grayed" or undefined or not yet defined
This is assuming integers are 32 bit signed values in JR. Adjust accordingly.
The benefits are
- much faster than string manipulations
- defaults to 0 (unchecked) like most new instances of an integer
- no need to define expected values / robust operation as there are no possible "out of range" values wreaking havoc
- does not prevents users of using "undefined"
- as integers, it can be used in straight IF/ELSE decisions, any value takes the IF, 0 takes the ELSE branch
-
Thats to be expected, 0 in an integer field behaves the same internally as empty, as a plain integer doesn't have a "empty" state, it has to be some number.
Well I wouldn't say that it was expected, but I understand the behavior now that Glynor explained it.
Rudyrednose's suggestions sound good, though I would add that it would be very useful if we could select the default state for the checkbox in its "undefined" state; checked/unchecked/inactive. (50% opacity?)
-
I think Check type is aim to easy change tag with Check and Uncheck that have only 2 value.
So I think it should can add two Acceptable Value for explain check is, uncheck is. Acceptable Value for explain should show in panes of panes view instead of 0, 1 and can Pane Tagging. At pane always show two value even if them have one value.
Last, Default value should is uncheck not Unassigned.
Thank again to add Check type it mark change some tag is easily.
-
I have a few additional thoughts regarding the potential third state, undefined.
As in .Net and elsewhere in Windows, I expect it would appear as a 50% grayed unchecked box.
I agree that tri-state checkboxes are confusing, which is why I would be reluctant to offer them.
It is true that the undefined choice might confuse some people.
I think that in Pane Tagging mode, the mouse left click should allow to toggle between checked and unchecked (invert the current state), but would not allow to "undefine" the checkbox. It is through the tag editor that a drop down menu would allow the three choices (0=uncheck;1=check;-1=undefined).
IMHO ;)
-
As in .Net and elsewhere in Windows, I expect it would appear as a 50% grayed unchecked box.
It is true that the undefined choice might confuse some people.
I can't think of the last time I saw this. I think most people would expect the unchecked appearance for undefined, not a third state.
That is why I suggested that the default state of an undefined checkbox be defined in the field as checked/unchecked/inactive.
I already have one use where I'd prefer the default state to be checked rather than unchecked or "inactive".
Inactive being "grayed out" either by displaying the unchecked graphic at 50% opacity, or with a third graphic if the skin includes it.
I would like to replace the current check graphic in my skin, but I'm not sure where it's being loaded from to replace it.
I think that in Pane Tagging mode, the mouse left click should allow to toggle between checked and unchecked (invert the current state), but would not allow to "undefine" the checkbox. It is through the tag editor that a drop down menu would allow the three choices (0=uncheck;1=check;-1=undefined)
Perhaps a right-click could "undefine" the checkbox.
-
I think most people would expect the unchecked appearance for undefined, not a third state.
undefined is a third state :)
And opening the door to predefine the checked or unchecked status of an undefined box is opening the Pandora Box. KISS-->undefined would be unchecked grey...
Perhaps a right-click could "undefine" the checkbox.
I thought about it, but I think it is not wise. Right click is universally a context menu (apart for lefties who invert their mouse buttons), better not touch that...
-
Well that's something very different.
A Voting field type IS different. It's also instantly familiar to anyone who's been on the internet for more than 30 minutes.
It's also useful. And fun.
I've been simulating it using my custom fields for years, but without the handy interface.
-
undefined is a third state :)
And opening the door to predefine the checked or unchecked status of an undefined box is opening the Pandora Box. KISS-->undefined would be unchecked grey...
KISS would mean that it has two states. On or off.
From a general user's point of view, there is no need for undefined to exist as a separate state. It is equivalent to the default state - which would usually be off, but in certain fields should be on instead. Hence the preference for the default state being on/off/inactive.
As before, an example of that would be iTunes' checked track behavior, where all tracks are enabled (checked) by default, and if the user unchecks them, they will not be played, nor will they be synced to mobile devices.
I thought about it, but I think it is not wise. Right click is universally a context menu (apart for lefties who invert their mouse buttons), better not touch that...
Media Center already uses a lot of non-standard controls/behaviors. It wouldn't be the first.
For example, if I drag a selection with the right-mouse button rather than the left, Media Center does not then display a context menu to let me play all those files at once. I have to right-click a second time to bring up the menu.
You could always bring up a context menu which lets you select the state if you right-click a checkbox, but that makes things more complicated. I doubt a user is likely to right-click a checkbox unintentionally.
A Voting field type IS different. It's also instantly familiar to anyone who's been on the internet for more than 30 minutes.
It's also useful. And fun.
I've been simulating it using my custom fields for years, but without the handy interface.
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.
-
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. :)
-
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:
(http://abload.de/img/voteuwk80.png) or (http://abload.de/img/vote9co7o.png)
Instead of this?
(http://abload.de/img/three5djxr.png)
Because I don't see how that is useful, and it could be defined by the skin.
-
Are you simply talking about having graphics like this:
(http://abload.de/img/voteuwk80.png) or (http://abload.de/img/vote9co7o.png)
Instead of this?
(http://abload.de/img/three5djxr.png)
Because I don't see how that is useful, and it could be defined by the skin.
I'm suggesting something like this.
(http://hotspur.us/albums/misc/voting.png)
(http://hotspur.us/albums/misc/voting2.png)
Icons and Colors aren't important. It's the functionality I'm after.
-
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.
-
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.
-
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?
-
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".
-
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.
-
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.
-
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.
-
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. ;D
-
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 (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.
(http://abload.de/img/checkrtuzj.png)
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.
-
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 ;D
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...
-
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.
-
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.
-
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.
-
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...
-
Split: To Play or Not to Play (http://yabb.jriver.com/interact/index.php?topic=92928.0)
It wasn't a clean split.
-
Thanks, Jim.
I was going to do that today.
-
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?
-
Anyone?
-
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.
-
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".
-
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.
-
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.
-
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
-
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.
-
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.
-
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.
-
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.
-
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.
-
^ ...and I thought that new Tag window was a secret! :P 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.
-
Any chance Shift could be a toggle and it will open the last used version of the Tag Window until you toggle it again?
-
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).
-
awesome, thanks Matt
i just discovered the new tag window when i read this thread. so far i think it's pretty fantastic