Jump to content

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


Recommended Posts

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. 

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

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

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

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

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

  • Like 1
Link to comment

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

This:

image.png.09bb5e87f4af4a79270d25ef6277d8ac.png

 

Got turned into this:

image.png.98bcd6ee0a363543703a24e53b39828c.png

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 by Neil Pate
Link to comment
1 hour ago, Neil Pate said:

Got turned into this:

image.png.98bcd6ee0a363543703a24e53b39828c.png

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

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

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

Link to comment

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.

image.png.3acd23adcd071aa733ab678af1d3b1e5.png

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

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

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

image.png.3acd23adcd071aa733ab678af1d3b1e5.png

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.

Link to comment
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 by LogMAN
Link to comment

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

Link to comment

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.

Link to comment

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

 

  • Like 2
Link to comment

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.