Leaderboard

I too had one. The day of the meeting I installed NXG and went though all the old issues I had with it years ago and tried evaluating what things have changed and what ones haven't. I made a bunch of notes on things and mentioned them in the meeting. I then have started formalizing these lists and have been giving feedback to NI, most of the time linking back to where the complaints were first mentioned.

Ok, here's what I did: I found a lvlibp file in my LV14 installation, and extracted it: $ file lv_icon.lvlibp lv_icon.lvlibp: PE32 executable (DLL) (GUI) Intel 80386, for MS Windows $ wrestool -x --raw lv_icon.lvlibp -o ./ $ ls -l lv_icon* -rwxr-xr-x 1 mefisto None 5377536 2014-06-25 lv_icon.lvlibp -rw-r--r-- 1 mefisto None 5375712 06-10 12:47 lv_icon.lvlibp_10_2_0 -rw-r--r-- 1 mefisto None 704 06-10 12:47 lv_icon.lvlibp_16_1 Then checked the RSRC file from inside: $ file lv_icon.lvlibp_10_2_0 lv_icon.lvlibp_10_2_0: National Instruments, $ ./readRSRC.py -x -i 'lv_icon.lvlibp' Error: [Errno RSRC {:d} Header sanity check failed.] 0 So, I never tried that before, and my tool doesn't currently support these files. But it should be an easy fix, so I will patch it and get back to you with more info. For fixing 'tampered with password' message - what I do is just removing the file from library when in extracted form (can't remember exactly, but I think 3 changes are required, one of them is removal of the LIBN which you mentioned). Btw, NI is inconsistent here - they say the password is just 'unintended modification' avoidance, but the 'tampered' message suggests the intent for creating that functionality was to provide some impression of security. EDIT: Fixed it! Now I'm getting: $ ./readRSRC.py -vv -x -i 'lv_icon.lvlibp_10_2_0' lv_icon.lvlibp_10_2_0: Starting file parse for RSRC extraction lv_icon.lvlibp_10_2_0: Block 'LVzp' index 0 recognized lv_icon.lvlibp_10_2_0: Block b'LVzp' max data size set to 5273600 bytes lv_icon.lvlibp_10_2_0: Block b'DATA' max data size set to 5375472 bytes lv_icon.lvlibp_10_2_0: Writing block b'LVzp' lv_icon.lvlibp_10_2_0: Storing block b'LVzp' section 0 binary in 'lv_icon_LVzp.bin' lv_icon.lvlibp_10_2_0: Writing block b'DATA' lv_icon.lvlibp_10_2_0: Storing block b'DATA' section 0 binary in 'lv_icon_DATA0.bin' lv_icon.lvlibp_10_2_0: Storing block b'DATA' section 1 binary in 'lv_icon_DATA1.bin' lv_icon.lvlibp_10_2_0: Storing block b'DATA' section 2 binary in 'lv_icon_DATA2.bin' lv_icon.lvlibp_10_2_0: Storing block b'DATA' section 3 binary in 'lv_icon_DATA3.bin' lv_icon.lvlibp_10_2_0: Storing block b'DATA' section 4 binary in 'lv_icon_DATA4.bin' lv_icon.xml: Writing binding XML The ZIP is auto-decrypted, so we can now extract it: $ file lv_icon_LVzp.bin lv_icon_LVzp.bin: Zip archive data, at least v2.0 to extract # unzip lv_icon_LVzp.bin Archive: lv_icon_LVzp.bin extracting: NI_Embedded_Library.xml extracting: 1abvi3w/resource/dialog/lvconfig.llb/LV Config Read Boolean.vi extracting: 1abvi3w/resource/dialog/lvconfig.llb/LV Config Read Color.vi extracting: 1abvi3w/resource/dialog/lvconfig.llb/LV Config Read String.vi extracting: 1abvi3w/resource/dialog/lvconfig.llb/LV Config Write Boolean.vi extracting: 1abvi3w/resource/dialog/lvconfig.llb/LV Config Write Color.vi extracting: 1abvi3w/resource/dialog/lvconfig.llb/LV Config Write String.vi [...] Will update after I look at the files I got. EDIT2: Looked at the files: The only real issue is lack of VCTP section. The rest of removing the VI from library is trivial, if you check how the file looks before and after compiling the library. VCTP sections from all files seem to be merged together (after all it stands for VI Consolidated Types), and stored in DATA resource of index 0. That resource is then compressed with ZLIB. Looks like DATA0 is zlib'ed, while DATA1+ are not. I will have to update the tools to handle a situation where the same resource ID has compressed and uncompressed sections. ps. If anyone wonders about the strange shortcuts we're using, I've made a wiki page on this: https://labviewwiki.org/wiki/Resource_Container

The MDI/tabbed interface solution for VIs seems to be one of the most fundamental flaws of NXG GUI. One of the biggest strengths of LabVIEW CG is that it enables and encourages continuous testing. You can have the user interface of your VIS (the whole application you are building for that matter) *on screen*, shown as it will be when built, not as a page within an MDI interface) and provide input to it and view the output - while you at the same time view and change the code of various VIs...tweak, run (as soon as the code is not broken), input, view output, tweak, run...etc. Just the idea that it is OK to require the developer to manually tab between the front panel and the code is ridiculous. It is scary how they can think that's a good change in the work flow, but then again - the text programmers are not used to much of what is (was) great in LabVIEW so that might explain why such things seem expendable. Now you can say that there are ways around this , or that it can be *fixed* in future versions of NXG - but the problem with that is that it would also require a complete redesign of the rest of NXG. There is too much stuff in NXG relying on it. Do not get me wrong here - I would love it if someone told me wrong and showed me the NXG light. Where are all the NXG evangelists? What do the Knights of NI for example really think about NXG and the road ahead? Are they worried or even angry too, or do they think this is the best thing since sliced bread?

Yes James, I had one with Jeff and one of the dev team from India last week. We had a nice candid chat. He clarified the position that NXG is not really intended for advanced users at this stage. One of the problems is that NI is now such a vast organisation and everyone is clawing their way up the corporate food chain so there is no real consistency. The issues with the software is always because of the other guy who was in the position previously (my words, not Jeffs). Rinse repeat and now we are 8 years in with a GUI that looked dated three years ago and a UX paradigm that should never have made it out of wireframe design. Sad times indeed. The juggernaut that is NXG cannot be stopped or even steered at this point it would seem. Almost every single person who has used NXG has said how ugly and drab it looks, but because this goes against NI's "data" our opinions will be ignored. I will revisit it next year...