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

[Aristos Queue]

21 hours ago, Neil Pate said:

Also, as a leftie my right hand hovers on the arrow keys when programming, so nowhere near the left hand side of the keyboard.

Darren has acknowledged he is not the right person to develop a left-hand set of shortcuts. If you put together a list of shortcuts for yourself that work better for left hand, contact him... he's happy to promote them. You can swap out the QD shortcuts if you have a better set. 

[Aristos Queue]

On 5/2/2020 at 2:47 PM, Neil Pate said:

Why is a feature like this removed? Sure, it is not a great thing to use this to actually run my application, but why removed it? Hide it away somewhere if you are worried it is going to be abused.

It wasn't removed from NXG. It has not yet been added. There are a sizable number of customers who lobby LV 20xx to remove it entirely, and others who want it left just as prominent as it is today. You can see one place where that discussion has been playing out: https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Hide-Run-Continuously-by-default/idi-p/1521886

NXG hasn't decided how to handle it yet, so they haven't added it. It's in the ToDo backlog to add it somewhere.

[Aristos Queue]

On 5/2/2020 at 9:05 AM, pawhan11 said:

 If they deliver more fundamental things that are pain in CG like problems with relative build paths, unicode, sealed classes, packed libraries linkage, building of multiple layers of libraries without killing labview, out of the box support for source control systems & diff/merge operations... 

Of your six items, NXG addresses three of them and has improved support for a fourth. The source code control stuff is still in flight -- not sure when the target is for delivery [again, not my department]. Sealed classes is so far down the priority list, it's not even in the backlog I bet. I couldn't get traction for that in LV20xx. 

[Neil Pate]

11 minutes ago, Aristos Queue said:

Darren has acknowledged he is not the right person to develop a left-hand set of shortcuts. If you put together a list of shortcuts for yourself that work better for left hand, contact him... he's happy to promote them. You can swap out the QD shortcuts if you have a better set. 

NXG actually seems quite good at figuring out what I am looking for with quick drop; I just type the name of the primitive and it appears. This is good as I cannot identify anything because the new icons all look totally weird to me...  

[mcduff]

4 hours ago, Aristos Queue said:

Of your six items, NXG addresses three of them and has improved support for a fourth. The source code control stuff is still in flight -- not sure when the target is for delivery [again, not my department]. Sealed classes is so far down the priority list, it's not even in the backlog I bet. I couldn't get traction for that in LV20xx. 

@Aristos Queue

I haven't used NXG yet, but I heard that a future feature was the ability to drop other code snippets in the the block diagram. For example, I heard that it would be possible to drop some C code, Matlab "script" code, or python code directly in the block diagram.

Is that still going to be a feature?

Cheers,

mcduff

[ShaunR]

8 hours ago, Aristos Queue said:

It wasn't removed from NXG. It has not yet been added. There are a sizable number of customers who lobby LV 20xx to remove it entirely, and others who want it left just as prominent as it is today. You can see one place where that discussion has been playing out: https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Hide-Run-Continuously-by-default/idi-p/1521886

NXG hasn't decided how to handle it yet, so they haven't added it. It's in the ToDo backlog to add it somewhere.

Just make it an ini/preference setting. The main tenor of that thread seems to be "I'm not very precise so please remove it" which, from that low point, then devolves into "my work-flow is better than your work-flow".

Edited May 5, 2020 by ShaunR

[Michael Aivaliotis]

4 hours ago, ShaunR said:

Just make it an ini/preference setting. The main tenor of that thread seems to be "I'm not very precise so please remove it" which, from that low point, then devolves into "my work-flow is better than your work-flow".

I can live without it. On the level of priorities for NXG, this has to be the least important. Just drop the vi on the diagram and wrap a while loop.

[Neil Pate]

1 hour ago, Michael Aivaliotis said:

I can live without it. On the level of priorities for NXG, this has to be the least important. Just drop the vi on the diagram and wrap a while loop.

It is so interesting how everyone uses LabVIEW differently.

For me, the ability to stop a running application and still have the Front Panel of a particular sub VI open and then, without doing any more work, run it continuously and allow me to debug is so valuable.

[ShaunR]

On 5/5/2020 at 7:55 AM, Michael Aivaliotis said:

I can live without it. On the level of priorities for NXG, this has to be the least important. Just drop the vi on the diagram and wrap a while loop.

Your argument is inconsistent. If it's not a priority then making a change to remove it is allocating resource to "the least important". Leaving it in would be the least impactful. However. If you are going to change it then you might as well make it a "Preference" since that is clearly what it is. You don't seem to have a preference or, at least, are indifferent. So why advocate taking away a feature that other people obviously feel strongly about?

Edited May 6, 2020 by ShaunR

[Neil Pate]

My experiment with NXG is now over. A simple web page has taken about 5x longer than I had planned for. Some of this is due to me underestimating the nuances of the web module but most of it has been me fighting the new IDE. The other night instead of happily diving into some after dinner software development fun I was actually filled with dread at the thought of having to open NXG and finish what I started, it really is that unpleasant to use.

