Jump to content

VIpreVIEW - Interactive VI preview


Recommended Posts

OK, I had a chance to play with a bit and it looks really nice. It works fast enough for small VIs, which I suspect is most of what will be thrown at it if it's used for sharing code online.

Would you be interested in adding it as another option inside the CCT? That would provide the tool with the options of either capturing an image or a flash demo.

The only thing that needs to be checked out is how to embed it. I've seen that the only thing you need is the swf file, but we need an easy way of copying and pasting both the file path and the embed tag code.

Link to comment

QUOTE(Yen @ Feb 29 2008, 11:27 AM)

Would you be interested in adding it as another option inside the CCT? That would provide the tool with the options of either capturing an image or a flash demo.

It is interesting proposition but there are two issues. At first, my employer is a sponsor of time spent for this project and therefore credit and link should be included in both GUI and SWF (however it has not to be anything covering half of the window). Second one in the license - definitely binary of script compiler should be included in distribution (it's GPL), so whole the project should be GPL and contain also source code of compiler (but I'm not sure about it). So keeping CCT BSD licence will be rather impossible. But I may be wrong, I'm not too familiar with license issues.

What concerns embedding, beside swf also its dimesions should be known, because browser pointed directly to sfw file stretches it to window size. BBCode contains tag to embed flash ... checking whether it works here...

http://vugie.republika.pl/mult/mult.swf

... works, but forces to reduce flash size to pretty small values...

Here[/post] is an example how it should look like

Link to comment

QUOTE(vugie @ Feb 29 2008, 01:50 PM)

At first, my employer is a sponsor of time spent for this project and therefore credit and link should be included in both GUI and SWF (however it has not to be anything covering half of the window). Second one in the license - definitely binary of script compiler should be included in distribution (it's GPL), so whole the project should be GPL and contain also source code of compiler (but I'm not sure about it). So keeping CCT BSD licence will be rather impossible. But I may be wrong, I'm not too familiar with license issues.

In the GUI, we have acknowledgements in the about screen and it can go in there. I don't want to start filling the main screen with logos and links.

In the flash movie, I don't think a link or an additional icon would be a problem.

As for the license, I don't have a problem with distributing the original with the CCT, but I want to avoid making it GPL. If we have a basic agreement, I think we can look more deeply into this to understand how it works. Maybe someone familiar with licenses can shed some light. Jim, maybe?

QUOTE

What concerns embedding, beside swf also its dimesions should be known, because browser pointed directly to sfw file stretches it to window size. BBCode contains tag to embed flash ... checking whether it works here...

I tested it in the NI forums, but the forums there do not allow attaching swf files. We can ask the moderator to change that. Pointing it to an external file works fine and you only need the embed tag there. If our tool is doing the capturing, it can also prepare the tag text and set the sizes to be right.

Link to comment
  • 2 weeks later...
  • 2 weeks later...

QUOTE (Yen @ Mar 1 2008, 02:32 PM)

In the GUI, we have acknowledgements in the about screen and it can go in there. I don't want to start filling the main screen with logos and links.

In the flash movie, I don't think a link or an additional icon would be a problem.

As for the license, I don't have a problem with distributing the original with the CCT, but I want to avoid making it GPL. If we have a basic agreement, I think we can look more deeply into this to understand how it works. Maybe someone familiar with licenses can shed some light. Jim, maybe?

If you integrate something covered by the GPL into a project it usually makes the whole project being covered by the GPL. Specific provisions such as an amendment to the GPL for the Linux kernel being excluded.

To be able to integrate libraries or subcomponents that are desired to be GPL like licensed without making the rest of a program being GPL too there has been specifically the LGPL license created for. This allows including LGPL licensed components in a dynamic way into another application which can be of any other license including fully closed source.

Purists claim that even calling a GPL based application over the command line explicitedly from inside another application is forcing this application to be GPL too, but I think that is a completely useless restriction and most likely not enforceable at all.

Rolf Kalbermatter

Link to comment
  • 10 months later...

