Animated GIF speed

[ensegre]

10 hours ago, hooovahh said:

I'd prefer a method that you give the path to a gif and it takes care of the rest,

An animated gif is of course a convenient compact container, I was thinking too, but a suitable custom format could be devised to the same extent, if one really decides to pursue this path. For instance, a zip containing the pngs and playlist information, or timing encoded into the png filenames.

I also remarked that some animated gifs contain incremental (like e.g the one in Steen's), not full frames (like in bbean's above), but I guess that could be appropriately taken care of too, at worst converting them to full independent frames. A matter of effort for the purpose. What I wonder is if it is worth to concoct some kind of Xcontrol out of the idea, in order to get a configurable animated button, hiding the additional event loop.

[ShaunR]

On 10/01/2017 at 9:23 AM, Steen Schmidt said:

Ok, not going to happen. I try to use http://ezgif.com/maker, which is a great site for making and editing animated images, but LabVIEW just gives me this on the created files:

LabVIEW ignores frame rates less than 1 second (greater is OK) and doesn't support extension blocks.

[Steen Schmidt]

Wow, this is frightening to look at from the outside:

All I wanted was for LabVIEW to play my animated gif correctly, a feature it's supposed to have built in.

That didn't work with my gif (nor Michael's it seems), and no sensible error message comes out of LabVIEW.

And now you guys are discussing embedding web browsers in ActiveX containers, and programming a gif decoder and playback feature manually, the latter even as an XControl. And all that with a straight face.

We're so used to LabVIEW falling short and us solving simple shortcomings with days of programming, that we can't see the joke here.

Over the last 24 hours I've come across two other simple things LabVIEW should be able to do in 10 seconds, but each will end up taking 5-10 hours of programming to get done: 1) Being able to drop a file from the explorer onto a control and get that event in the event structure, and 2) Enabling any control and even the front panel to drag the entire window (as you would be able to do with the title bar). Every small step is really a huge leap with this tool...

[ShaunR]

58 minutes ago, Steen Schmidt said:

Wow, this is frightening to look at from the outside:

All I wanted was for LabVIEW to play my animated gif correctly, a feature it's supposed to have built in.

That didn't work with my gif (nor Michael's it seems), and no sensible error message comes out of LabVIEW.

And now you guys are discussing embedding web browsers in ActiveX containers, and programming a gif decoder and playback feature manually, the latter even as an XControl. And all that with a straight face.

We're so used to LabVIEW falling short and us solving simple shortcomings with days of programming, that we can't see the joke here.

Over the last 24 hours I've come across two other simple things LabVIEW should be able to do in 10 seconds, but each will end up taking 5-10 hours of programming to get done: 1) Being able to drop a file from the explorer onto a control and get that event in the event structure, and 2) Enabling any control and even the front panel to drag the entire window (as you would be able to do with the title bar). Every small step is really a huge leap with this tool...

Do all your UI in a web browser and just let LabVIEW be a back-end. I switched a couple of years ago and all LabVIEWs UI problems are moot now. I've even been experimenting with "Rainmeter" to break out of the browser frame and utilise the desktop-works great!

[hooovahh]

2 hours ago, Steen Schmidt said:

And now you guys are discussing embedding web browsers in ActiveX containers, and programming a gif decoder and playback feature manually, the latter even as an XControl. And all that with a straight face.

We're so used to LabVIEW falling short and us solving simple shortcomings with days of programming, that we can't see the joke here.

Sorry if I came off as too defendant of LabVIEW, I didn't mean to post these solutions as ways of saying "See LabVIEW can do it, you just need to work harder."  It was meant to say "Here is a solution".  Often times on the forums a user will post a question and I'd like to find a solution, to get discussions going so others can also post their solutions which are often times better than the first ones I came up with.  Not supporting gifs with varying timing, longer than 1s delays, and extension blocks feels short of being able to say LabVIEW supports gifs.  Having LabVIEW support PNGs without alpha layer transparencies is a similar shortcoming that I've found work arounds for.  But again it doesn't mean I'm happy about it.

The dragging files to a control from explorer has similar work arounds that I'm sure you've found involving transparent and hidden path controls, floating on top of the control which will have value change events when dropped.

These are incomplete features of LabVIEW and I agree NI should fix them.

[G-CODE]

4 hours ago, ShaunR said:

Do all your UI in a web browser and just let LabVIEW be a back-end. I switched a couple of years ago and all LabVIEWs UI problems are moot now.

