Skip to content

ni/labview-icon-editor

LabVIEW Icon Editor

CI Status Latest Release Discord Chat License: MIT Coding hours


🗂 Table of Contents

For LabVIEW Users:

For Contributors:


📌 Overview

The LabVIEW Icon Editor is an open-source, MIT-licensed tool for creating and editing VI icons, delivered as a VI Package. Each official LabVIEW release automatically includes the latest Icon Editor from this repository’s main branch (the next integration is targeting LabVIEW 2026 Q1).

In practice, your contributions – whether new features, fixes, or improvements – can become part of the Icon Editor shipped with LabVIEW itself. The source code is maintained in LabVIEW 2021 SP1 format for broad compatibility (allowing contributors using LabVIEW 2021–2025 to build the editor), while the released VI Package requires LabVIEW 2023 SP1 or newer to run.

  • 🛠 Built in LabVIEW (“G” code) – All editor functionality is implemented as LabVIEW VIs (graphical code).
  • 📁 Broad Compatibility – Source is stored in LabVIEW 2021 SP1 format for development, but the distributed packages target LabVIEW 2023 SP1 through 2025.
  • ⚙️ CI PipelineGitHub Actions orchestrate PowerShell-based workflows for testing, building, and publishing the .vip package.
  • 🔄 Modern Development Practices – This project helped pioneer NI’s open-source CI/CD patterns, and its infrastructure will migrate to a centralized toolkit for future LabVIEW projects.

NI’s open-source initiative encourages community collaboration on this project to continuously improve the Icon Editor and streamline LabVIEW development workflows.


📦 Installation

Prerequisites: • LabVIEW 2023 SP1 (or newer) • VI Package Manager (VIPM) installed • (Development note: Source code is saved in LabVIEW 2021 SP1 for building and backward compatibility.)

  1. Download the latest .vip installer from the Releases page.
  2. Open VIPM (VI Package Manager) in Administrator mode.
  3. Install the package by double-clicking the downloaded .vip file or using File ▶ Open Package in VIPM.
  4. Verify the installation by launching LabVIEW, creating a new VI, and opening the Icon Editor (e.g. right-click the VI icon and choose Edit Icon).

For additional details and troubleshooting tips, see INSTALL.md.


🧩 Key Components

  1. Source Code (VIs) – The editor’s functionality is implemented entirely in LabVIEW, as a collection of VIs organized into a project. This includes the UI and logic for icon editing.
  2. PowerShell Automation – A suite of PowerShell scripts (built on the G-CLI toolkit) supports repeatable build and test tasks. These scripts allow running LabVIEW build steps and packaging from the command line, ensuring consistent results between local development and CI.
  3. CI/CD Workflows – GitHub Actions workflows are provided for common tasks:
    • Build VI Package – Compiles the source and produces a .vip artifact (VI Package).
    • Development Mode Toggle – Enables or disables a mode where LabVIEW loads the Icon Editor from source (for debugging vs. using the installed package).
    • Run Unit Tests (now part of the main CI pipeline) – Executes automated tests to verify the Icon Editor’s behavior in a clean LabVIEW environment. Additional details on these pipelines are in CI Workflows and the CI Workflow (Multi-Channel Release Support).

🚀 Getting Started & Contributing

We welcome both code and non-code contributions – from adding new features or fixing bugs to improving documentation and testing.

  • 📑 Contributor License Agreement (CLA) – External contributors must sign NI’s CLA before a pull request can be merged (this will be prompted automatically on your first PR). The CLA ensures NI has rights to distribute your code under MIT, and you retain rights to your contributions.
  • 🧭 Steering Committee – A small group of NI maintainers and community members governs the project’s direction. They approve significant changes and label issues as “Workflow: Open to contribution” once an idea is ready for external work.
  • 🔄 Find an Issue to Work On – Check the issue tracker for issues labeled “[Workflow: Open to contribution]” – these are tasks approved for community development. Comment on the issue to volunteer, and a maintainer will assign it to you and create a branch named issue-<number>-<short-description> if one doesn’t exist, marking the issue’s Status as In Progress so CI will run.
  • 🧪 Long-Running Features – Major features that might span weeks or months can be developed on special experiment/ branches with more rigorous CI (security scans, gated releases). See EXPERIMENTS.md for details on how experimental feature branches work.

