NXG, I am trying to love you but you are making it so difficult

[JeffP]

21 hours ago, drjdpowell said:

I think you need to give the User a choice at step 2 of what to do with the loose files.  In my case they are just deprecated VIs that never got deleted (deleting files in Current Gen is very inconvenient).  Step 3 need a choice too, as adding the shared files to one of the projects will usually be the right choice.

I agree with both your points. For your first point - we debated about how much customization should be available in the conversion wizard. We want to make you aware of any issues that you should fix up before conversion, but we didn't want to duplicate IDE functionality. For example - refactoring your architecture is easier with all the tools in the editor, so we wanted to get you through the conversion wizard quickly so you could use those tools instead of duplicating them in the wizard. This breaks down a bit in the case where we generate multiple projects.

Customization like you are describing - being able to choose specific files not to convert or which project should own a shared dependency - are improvements we liked but weren't sure how much they would be used. It is certainly something we can come back and improve later, it just hasn't been a priority yet.

[JeffP]

15 hours ago, X___ said:

Am I reading this right?

Can you elaborate on your concern?

Generally speaking - directly sharing source across multiple projects can easily lead to making changes in one project which unintentionally breaks another project. The recommendation is that if you have a piece of code that you want to reuse in multiple projects (maybe its a framework or a library) you should separate that code into its own module. The projects would then depend on the built component - a gll for example, so this enables you to maintain versioning and avoid the case I described. Alternatively you could distribute the shared component as an addon, but you would not be able to directly edit the shared dependency from the project which is dependent on it.

You are still able to directly share GVIs between different projects, we just don't recommend that you do it.

[X___]

43 minutes ago, JeffP said:

Can you elaborate on your concern?

Generally speaking - directly sharing source across multiple projects can easily lead to making changes in one project which unintentionally breaks another project. The recommendation is that if you have a piece of code that you want to reuse in multiple projects (maybe its a framework or a library) you should separate that code into its own module. The projects would then depend on the built component - a gll for example, so this enables you to maintain versioning and avoid the case I described. Alternatively you could distribute the shared component as an addon, but you would not be able to directly edit the shared dependency from the project which is dependent on it.

You are still able to directly share GVIs between different projects, we just don't recommend that you do it.

Thanks, this perfectly clarifies the matter. Nihil novi sub sole?

 

[Aristos Queue]

17 hours ago, X___ said:

Am I reading this right?

Yes. It is an excellent change from CurGen that makes source management far easier for all use cases that we have evaluated.

[X___]

3 hours ago, Aristos Queue said:

Yes. It is an excellent change from CurGen that makes source management far easier for all use cases that we have evaluated.

Then I am completely convinced that I have nothing to add to that discussion (which I guess was the purpose of this enlightening statement).

[Aristos Queue]

7 hours ago, X___ said:

Then I am completely convinced that I have nothing to add to that discussion (which I guess was the purpose of this enlightening statement).

I answered the question you were really asking, which was, “Did you idiots even think before implementing this junk?” If you had wanted an actual explanation of the feature, I’ve seen your posts often enough to know you would have asked directly. You didn’t ask that, so I didn’t answer that.  Your response to JeffP strongly suggests that I was right.

X__, it is honestly hard to tell in many of your posts whether you want an answer or just want to pick a fight. My goal is to answer customer questions about LabVIEW and its design and to learn enough to fix designs that aren’t working.  Please, if you want a more useful answer, ask a question that isn’t snark and doesn’t require Latin translation. It would make helping you a lot easier — and I mean that *even if* your question is about R&D’s general lack of forethought. 

[drjdpowell]

Tone of voice doesn't come through on the internet, X__.  You need to be more clear or start using emojis 🙂

AQ, I'm thinking about the Project changes, as I had not appreciated how significant the change is.  

[X___]

Whatever. My question was: did I understand correctly that individual VI files shared between projects were going to become hard to use. The answer was no. I then commented that in this case there was nothing new of interest, or at least I could ignore the the gll paradigm.

As for picking a fight, why would I even bother. As you know, I left NI forums after you (AQ) summoned me by private message to stop expressing critical comments. There is a difference between engaging customers and addressing their needs, which I believe is something that would benefit from some soul searching on NI's part.

As for me, I have no interest in wasting any time with NXG until I am forced to abandon CG. I hope that by then I will be sufficiently proficient using other programming environments that are open, free and supported on all platforms. 

[hooovahh]

Hi all, friendly LAVA moderator here. I'd just like to gently remind everyone we are all human, and are at times emotional, and at times frustrated with colleges we interact with.  Lets all take a deep breath and try to continue to give criticism in a form that will be most helpful.  I know I've at times flown off the handle online, especially on the subject of NXG. 

I personally don't think I've shared code between projects for anything real project anytime recently.  But I can remember times that I did it and didn't have any real problem.  Likely because I was mindful of what effected what.  X do you have some recent examples of code you shared between projects?  What made you make that decision, and why were the other options seen as less desirable?  Also it sounds like this isn't explicitly forbidden in NXG.

[LogMAN]

21 hours ago, hooovahh said:

I personally don't think I've shared code between projects for anything real project anytime recently.  But I can remember times that I did it and didn't have any real problem.  Likely because I was mindful of what effected what.

Me too. In the early days (LV 6-7 era), it was common practice for us to share code between projects. The "smarter" ones of us even had dedicated directories for reuse code. As it turned out, this move was not so smart after all...  Now we have older (and still active) projects that are missing entire LLBs, because they got lost when old computers were replaced by new ones. To this day we keep praying that nobody gets strange ideas about adding new features or (god forbid!) fix a "small bug" in those projects 😱