For me, NXG is nowhere near usable in a real project that I expect to have to develop, maintain and make money off. Some stuff seems to work, but everything has this toy feel about it. It is ugly, sluggish, unintuitive and absolutely repulsive to develop with. Sorry that sounds harsh, but it has been in development for over 8 years and has an incredibly strong pedigree to compare against. NI have taken almost everything that made current gen so special and thrown it in the bin. NXG is clearly being managed and developed by people who have never actually become intimately familiar with LabVIEW.

I will check back in a few years time but at this point I am extremely disappointed and now need to think very strongly about where my professional systems development career is going. Current Gen is going to be sunsetted at some point and will fade into irrelevance due to its closed source nature (not that open sourcing something of its complexity would help now, it is too late for that). I could wait a few years if I had confidence that the ship was sailing in the right direction, but apart from AQ who consistently has the courage to actually even reply to these threads there is virtually nothing coming back from NI and I feel that the HMS NXG-itanic is sailing full steam ahead towards its doom.

NI is run by extremely clever people who have no doubt done their sums and analyses and are charting the course for NXG that they think will bring them the most success in the long-run. I have a strong appreciation for just how big an undertaking something like NXG is, but given where it is after 8 years of development it just seems that I am not the target market and there is not too much I can do about it.

Happily, given how robust NI hardware and current gen LabVIEW actually are I suspect there will be quite a bit of work supporting old systems for at least another decade (perhaps more).

 

 

Edited May 6, 2020 by Neil Pate

[Neil Pate]

Just for fun I tried the code conversion utility on a 2019 project I am working on.

This:

 

Got turned into this:

Yeah, that is a no then... Totally ignoring the 1300 things I have to attend to manually just look at the project tree. Urgh....

Edited May 6, 2020 by Neil Pate

[X___]

The IDE was in fact pretty much here when NI launched LabVIEW Web UI: https://www.youtube.com/watch?v=RiY35znIdUg which used Microsoft Silverlight. Since that must have been in the making for several years before it was released, this is more like 10+ years old. Does the IDE look 10 years old or older?

The fact that pretty much every traditional LV developer feels horrible pain at the mere look of the IDE is saying either we are all hopelessly outdated or indeed the IDE is a step backwards in terms of nimbleness (agility?). The IDE should be modular, since the underlying code itself is not. In fact, it should be open, offering the ability to third party developers to hook their tools and customization.

I am not particularly depressed anymore at the unfolding of this slow motion catastrophe, and in fact I am even willing to believe NI that indeed there is a new crop of developers who are going to prove us all wrong. But right now, this is not the direction we (academia) are going. We want openness (for reproducibility purposes), we want flexibility, customizability, and we are certainly not going to have our users pay runtime licenses for toolkits simply implementing public domain algorithms.

I am still much more efficient at programming in LV, but there is zero incentive for me to choose NXG over Python at this point, based on my 25 years of dealing with NI.

[ShaunR]

1 hour ago, Neil Pate said:

Got turned into this:

Yeah, that is a no then... Totally ignoring the 1300 things I have to attend to manually just look at the project tree. Urgh....

it clearly states that LV 2015 isn't supported and says to forward save it to 2017. It's not really a useful test for it's conversion capabilities.

Edited May 6, 2020 by ShaunR

[Neil Pate]

Just now, ShaunR said:

it clearly states that LV 2015 isn't supported and says to forward save it to 217. It's not really a useful test for it's conversion capabilities.

You did not read my post. This is a LabVIEW 2019 project. Yet somehow NXG is not smart enough to know this.

[ShaunR]

2 minutes ago, Neil Pate said:

You did not read my post. This is a LabVIEW 2019 project. Yet somehow NXG is not smart enough to know this.

Oh. Sorry. Missed that bit. That's a different kettle of kippers then.

[drjdpowell]

I think LabVIEW CG doesn't automatically resave files, when opened in new versions, anymore, so that may be the reason.

[Neil Pate]

1 minute ago, drjdpowell said:

I think LabVIEW CG doesn't automatically resave files, when opened in new versions, anymore, so that may be the reason.

Fair point. I will do a mass compile and re-run the experiment. (Sorry ShaunR, I guess you were also right)

[JKSH]

2 hours ago, drjdpowell said:

I think LabVIEW CG doesn't automatically resave files, when opened in new versions, anymore

I think that's because @Neil Pate was doing the Right Thing™ by enabling "Separate Compiled Code from Source".

Unseparated VIs will ask to be re-saved if opened in a newer version.

[Neil Pate]

In order to resize an array you have to click on the tiny dot in the middle of the drag handle that only appears if your mouse is leaving the control and is some weird distance way from the border.

In other words, in this picture in order to get the resize drag handle to appear I have to move my mouse over the control, then out a little bit into the middle of space with no visual indication how far out to move it until the horizontal bar appears and then find the tiny dot in the middle and then drag that. 🤮

How could this UX make it through 8 years of development?

