Icon editor load entry point

[svelderrainruiz]

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.

[jimkring]

@svelderrainruiz

We can have a more streamlined process by not having to rebuild the ppl in between testing changes.

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

As a dev contributor to the icon editor project, I want to quickly test changes I’ve made to the icon editor source code. Currently, I have to rebuild the PPL [and do other steps?] which takes a long time [X minutes and Y seconds]. 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.

[svelderrainruiz]

Made the changes, and added an additional section that establishes the additional benefits we could get from this change

[crossrulz]

@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.

[crossrulz]

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.

[svelderrainruiz]

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.

[crossrulz]

So the thought now is to remove the Icon Editor from the folder and then use LVAddons instead? I fail to see how that helps the development process.

[gregr-ni]

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.