Nowadays (for the past ~10 years) any code is either part of the same repository or shared with packages (that are managed in their own dedicated repositories). This is one of the reasons I am very much in favor of how files are managed by NXG. Doing it manually has become a second nature, but is cumbersome and tiring at times. I would love to have that feature in CG 😍

[drjdpowell]

So... did anyone have a 1-on-1 interview with NI?  I've spent some time with NXG over the last week and made multiple comments, though in a private NI forum so I can be completely honest.  Can't tell if anyone from NI has read these comments.

[drjdpowell]

14 hours ago, LogMAN said:

Me too. In the early days (LV 6-7 era), it was common practice for us to share code between projects. The "smarter" ones of us even had dedicated directories for reuse code. As it turned out, this move was not so smart after all...  Now we have older (and still active) projects that are missing entire LLBs, because they got lost when old computers were replaced by new ones. To this day we keep praying that nobody gets strange ideas about adding new features or (god forbid!) fix a "small bug" in those projects 😱

Nowadays (for the past ~10 years) any code is either part of the same repository or shared with packages (that are managed in their own dedicated repositories). This is one of the reasons I am very much in favor of how files are managed by NXG. Doing it manually has become a second nature, but is cumbersome and tiring at times. I would love to have that feature in CG 😍

That's more of a Source-Code-Control issue than multiple LabVIEW projects using common code.  I have clients where there are multiple projects using common code, but all code is under a single repo.

I'm not sure yet about NXG changes here.  I have basically two types of reuse.  VIPM packages developed usually on an earlier LabVIEW version and used across many projects at many customers (with the main ones being on the Tools Network), and customer common code shared by different sub-projects for a single customer.

[Neil Pate]

3 hours ago, drjdpowell said:

So... did anyone have a 1-on-1 interview with NI?  I've spent some time with NXG over the last week and made multiple comments, though in a private NI forum so I can be completely honest.  Can't tell if anyone from NI has read these comments.

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...

[LogMAN]

2 hours ago, drjdpowell said:

That's more of a Source-Code-Control issue than multiple LabVIEW projects using common code. I have clients where there are multiple projects using common code, but all code is under a single repo.

I never said there was an issue with using common code between projects. In fact, it makes no difference. Just to give you an idea of what I'm talking about, one of our old repositories has more than 200 individual projects in a single folder with a few hundred VIs and LLBs, most of which share code between each other! It is absolutely mental.

My point is, our projects shouldn't have been structured that way in the first place and NXG makes it so much easier not to make the same mistake.

3 hours ago, drjdpowell said:

I'm not sure yet about NXG changes here.  I have basically two types of reuse.  VIPM packages developed usually on an earlier LabVIEW version and used across many projects at many customers (with the main ones being on the Tools Network), and customer common code shared by different sub-projects for a single customer.

I wonder how NXG handles nested projects...

[hooovahh]

4 hours ago, drjdpowell said:

So... did anyone have a 1-on-1 interview with NI? 

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.

[DTaylor]

My biggest disappointment is how sluggish it is compared to 20xx, though it has improved since the initial release. Loading an empty project takes 3x as long in NXG for me.

I do like the single window environment.

[drjdpowell]

I've pointed out the sluggishness.  It's actually the slowness of opening front panels and block diagrams and in opening right-click menus that is a bigger problem, IMO.

Edited June 10, 2020 by drjdpowell

[Neil Pate]

37 minutes ago, drjdpowell said:

I've pointed out the sluggishness.  It's actually the slowness of opening from panels and block diagrams and in opening right-click menus that is a bigger problem, IMO.

The whole IDE is unacceptably sluggish. Doing any kind of block diagram create/remove space feels terrible. Everything just takes a few hundred ms to a second longer than it ought to. Tearing out tabs into new windows feels so heavy.

When I start NXG now from fresh I get a total system freeze where I cannot even interact with the OS for about 30 s. It does not happen on subsequent openings but is still quite disconcerting.

[MikaelH]

7 hours ago, Neil Pate said:

When I start NXG now from fresh I get a total system freeze where I cannot even interact with the OS for about 30 s

Same here. It locked the whole OS for some reason when I start NXG.

[Mads]

We might as well loop back to 2017 😉

[Dataflow_G]

4 hours ago, Mads said:

We might as well loop back to 2017 😉

The very first comment in that thread is interesting.

Quote

I just downloaded and installed LabVIEW NXG.  At first I thought I installed LEGO NXT by mistake...

It's no coincidence NXG looks like LEGO Mindstorms NXT. There was an R&D project in 2009 called LabVIEW Notebook Pioneer. You can see it here - video 1, video 2 and a screen cap:

It looks like a very early NXG concept (single window, panes, docked palettes, data stored with project, etc). What's interesting is Christina's comment in the linked blog post.

     

It would seem NXG's roots were partly influenced by NXT. Not saying it's good or bad, just interesting that it was picked up on.

[dadreamer]

9 hours ago, Dataflow_G said:

There was an R&D project in 2009 called LabVIEW Notebook Pioneer.

There was even a (very) short thread on LAVA:

By the way I always wanted to try, but I was a bit late to it, so never seen any files to download and play around freely. Does anyone still have it on their hands? Or does it require a special licensing and thereby unavailable?

[hooovahh]

Also around this era was the Web UI Builder which has other elements now seen in NXG.

[X___]

And StarLogo TNG (The Next Generation)... the ancestor of MIT's App Inventor. After all, NXG is supposed to be so simple that everyone can use it, right?

 

[PiDi]

After starting NXG 5.0.0 and traditional hang of the whole OS for 3 minutes, LabVIEW forgot how to write text on the screen

 

Ok, not only LabVIEW, other apps too...

 

They used to have a name software that caused weird system behaviour: a virus...