Jim Kring Posted October 8, 2011 Report Share Posted October 8, 2011 I know it's only been about 5 minutes since the OpenG MD5 Library version 4.1.0.8 was released, but I was so excited that I had to try it out and wanted to make a couple suggestions to continue this wave of improvement Place Hexadecimal MD5 instance by default When the MD5 Message Digest is dropped from the palette, the Binary MD5 instance is placed, since this is the top-most instance of the Poly VI. I'm not sure if this is by design. I expected that Hexadecimal MD5 is more commonly used and that this should be the default instance when dropped. Use Instance VI Icons to distinguish instances There is currently no difference between the Hexadecimal MD5 and Binary MD5 instance VIs. One can only tell the difference if the Polymorphic VI Selector is visible and many people like to hide that, since it takes up a lot of space. If the Use Instance VI Icons option were enabled and the two instances' icons were different (to reflect the output MD5 encoding), then it would be really helpful. Quote Link to comment
jgcode Posted October 8, 2011 Report Share Posted October 8, 2011 Thanks for the feedback Jim. Place Hexadecimal MD5 instance by default When the MD5 Message Digest is dropped from the palette, the Binary MD5 instance is placed, since this is the top-most instance of the Poly VI. I'm not sure if this is by design. I expected that Hexadecimal MD5 is more commonly used and that this should be the default instance when dropped. This was a design decision based on backward compatibility. In polymorhizing the API, anyone's code calling the original MD5 Message Digest (Binary) will not be broken, as it will default to the top of the polymorphic list (Binary) given the connector pane of the two VIs (Binary and Hexadecimal) matches (which is normally not the case). Its was very important to maintain this with this change (although I agree Hexidecimal will be more popular). Use Instance VI Icons to distinguish instances There is currently no difference between the Hexadecimal MD5 and Binary MD5 instance VIs. One can only tell the difference if the Polymorphic VI Selector is visible and many people like to hide that, since it takes up a lot of space. If the Use Instance VI Icons option were enabled and the two instances' icons were different (to reflect the output MD5 encoding), then it would be really helpful. This was requested in the review that the icons be of polymorphic instance. Other API's use the selector by default e.g. DAQmx. You should have chimed in at the review But if it is causing an issue, it can definitely be changed. Quote Link to comment
asbo Posted October 8, 2011 Report Share Posted October 8, 2011 Thanks for the feedback Jim. This was a design decision based on backward compatibility. In polymorhizing the API, anyone's code calling the original MD5 Message Digest (Binary) will not be broken, as it will default to the top of the polymorphic list (Binary) given the connector pane of the two VIs (Binary and Hexadecimal) matches (which is normally not the case). Its was very important to maintain this with this change (although I agree Hexidecimal will be more popular). This was requested in the review that the icons be of polymorphic instance. Other API's use the selector by default e.g. DAQmx. You should have chimed in at the review Oops, I missed Ton's message too. I'm with Jim on this one, there's a lot of icon real estate that's unused, so I think it makes sense to use the polymorphic instance icons. I don't think it will "cause issues" per se, but it's painless and if it will save some organization grief down the road, why not? WRT DAQmx, typically the icons are already pretty busy, and it would be difficult to convey the multitude of choices adequately in the icon (DAQmx Read, for example). Just my two cents. Quote Link to comment
jgcode Posted October 8, 2011 Report Share Posted October 8, 2011 Oops, I missed Ton's message too. I'm with Jim on this one, there's a lot of icon real estate that's unused, so I think it makes sense to use the polymorphic instance icons. I don't think it will "cause issues" per se, but it's painless and if it will save some organization grief down the road, why not? WRT DAQmx, typically the icons are already pretty busy, and it would be difficult to convey the multitude of choices adequately in the icon (DAQmx Read, for example). Just my two cents. I gots no dramas with it given: It's not a functional change If is the more popular way to go etc... That building and releasing packages is so painless in VIPM 2011 I am happy to do it now. That is what the fix version number was made for So I just need the following two questions answered: Are you happy with the current VI icons (they are do exist in the released package they are just not shown)? Do you want the poly selector on by default still (personally, I don't see the point anymore if we do the above)? Quote Link to comment
Jim Kring Posted October 9, 2011 Author Report Share Posted October 9, 2011 1. Are you happy with the current VI icons (they are do exist in the released package they are just not shown)? I'm not in love with the current icon, but there really isn't any sexy way of saying "MD5 DIGEST" 2. Do you want the poly selector on by default still (personally, I don't see the point anymore if we do the above)? Yes, I think we should keep the Poly Selector, because the poly instances change between string encoding, not data type. This means: 1) You can't change between implementations by wiring up different input data types. 2) there's really no other good way (besides the Poly Selector) to convey to users that it's a poly VI with other implementations and let them choose between the different implementations. Quote Link to comment
jgcode Posted October 9, 2011 Report Share Posted October 9, 2011 I'm not in love with the current icon, but there really isn't any sexy way of saying "MD5 DIGEST" Should we call in vugie? Quote Link to comment
Jim Kring Posted October 9, 2011 Author Report Share Posted October 9, 2011 Should we call in vugie? I don't see anything wrong with having well-designed icons for OpenG VIs, as long as they all look consistent -- right now I think that the font of "MD5" doesn't really fit with the icon designs of other OpenG VIs. Quote Link to comment
jgcode Posted October 9, 2011 Report Share Posted October 9, 2011 I don't see anything wrong with having well-designed icons for OpenG VIs, as long as they all look consistent -- right now I think that the font of "MD5" doesn't really fit with the icon designs of other OpenG VIs. FWIW, I didn't change that one - it has been there before my time I just added the Binary and Hex down the bottom. We can update them in a future release if anyone wants to contribute sexier ones I was also thinking that if we move to .lvlibs (?) in the future, we could utilise the banner feature in certain situations (Modules/APIs etc...) 1 Quote Link to comment
Jim Kring Posted October 9, 2011 Author Report Share Posted October 9, 2011 FWIW, I didn't change that one - it has been there before my time Ya, I wasn't blaming you 1 Quote Link to comment
jgcode Posted October 11, 2011 Report Share Posted October 11, 2011 The Message Digest Polymorphic VI should show instance icons item can be tracked here: ID 3421698 Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.