Jump to content

Search the Community

Showing results for tags 'feature request'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • Special Interest Boards
    • Developing LabVIEW Tools and Add-ons
    • Professional User Interface Design in LabVIEW
  • VI Package Manager (VIPM)
    • VI Package Manager (VIPM)
    • Dragon Beta
  • JKI Tools
    • JKI Flat UI Controls
    • JKI Design Palette
    • JKI State Machine
    • JKI State Machine Objects (SMO)
    • Caraya Unit Tester
    • VI Tester
    • JKI JSON
    • HTTP REST Client
    • JKI Simple Localization
    • EasyXML Toolkit
  • Legacy Tools
    • Legacy Tools
  • VIPM Community Add-ons for LabVIEW
    • JSONtext by JDP Science

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start





Website URL







Found 10 results

  1. I would include an option at install requirements page indicating if the package can be only installed on the global environment, local environment or both.
  2. When there are missing required packages and project is opened, Dragon asks to install missing required packages. But, it would be great to display in this dialog window what exact packages are missing - just to know in advance whether it is really needed to install them now.
  3. 1. Create Dragon project, configure it to install packages under Dragon project folder. 2. Install some packages. 3. Use VIs from the packages in the project. 4. Then, deselect "Install Packages Under Dragon Project Folder" checkbox for the Dragon project, save changes. 5. Close Dragon project. 6. Open Dragon project. 7. Open LV project's VI -> there is no functions palette for the locally installed packages. 8. Open Resources tab -> there is no displayed locally installed toolkits. It would be nice when Dragon could handle such situation - for example, anyway display list of locally installed packages, or functions palette. Or, by forcing user to delete local packages and use global packages instead. Also, if such project will be, for example, pulled from repository to another PC, Dragon project will be opened -> it will ask to install missing toolkits -> and it will install them globally. So that will be two different projects already due to different dependencies. I've simulated it by removing lv-venv folder after step 5.
  4. Clicking the Dragon button opens the welcome screen. Then the user needs to click "Open VIPM" to open the VIPM window. Idea: add a shortcut directly to VIPM:
  5. Idea: add (user-configurable) shortcut to source code control:
  6. Clicking the *.lvproj file opens the normal project window in LabVIEW, not in the Dragon wrapper. The result is that even if .dragon specifies a particular version of LabVIEW a developer can unwittingly open the project in the wrong LabVIEW version. Idea: change this behavior such that Dragon handles opening the lvproj file (in the proper LV version). Bonus idea: "Developer A" can require that Dragon be installed and used to open the lvproj file (further protecting us from accidentally fast forwarding the LV version) Caveat: What if we mean to open in the "wrong" LabVIEW version?
  7. There are many packages which either are completely done as project providers, quick-drop plugins, shortcut menu plugins, etc. or partially provide such functionality. JKI State Machine is great example of that. It is available from LV functions palette, and also has State Machine Editor functionality (which is mostly shortcut menu plugin). But when JKI State Machine is installed just in lv-venv folder, then State Machine Editor does not work. Similar situation is for other toolkits also - for example, RAFA Language Support Toolkit, ANV toolkits, JKI VI Tester, etc. - there are project providers + functions palette. On one hand, it is developer's responsibility to wisely separate scope of the toolkits installed in the system. But on the other hand, for sure someone could forget about such behavior, and then could face some troubles with figuring out what is actually happening. It would be nice somehow handle it via Dragon. For example, maintain list of toolkits not recommended to be installed in lv-venv folder. Such list could be created on vipm.io, and then Dragon will use it in order to verify toolkits to be installed locally. Also, VIPM package build configurator could have additional flag to indicate whether toolkit could be safely installed in lv-venv, or it should be installed just globally. So toolkits built with newer VIPM version will have that flag set. But the question is what to do with existing toolkits, because not all of them will be rebuilt anyway. Another way - Dragon could determine, whether toolkit has some files which are going to be copied into project provider/popup menu/etc. folders. If so, then we could assume that toolkit has project provider, shortcut menu plugin etc. functionality - so it is not recommended to install it locally. Partial solution (but not sure that it is possible to implement) in order to make shortcut menu plugins working is to provide some hook via Dragon, which will allow to load plugins from local lv-venv folder. But for sure, there could be some more elegant solution which will allow at least to warn user about possible consequences while installing such kinds of toolkits locally (in lv-venv) folder...
  8. Firstly, Kudos to the JKI team. Dragon looks awesome, delivers on the promises, and truly is a work of art. I've enjoyed using it so far and really look forward to this going live. One small feature request I've come across - I'd like the ability to multi-select items in the Resources view. I'm converting a few packages and needed to uninstall a bunch of packages from the global location, but Dragon only lets me select one at a time. My work-around was uninstalling through VIPM, so not a big deal, however it would be nice if Dragon supported that natively. Same request would go for "Add Package to VIPC."
  9. I am trying to migrate a project to use dragon and I need to make the package configuration file. I am trying to gather all the package dependencies so I am opening the package information window, but I can't leave that open and work in dragon at the same time. Is it possible to allow the information window to be default or floating? I may just be missing this but is there a way to ask dragon to add the package and all of it's deps to the vipc file in one click? That would also solve my issue.
  10. Hi all, First, thank you JKI for your great tool that makes the design of my UIs so much easier! I successfully added my own themes and controls to the JKI Design Palette but I noticed some controls are not supported. Arrays and clusters with no elements: data structures like arrays and clusters require to have elements to be added to the Palette. Adding arrays or clusters that don't have elements make all the controls in the JKI Design Palette disappear as shown below. In the future, I think it would be great to be able to add our own arrays and clusters that don't have a type to the Palette. Decorations: decorations can't be added to the Palette. I tried to add my own decorations to the Palette and it looks like they are not supported. It didn't make the other controls disappear like above but I think it would be a great improvement to have access to decorations (classic or our own) via the JKI Design Palette. Best, Benoit
  • Create New...

Important Information

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