2020-05-07 22-49-46.mkv

[Michael Aivaliotis]

On 5/6/2020 at 2:43 AM, ShaunR said:

Your argument is inconsistent. If it's not a priority then making a change to remove it is allocating resource to "the least important". Leaving it in would be the least impactful. However. If you are going to change it then you might as well make it a "Preference" since that is clearly what it is. You don't seem to have a preference or, at least, are indifferent. So why advocate taking away a feature that other people obviously feel strongly about?

Inconsistent to a post i made 10 years ago? Besides, that was related to CG. I'm not advocating for removing an engrained CG feature. I thought we were discussing NXG. My assumption is this feature hasn't even beed implemented in NXG. There is a lot more work required in NXG to make it even barely usable. Lack of continuous run is not a problem in NXG. Lack of everything, is a problem.

[Michael Aivaliotis]

5 hours ago, Neil Pate said:

In order to resize an array you have to click on the tiny dot in the middle of the drag handle that only appears if your mouse is leaving the control and is some weird distance way from the border.

In other words, in this picture in order to get the resize drag handle to appear I have to move my mouse over the control, then out a little bit into the middle of space with no visual indication how far out to move it until the horizontal bar appears and then find the tiny dot in the middle and then drag that. 🤮

How could this UX make it through 8 years of development?

2020-05-07 22-49-46.mkv 3.22 MB · 3 downloads

i watched the video. Yikes, ya, that's pure garbage.

[LogMAN]

11 hours ago, Neil Pate said:

In other words, in this picture in order to get the resize drag handle to appear I have to move my mouse over the control, then out a little bit into the middle of space with no visual indication how far out to move it until the horizontal bar appears and then find the tiny dot in the middle and then drag that. 🤮

It works slightly better if you select the control first (the dots stay visible). Still, poor design choice. They actually don't work well on different zoom levels.

Edit: How do you attach videos but not display them into a post (does it automatically for me)? This thing is freaking huge...

Edited May 8, 2020 by LogMAN

[drjdpowell]

Actually, I like the new Array sizing where the bottom edge is not the bottom of the array.   in current gen, the fact that an array has a "coarse" sizing causes issues when the arrays are set to scale with the pane size.  After several resizes the accumulated round-off errors build up and the array can be very out of sync with the panel size.   Having a size that isn't forced to be an integer multiple of element size means that that scaling will work much better.   Once, that is, they actually have panel scaling and splitterbars and the like in NXG (I could not identify any such in 5.0).

[Jordan Kuehn]

To be fair, CG has so many oddities regarding where you need to place the mouse to get Auto-tool to work correctly as well. For most of us they are second nature, but at times when I'm coding in front of someone I suddenly realize how ridiculous (and intricate) some of the mouse work is. I also notice when having to code over a remote connection and there is even a tiny lag on the mouse.

[X___]

Dug up from the info-labview mailing list... on April 1, 2011 (can't make this up):

Quote

> Without hijacking the discussion, I wanted to jump in and make a couple of
> points in response to Vito's comment on Silverlight. Despite recent
> (mis)statements by a (former) Microsoft executive, Microsoft is not
> abandoning Silverlight. In fact, Microsoft is investing heavily in this
> technology, but also recognizes that it can't ignore HTML5. In the end,
> Microsoft will support both and let developers decide which to use given
> their different strengths and weaknesses.
>
> With respect to HTML, this "standard" technology is still (will likely
> remain) a moving target. HTML support is is implemented differently in
> every browser and across versions of the same browser from the same
> vendor. One of the key advantages of Silverlight is that an application's
> user interface will be consistent on every platform where it is viewed.
> However, the fact that Web UI Builder currently outputs Silverlight
> applications doesn't mean that NI does not have an interest in HTML or
> that long-term NI wouldn't support generating HTML code. We just released
> the very first version of Web UI Builder and anticipate that we will be
> adding features to it for years and years to come.
>
> Best regards,
>
> Mike Neal
> Senior LabVIEW Product Manager

Keep in mind that at the time of its disappearance (at least from public eyes), LabVIEW Web UI was in par with ~ LabVIEW 3.1 (no undo, no event structure, etc. for instance).

It would be very instructive, from an historical perspective, to have an insider's view of NI's development plans at the time (2011 and before) and how this unfolded up to now, with this bizarre "perpetual alpha" release strategy of a development product supposed to replace a flagship product, which itself is not officially discontinued, but in practice will have little bug fixes or added features. In fact, from a sociological perspective, it would be interesting to have an idea of who is leading this effort, as I have a hard time admitting that NI can find enthusiastic young developers working on somethings that is so painfully uncool.

Somewhat premonitorily, the same newsletter contained these two links (found on the Wayback machine):

https://web.archive.org/web/20100406005233/http://www.ni.com/news/releases/april0701.htm

https://web.archive.org/web/20110402173747/http://www.ni.com/news/releases/april1101.htm

You can 't help but wonder what will pop up when the next time capsule will be opened in 2036...