If you use the GUI Form Editor you may want this patch

Answered

I use GUI Form Editor for most of my plugin forms and often copy existing components to create similar ones.

All is good up this point, the hassle starts at re-using edited versions bundle property keys and text for the new control.

The GUI property editor forces you to go through hoops to copy the property key and value in order to use edited versions in the new control. Double that for re-using the Text and TooltipText properties.

Needing to create a new settings pane for annotator configuration and knowing that I will have a few dozen checkboxes with similar property keys, texts and tooltip texts I could not bear to do it the painful way and decided to add functionality to allow direct editing of property keys to select/create a new key without going through two additional layers of dialog boxes.

YouTrack: IDEA-208521 has a patch you can apply if you use your own intelli-community build or you can vote up the issue to show your interest in the feature.

2 comments
Comment actions Permalink

Just curious, why this post, issue and patch, instead of a pull request?

0
Comment actions Permalink

The post is to let others who could use the improvements know there is a solution available.

The issue is to raise awareness to usability problem in the IDE.

The implementation is to solve my problems that the issue is causing.

The patch stems from the implementation and is to provide a starting point for resolving the issue with the hope that it does not linger in YouTrack for  too long since there is already a working solution.

I am not responsible for the subsystem on the IDE and not being sure of all factors that must be taken into account on a project of this complexity,  I try to make few changes to existing implementation and copy/modify existing parts of the implementation to not loose important details that it contains. The developer responsible for the subsystem, being the owner of that code, has more leeway in refactoring existing code and improving on the implementation suggestion I make.

A PR requires a fork and a branch because committing the changes to the master branch will pollute my fork with unofficial changes which may or may not ever become official. Been there. Done that. Not a good long term strategy.

A patch has more flexibility because it is a snapshot of changes without changing git history. I was also under the impression that patches are the preferred method for externally submitted code changes to the IDE.

0

Please sign in to leave a comment.