After a year of doing something from time to time, investigating various flash generation libraries and turning whole the code up side down, we have another prerelease of VIpreVIEW (interactive preview of VI in flash).

Visually almost anything was not changed and actually even code looks similar as in previous version (best ideas come at beginning), but:

  • it is much faster (speed is already reasonable)
  • flat sequence works (however it is implemented pretty ugly)
  • fixed issue with showing labels from not visible frames
  • fixed issue with additional 1 px border
  • its is much faster (repeating this because I'm so proud of it)
  • and what even better - it still may be faster (and I know more or less how to do it)

Below some instructions copied from the first post:

The main file is VIpreVIEW.vi. You have to open it, fill all paths, sizes, etc. and run (not very professional, isn't it?). After some work (depending on VI complexity) it will create a lot of files at target path. Most of them are temporary files, but I do not delete them yet for debug purposes. Open {name}.html file in a browser and watch the result. I included SWFtools binary in this package (it's GPL).

Comments as always are welcome

  • Like 2
Link to comment

I haven't looked at the new version yet, but I think it would only be practical in the real world if it ended up generating a single file and had a simple UI (which I understand you want to wait with until you get ahead with it). As mentioned, including it with the CCT would be great.

Link to comment

QUOTE (Yair @ Feb 15 2009, 05:29 PM)

I haven't looked at the new version yet, but I think it would only be practical in the real world if it ended up generating a single file and had a simple UI (which I understand you want to wait with until you get ahead with it). As mentioned, including it with the CCT would be great.

Of course it will be as you said: Simple interface generating single SWF file easy to publish anywhere (+ maybe some code snippet to copy-paste making embedding even easier). Now it is just a functional prototype.

What concerns merging with CCT (thanks for the proposition)- for me the only argument against is the license. Mine has to be GPL as I use GPLed SWFtools utility. I digged in this topic and I'm pretty sure that even calling external exe file with "system exec" (that's the way I'm doing this) obliges me to use GPL. Considering migration to something else, I investigated several other tools/libraries with less restrictive licenses butnone of them was as convienient as SWFtools. So as for now it has to be standalone tool and that's a pitty.

I'm thinking about such a feature: vipreview (BTW is that name ok?) analyses structure of vi it was called for and its subVIs and their subVIs up to given level of nesting and then lets user choose VIs to be included in SWF file. Flash viewer lets to browse such a file in manner similar to LabVIEW IDE - clicking on subVI shows its code, list on the side (or expandable) lets to choose individual VI.

How do you think - would it be helpful or only an overhead making UI more complex?

What other features would you suggest?

Link to comment

I can't say I know the details of the GPL. Rolf seems to think that the restriction on calling executables is for purists and unenforcable and common sense would make me agree. However, you can also simply distribute it as a parallel capture tool with its own license.

As for the features, you should probably think about the relevant uses and how much you want to invest in this. Personally, I think I would find something like this useful when posting an example on-line, and I would want the creation UI to be as minimal as possible (e.g. a single control asking how many levels down the call chain I would like to go. In most cases, I expect this would only be one or two).

The coolest thing would be if the resulting flash file could have its own "window manager" which will allow moving the VI windows around, but a listbox with the open VIs is probably enough too.

P.S. VIPreview is a good name. You can get an icon of a viper, similar to how LabPython uses a Python. You could probably even rename it to ViperVIEW or something, if you don't mind the lack of clarity.

Link to comment

I had a quick look at the code and you would probably want to change the connector pane. The standard convention is using the top corners for references and the bottom corners for the error clusters.

Additionally, you should probably get rid of the "lossless compression" boolean, as JPEG is useless when dealing with images like LV code. Just do PNG all the time. Another point is that in the final UI you would probably want to get rid of the folder name and just let the user select the file name, since you will presumably have a single file.

It seems to me that parsing the subVIs should be relatively simple, as you already have the recursive parsing code. All you need is to check the depth of the call chain. Also, this is from memory, so it may be wrong, but you might be able to simplify the code by pushing all the objects in the top level diagram into the queue instead of dealing with them in the main VI.

Link to comment
  • 4 months later...

I also attached recently generated swf, as these from previous posts are gone, but I'dont know how to embed it in the post... BBcode is not working.

test3.swf

Also if someone who got the power could move this topic to uncertified code repository where is much better place for it?

vugie. I think this is way awesome and I would like to get this in the LAVA CR ASAP. I suggest you submit it, it doesn't have to be ready. Please review the instructions here and here. Just submit it and select Uncertified as the category.

I would also like figure out how to use the new LAVA media embed feature discussed here. Otherwise you would need to have HTML editing capabilities which is currently only available to Premium Members and other special LAVA groups like NI, JKI and V I Engineering.

Link to comment

I just wanted to inform that after total rewrite of everything (to LVOOP) I reached exactly the same functionality as it was before. That's a progress, isn't it? ;)