For detailed contribution guidelines (branching strategy, coding style, etc.), please see the CONTRIBUTING.md document. The /docs folder also contains setup guides and technical notes (summarized below).


🌱 Feature & Experiment Workflows

Standard Feature Contribution Workflow:

  1. Propose & Discuss – Start by proposing your idea via GitHub Discussions or by opening an issue. Discussing first helps refine the idea and get feedback.
  2. Issue Approval & Assignment – Once the idea is approved, maintainers label the issue Workflow: Open to contribution. After you volunteer, a maintainer assigns the issue and sets up a branch such as issue-123-short-description, ensuring the issue is marked In Progress. The workflow defined in ci-composite.yml triggers, but its jobs run only when the issue-status gate passes (branch pattern issue-<number> and issue Status In Progress). Runs failing this gate appear in GitHub Actions but skip subsequent jobs.
  3. Development Setup – Fork the repository and clone your fork. Check out the feature branch. Prepare your LabVIEW environment (LabVIEW 2021 SP1 with required dependencies applied). You can develop in two ways:
    • Manual mode: Follow the manual-instructions.md guide to configure LabVIEW to use the editor’s VIs directly (replacing the built-in editor).
    • Automated (CLI) mode: Use the automated-setup.md guide for PowerShell-based scripts to build the pack and run tests.
  4. Implement & Test – Develop your changes using LabVIEW. Test the editor manually in LabVIEW (in development mode) to ensure your changes work. Run any available unit tests. Make sure to apply the runner_dependencies.vipc file (located at .github/actions/apply-vipc/runner_dependencies.vipc) via VIPM or the scripts so that all required libraries (G-CLI, etc.) are present.
  5. Submit a Pull Request – Open a PR linking to the issue. Our CI will automatically run and build a .vip package with your changes for testing. Maintainers and others can install this pre-release package to test your contribution. Iterate on any review feedback.
  6. Merge & Release – Once your contribution is approved, it will be merged into the develop branch. During the next release cycle, develop is merged into main and a new official Icon Editor version is released. (At that point, your contribution is on track to ship with the next LabVIEW release.)

Experimental Feature Workflow:

For very large or long-term contributions, NI may use an experiment/<feature-name> branch:

  • The experiment branch lives in the main repository (so CI can run on it) and allows multiple collaborators to work in parallel on the feature. Regular develop branch merges into the experiment keep it up-to-date with ongoing changes.
  • Automated code scanning (e.g. Docker-based VI Analyzer and GitHub CodeQL) runs on every commit/PR to the experiment branch, catching issues early.
  • Manual approval for builds – By default, publishing a build from an experiment branch is disabled. An NI maintainer must manually trigger an “approve-experiment” workflow to generate a distributable .vip for testing. This ensures experimental builds aren’t widely released without review.
  • Optional sub-branches – The team can create sub-branches like alpha, beta, or rc under the experiment branch for staged testing releases (e.g. experiment/feature/alpha). These follow a multichannel release approach for gradual testing.
  • Integration – When the feature is complete, the experiment branch is reviewed and then merged into develop (and later into main) following Steering Committee approval. If an experiment is aborted or partially finished, it may be archived or selectively merged as appropriate.

(See EXPERIMENTS.md for full guidelines on experimental branches.)


📚 Documentation

In-depth documentation and reference guides are located in the /docs directory. A complete index is available in docs/README.md. Notable documents include:


📄 License & CLA

This project is distributed under the MIT License – see the LICENSE file for details. By contributing to this repository, you agree that your contributions can be distributed under the same MIT license and included in official LabVIEW releases. (In practice, this means you’ll be asked to sign a simple Contributor License Agreement on your first pull request, confirming you are okay with NI using your contributions in LabVIEW.)


💬 Contact & Community

  • 🗨️ Discord Chat: Join our Discord server to ask questions, get help, or discuss ideas in real time with NI developers and the community.
  • 📣 GitHub Discussions: For longer-form discussions, proposals, or Q&A, visit our GitHub Discussions. It’s a great place to propose new features or improvements and get community feedback.

🙏 Thanks for Contributing!

Your ideas, testing, and code contributions directly shape the Icon Editor experience across LabVIEW 2023–2026 and beyond. Thank you for helping improve this tool for the entire LabVIEW community!

About

Source for LabVIEW's icon editor

Topics

Resources

License

Code of conduct

Contributing

Stars

Watchers

Forks

Packages

No packages published

Contributors 13