Jump to content

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


Recommended Posts

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.

Link to comment
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.

Link to comment
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?

 

Link to comment
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).

Link to comment
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. 

Link to comment

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. 

Link to comment
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 😍

Link to comment
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.

Link to comment
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...

  • Sad 4
Link to comment
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...

Link to comment
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.

  • Like 1
Link to comment
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.

  • Like 1
Link to comment
4 hours ago, Mads said:

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:

LVNotebookPioneer.png.9401cc1a025443580df37e71964d3788.png

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.

      nxt_comment.PNG.36c60361cdf380d5a13c0551245e3199.PNG

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.

Link to comment
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?

Link to comment
  • 2 months later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.