Icon editor load entry point #55
Replies: 3 comments 8 replies
-
This reads like a “solution statement”. Let’s rewrite it from the user/developer perspective. Here is a rough draft of what I mean by “problem statement” — it’s written in the first person to help the reader put themselves in the user’s (contributor’s) shoes. User’s Problem Statement / User Story
|
Beta Was this translation helpful? Give feedback.
-
|
Made the changes, and added an additional section that establishes the additional benefits we could get from this change |
Beta Was this translation helpful? Give feedback.
-
|
@jimkring perfectly stated my main concern that this will solve: I need to easily test updates. Something that would be useful here would be a couple of additional VIs in the repo that can 1) set the LabVIEW ini token to the secondary/development editor and 2) clear that token to revert back to the primary/built-in editor. There is already an API for updating the LabVIEW.ini file, so these would be very simple to create. |
Beta Was this translation helpful? Give feedback.
-
|
Per the conversation we had today, there is a pitch coming to get this in the next version of LabVIEW. If that is successful, I would consider this open-source experiment a success. With that said, we (the community) need to make sure it is ready. |
Beta Was this translation helpful? Give feedback.
-
|
After a design review with @gregr-ni, it was pointed to me that this problem statement would be able to be fixed by the use of LV Addons. This "icon editor load" callback mechanism already exists, and i would be adding a callback inside of a callback. Having an NI Package that can deploy the icon editor as an LV Addon could allow for this package to be distributed with LabVIEW, and overridden by other users. If somehow this LV Addon is deleted, then it will ask you to download the addon again. |
Beta Was this translation helpful? Give feedback.
-
|
Switching the LV installer to install the icon editor as an LVAddon allows it to be managed like any other addon. It would install as a separate package that can be independently removed. Initially, users would be able to control which icon editor they use simply by uninstalling the default one and installing the one they want. Eventually, we want to make LVAddons controllable at the project level so you could have multiple installed and pick per project which is active. That mechanism is needed to support projects with different dependencies, so I'd rather avoid creating something specific to the icon editor that solves the same problem. |
Beta Was this translation helpful? Give feedback.
-
|
Correct me if I'm wrong but, as I understand the support for LVAddons only works for LabVIEW 2024 and up which would break the support in the LV2021 that the project currently has. |
Beta Was this translation helpful? Give feedback.
-
The LVAddons support started with 2022Q3. Yes, that still breaks the 2021 version we are currently using. My suggestion is that this project should be moved to at least LabVIEW 2024 as 2025 is the first possible version that would be using this new package. |
Beta Was this translation helpful? Give feedback.
-
|
Any changes are already not guaranteed to make it into the LV 2025 Q1 release. We're locking down the release before Thanksgiving. However part of the point of splitting out the icon editor is so it could be installed into older LVs. It should be possible to make a package that installs directly into earlier versions or as an addon for 202Q3 forward. Just have to decide if that is worth the effort. |
Beta Was this translation helpful? Give feedback.
-
I implemented this (this is part of main now). A VIP and NIP get created by using "\Tooling\deployment\Build.bat". This package deploys the PPL to a temp location, and moves it to the correct location depending on the LabVIEW version on a post install action. |
Beta Was this translation helpful? Give feedback.
-
Problem statement
As a dev contributor to the icon editor project, I want to quickly test changes I’ve made to the icon editor source code. After installing the source, i have to rebuild the packed project library after solving multiple conflicts, which takes around 5 minutes. It significantly slows down iteration time for testing changes/fixes and can cause context shifting while I “do something else” while a build is happening, which further reduces my effectiveness. The result is I code at a much slower feature/fix velocity, introduce more bugs (due to attention while context switching), and I generally don’t enjoy the experience of contributing to the project.
Proposal
This change makes the icon editor to read a LabVIEW ini token called IconEditorCustomPluginPath when it loads. A path can be specified on this token that points to a custom icon editor. Any instance of a custom icon editor being unavailable will load the default icon editor.
This approach is similar to the way that TestStand allows users to modify certain behaviors of its IDE by modifying some sequences or specifying a path.
Additional benefits from this change
We could in theory build the PPL that has the change from this discussion and distribute it as a VI package. This would allow new developers that are only working on UI features to have a simplified process because they now only need to install a VI package instead of installing the source. Installing the source modifies your LabVIEW installation, which is not ideal for someone that may want to work as a tester and is now stuck with a LabVIEW install that has been modified. When we need to make changes to the core files of the icon editor, we will have to rebuild the PPL and the VI package, which will be like a sort of "development environment"
See the following idea from Idea Exchange that was intended to gauge the public interest on this new feature.
Beta Was this translation helpful? Give feedback.
All reactions