Shaun, would you be willing to elaborate on your process for doing this? Has this already been discussed and do I just need to be pointed to those discussions? I find this interesting, but it also seems like it would pose its own challenges. To do this it makes you a LabVIEW/front end web developer, right? Do you have a preferred JavaScript framework? Do you run into issues where browser updates break your UI? It seems like it would slow down development time so it might be a hindrance on customer projects that have aggressive delivery timelines.

I probably shouldn't hijack this thread. If you'd be willing to discuss your methodology, I could start a new discussion.

Eric

[Steen Schmidt]

7 minutes ago, planet581g said:

Shaun, would you be willing to elaborate on your process for doing this? Has this already been discussed and do I just need to be pointed to those discussions? I find this interesting, but it also seems like it would pose its own challenges. To do this it makes you a LabVIEW/front end web developer, right? Do you have a preferred JavaScript framework? Do you run into issues where browser updates break your UI? It seems like it would slow down development time so it might be a hindrance on customer projects that have aggressive delivery timelines.

I probably shouldn't hijack this thread. If you'd be willing to discuss your methodology, I could start a new discussion.

Eric

I'm interested as well, I think we've come to the end regarding gifs anyway, haven't we? But for future searchability we could start a new thread...

[Steen Schmidt]

4 hours ago, hooovahh said:

Sorry if I came off as too defendant of LabVIEW, I didn't mean to post these solutions as ways of saying "See LabVIEW can do it, you just need to work harder."  It was meant to say "Here is a solution".  Often times on the forums a user will post a question and I'd like to find a solution, to get discussions going so others can also post their solutions which are often times better than the first ones I came up with.  Not supporting gifs with varying timing, longer than 1s delays, and extension blocks feels short of being able to say LabVIEW supports gifs.  Having LabVIEW support PNGs without alpha layer transparencies is a similar shortcoming that I've found work arounds for.  But again it doesn't mean I'm happy about it.

No no, that's perfectly fine. I may come of as too complaintive. At other times I'm a fierce defendant of LabVIEW :-) It might be a question of circumstances for me - I enjoy programming LabVIEW, so if I have the time to do it I don't mind challenging workarounds. If I'm short on time I hate I have to do them. And also, things might get better in the future. So don't put too much weight on my complaining, my bark is much worse than my bite :-)

4 hours ago, hooovahh said:

The dragging files to a control from explorer has similar work arounds that I'm sure you've found involving transparent and hidden path controls, floating on top of the control which will have value change events when dropped.

Yes, exactly the workaround I want to implement. But it's not so simple. I don't want the invisible path control (let's call this Control P) to be over my target control (let's call this control T) permanently, as I want control T to behave completely normal, except when I drag something onto it. That is, upon dragging something from the explorer onto the VI FP, and ultimately onto control T, only then do I want control P to place itself over control T to receive the drop (and whisk itself off to the side again after it has passed on the dropped item via Value Change). There are two problems with this:

1) Once I drag something onto the FP all normal control event firing stops. I would have hoped Mouse Enter or Mouse Down would fire on control T, but they don't. So I have no way of detecting when that cursor is over control T. I can't even detect such a drag entering the VI Pane, so I couldn't even poll the cursor by looking at the mouse position with Input Device Control.

2) If I succeed in detecting that drag, and move control P in place, if I then want to abort the drag (by pressing ESC on the keyboard, or by dragging outside control T again and letting go of the mouse button), I have no events firing in this case either. I would have hoped Mouse Leave would fire on control P, but it doesn't.

So, I'm contemplating how I can discover that drag from explorer has started, and how I can discover if it is aborted again.

 

Edited January 11, 2017 by Steen Schmidt

[ShaunR]

49 minutes ago, planet581g said:

Shaun, would you be willing to elaborate on your process for doing this? Has this already been discussed and do I just need to be pointed to those discussions? I find this interesting, but it also seems like it would pose its own challenges. To do this it makes you a LabVIEW/front end web developer, right? Do you have a preferred JavaScript framework? Do you run into issues where browser updates break your UI? It seems like it would slow down development time so it might be a hindrance on customer projects that have aggressive delivery timelines.

I probably shouldn't hijack this thread. If you'd be willing to discuss your methodology, I could start a new discussion.

Eric

There's no magic here. Browser + websockets + LabVIEW. It definitely doesn't make me a web developer, that's why I want to use Rainmeter because I suck at drawing.