So now it's time to start extending VIpreVIEW. For the beginning, following Yair's suggestions, I designed a logo:

post-7450-124775901626_thumb.png

I also attached recently generated swf, as these from previous posts are gone, but I'dont know how to embed it in the post... BBcode is not working.

test3.swf

Also if someone who got the power could move this topic to uncertified code repository where is much better place for it?

vugie: this is sweet -- you rock!

Link to comment

Very impressive, not sure if you've thought of this before, but with this you could possibly be able to create our own open source VI file format.

Pass in a VI into a program and get the SWF equivalent. Then take the SWF put it in another program and get the VI back. Of course there's alot of issues associated with that, like subVIs. But for basic stuff I think it could utilize the quick drop function to find code.

Link to comment

So, where's the new code?

P.S. Great logo, but you should probably flip it, so that it looks more like the LV logo.

I'm going upload the code after making it really usable and with at least trace of documentation. Now even I has sometimes a problem to remember where I put top level VI... Because it's a member of a class and it is not obvious which one it should be.

I already tried the flipped version of logo but it doesn't look too good. I don't know why...

Very impressive, not sure if you've thought of this before, but with this you could possibly be able to create our own open source VI file format.

Pass in a VI into a program and get the SWF equivalent. Then take the SWF put it in another program and get the VI back. Of course there's alot of issues associated with that, like subVIs. But for basic stuff I think it could utilize the quick drop function to find code.

Creating universal text-based format for VI was already discussed few times as I remember. BTW it is a good subject for LAVA cooperative project, LAVA flagship or how too call it... I can think of many advantages of such a format and related utilities.

With VIpreVIEW I capture too less information for such an approach - just images of subsequent frames of multiframe structures and some text and position info from other objects for displaying tips.

Link to comment

create our own open source VI file format.

You might find the NI legal team hunting you down if you do that.

Now even I has sometimes a problem to remember where I put top level VI

You should add virtual folders to the class to organize it. Also, you can drag the top level VI to be the first one.

I already tried the flipped version of logo but it doesn't look too good. I don't know why...

You're right.

Link to comment

You might find the NI legal team hunting you down if you do that.

I don't think it is as much a legal problem as it is a technical one. Creating a file formaat is not something you can legally prohibit. Only copying it could be prohibited but this does IMHO not apply here. However there are many aspects of a VI that are not accessible even through scripting, so you can not create a fully descriptive alternate file format.

And reverse engineering the original format, while IMO an exercise in vain already, would be violating your LabVIEW license you accept when installing it.

Rolf Kalbermatter

Link to comment

I don't think it is as much a legal problem as it is a technical one. Creating a file formaat is not something you can legally prohibit. Only copying it could be prohibited but this does IMHO not apply here. However there are many aspects of a VI that are not accessible even through scripting, so you can not create a fully descriptive alternate file format.

And reverse engineering the original format, while IMO an exercise in vain already, would be violating your LabVIEW license you accept when installing it.

Rolf Kalbermatter

I think people may be confusing an open-source documentation of the existing VI format and a completely new (Human-readable FTW) file format.

I really don't see how NI could possible have a legal leg to stand on against a NEW file format , i.e. a template for a script to generate VIs from a given input file.....

Shane.

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
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
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.