[hooovahh]

Here is a good example.  It is a bit more complciated than it needs to be but the main thing is that after a value change it hides the invisible path control, and then if your mouse leaves the chart, then it makes the invisible path control shown.

http://forums.ni.com/t5/Example-Program-Drafts/Windows-Explorer-in-your-front-panel/ta-p/3492301

[Steen Schmidt]

52 minutes ago, hooovahh said:

Here is a good example.  It is a bit more complciated than it needs to be but the main thing is that after a value change it hides the invisible path control, and then if your mouse leaves the chart, then it makes the invisible path control shown.

http://forums.ni.com/t5/Example-Program-Drafts/Windows-Explorer-in-your-front-panel/ta-p/3492301

Thanks, but having N control P's, one on top of each control T, was what I'd like to avoid. I would much prefer a single control P that resized and moved in place over each control T whenever it was needed. The reasons for this:

1) Being able to drop just a single "Drop Sink" (I call the control P that) control anywhere on the FP is simpler than meticuously placing N of them over each control T (and leaving enough border of the underlying control T to keep its Mouse Over/Mouse Leave events actionable).

2) The hidden control Ps won't scale and move with the FP, unless you jump through all sorts of other hoops (you have to remember to also set those to scale/bind to splitter, and they have a different size than the underlying control). If they could be placed just in time, one control P would suffice and it would always be placed just right.

Edited January 11, 2017 by Steen Schmidt

[ensegre]

8 minutes ago, Steen Schmidt said:

2) The hidden control Ps won't scale and move with the FP, unless you jump through all sorts of other hoops (you have to remember to also set those to scale/bind to splitter, and they have a different size than the underlying control

Oh, apropos FP things and "LabVIEW falling short and us solving simple shortcomings with days of programming".... One idea in this direction.

[G-CODE]

3 hours ago, ShaunR said:

There's no magic here. Browser + websockets + LabVIEW. It definitely doesn't make me a web developer, that's why I want to use Rainmeter because I suck at drawing.

I guess I'm waiting for the day where I see a case study of a medium to large size LabVIEW app with the UI completely developed with a JavaScript framework. (Angular, React, Vue, etc). If pressed for time, I can't think of a good reason to do this assuming a standard LabVIEW UI can meet all the requirements.

[ShaunR]

48 minutes ago, planet581g said:

I can't think of a good reason to do this assuming a standard LabVIEW UI can meet all the requirements.

Ignoring the obvious Gif (and apng)........

Dynamically create controls. Tables with child controls in cells. Proportional control resizing. Tab controls that work properly. Window and graph animations. Skins. Drag and drop....shall I go on?.

[smithd]

3 hours ago, ShaunR said:

Ignoring the obvious Gif (and apng)........

Dynamically create controls. Tables with child controls in cells. Proportional control resizing. Tab controls that work properly. Window and graph animations. Skins. Drag and drop....shall I go on?.

Those are all good features but theres other aspects you're missing just with regards to the general design:

• Encrypted/authenticated communication via https (since apparently NI can't provide a TLS api on the diagram)
• Pretty much every popular language can talk https with json or xml payloads
• Browser is sandboxed
• Evergreen UI code
• Accessibility everywhere, even across corporate networks through reverse proxies

4 hours ago, planet581g said:

I guess I'm waiting for the day where I see a case study of a medium to large size LabVIEW app with the UI completely developed with a JavaScript framework. (Angular, React, Vue, etc). If pressed for time, I can't think of a good reason to do this assuming a standard LabVIEW UI can meet all the requirements.

I definitely agree that theres a pretty big hump to get over. I'm building something that uses a lot of the above features but still provides a labview UI simply because I don't need it to be fancy and I know labview. That having been said, I don't see a ton of risk to the concept. People have been building client server labview code for a long time, javascript is a proven technology (even if []+{} != {}+[]), and far far far far far far far far more people are successful with javascript than have ever even heard of labview (sadly for some reason success eludes newspaper website developers, who love javascript but are horribly bad at it, but I don't think their incompetence means the whole platform is bad).

Edited January 12, 2017 by smithd

[Steen Schmidt]

7 hours ago, planet581g said:

I guess I'm waiting for the day where I see a case study of a medium to large size LabVIEW app with the UI completely developed with a JavaScript framework. (Angular, React, Vue, etc). If pressed for time, I can't think of a good reason to do this assuming a standard LabVIEW UI can meet all the requirements.

We investigated doing a non-LabVIEW UI for a recent project, due to alle the reasons Shaun lists, but LabVIEW web service support was simply too lacking (crippled web server and non-existent security).

So, lot's of good reasons to do it, just not really possible in a comfortable way.

Edited January 12, 2017 by Steen Schmidt

[ShaunR]

11 hours ago, smithd said:

Those are all good features but theres other aspects you're missing just with regards to the general design:

• Encrypted/authenticated communication via https (since apparently NI can't provide a TLS api on the diagram)
• Pretty much every popular language can talk https with json or xml payloads
• Browser is sandboxed
• Evergreen UI code
• Accessibility everywhere, even across corporate networks through reverse proxies

No problem for me. The Websockets support HTTPS (wss://) when this is installed and it has proxy support (HTTP with NTLMv2 auth and Socks 5 with basic)

I don't know what "Evergreen UI code" means but sandboxed has never been a problem. Besides. As I said earlier. I've been playing with Rainmeter which doesn't use a browser and is more like desktop gadgets.

8 hours ago, Steen Schmidt said:

but LabVIEW web service support was simply too lacking (crippled web server and non-existent security).

I've never used the NI web server for webservery things (there is no public security analysis). I've always used Apache or Nginx but never for streaming or real-time; its too slow.

Nice to see the community taking security seriously at last

Edited January 12, 2017 by ShaunR

[Zou]

 

21 hours ago, ShaunR said:

Ignoring the obvious Gif (and apng)........

Dynamically create controls. Tables with child controls in cells. Proportional control resizing. Tab controls that work properly. Window and graph animations. Skins. Drag and drop....shall I go on?.

LabVIEW objects are not Windows object, so you can't create LabVIEW ctrls dynamically.

However, you CAN create Windows objects (e.g. text box, for both numeric ctrl & string, picture box for images, and static obj for decor. etc.) on the FP dynamically with or without a container (a child window if no container).

Animations, skins, drag & drop, etc.  all can be done with Windows API, just like other programming languages (e.g. C#, VB) do.

 

[ShaunR]

28 minutes ago, Zou said:

 

LabVIEW objects are not Windows object, so you can't create LabVIEW ctrls dynamically.

However, you CAN create Windows objects (e.g. text box, for both numeric ctrl & string, picture box for images, and static obj for decor. etc.) on the FP dynamically with or without a container (a child window if no container).

Animations, skins, drag & drop, etc.  all can be done with Windows API, just like other programming languages (e.g. C#, VB) do.

 

LabVIEW is cross platform (Windows, Mac and Linux).

Edited January 12, 2017 by ShaunR

[Zou]

27 minutes ago, ShaunR said:

LabVIEW is cross platform (Windows, Mac and Linux).

That's because NI takes care of the cross platform issue.  The source code for LabVIEW itself is implemented depending on OS.

For those features LabVIEW doesn't support (yet), you can implement them yourself.

 

[ShaunR]

2 hours ago, Zou said:

That's because NI takes care of the cross platform issue.

As do browsers.

2 hours ago, Zou said:

For those features LabVIEW doesn't support (yet), you can implement them yourself.

But perhaps it helps to think of it another way.

Once you have completely separated the UI from the working code with a cross platform, standardised communications scheme (like websockets, WebRTP, TCPIP or UDP) you are not just limited to browsers or even LabVIEW - you can create interfaces in any language rather than patching LabVIEW. However. If you intend to support cross platform for the UI then doing as you suggest means you will end up with [a minimum of] 3 different and distinct code bases along with all their test harnesses and build tools (probably in different languages). You are also a bit stuck if you want to see the pseudo interfaces of embedded applications that LabVIEW provides natively.

It is a maintenance nightmare that browsers solve quite nicely and, if you are as incompetant with an ebrush  as I am or almost at the deadline, you can outsource the UI to web developers while you do the interesting stuff. There's always a few web-devs hanging around IT departments and they can argue about layouts, corporate colour schemes and logos.

Maybe we should move all this to another thread if we are not finished?

Edited January 13, 2017 by ShaunR

[smithd]

21 hours ago, ShaunR said:

I don't know what "Evergreen UI code" means but sandboxed has never been a problem.

Evergreen is a term I've heard applied to browsers since they auto-update. I went ahead and applied it to web page applications.