I have quite a few Designer mods that improve my workflow. For example, I have an AWT event listener that detects when the diagnostic dialog opens and automatically switches to the console tab. It also detects when a component script editor is opened and switches the popup from the navigation tab (which I rarely use) directly to the script editor. It even collapses the description panes that I almost never need anymore, giving me the maximum amount of room to work.
They're all small quality of life improvements, but they really add up. The moment I find myself on a designer that doesn't have them, I really notice all of the extra clicks and steps.
Edit: Removed comments that were applicable to the topic this was split from, but are not applicable to this thread,
...and if anybody has any designer qol improvements or work arounds that that they would like to share, please post them here.
Examples:
ā¢ Here's how I patched that annoying script editor bug that would hide the apply button and collapse the event handler pane when the script editor was resized: Component Window Default Size I wonder if that's still needed? The problem was caused by an embedded container that had a minimum size parameter that was too big, and it was a long time ago. I'm sure they've probably fixed that by now.
I'm not sure if I ever posted this one, but to do it, simply add these two lines of code to the ComponentScriptEditor window opened event handling I outlined in the previous posts:
# Change the default tab from navigation to the script editor
splitPane = findComponentOfClass(window, 'JSplitPane')
findComponentOfClass(splitPane.rightComponent, 'JTabbedPane').selectedIndex = 4
As you can see, my designer hacks are already all over the forum, and there are many more than I've linked to here, but at this point, I'm afraid we've derailed this thread enough. If you can't find the one you need, just post the question, and as always, if can answer it, I will.
I moved this out to another thread because I want to keep this conversation going without derailing the original.
I'd actually love to fix a lot of these things first party - there just really isn't a great channel for feedback on things like this that isn't really a bug, just a "thing that annoys you constantly".
Specifically,
I don't think this has been fixed, or at least I don't remember doing so. It might be a low priority ticket in the backlog that's been sitting for five years, though.
EDIT: I've attached it as a piggyback to another ticket that should get picked up ~soon.
Yeah, I think the tickets to generally improve the script editors didn't capture specifically how bad the custom method editor is about parameters.
I think if I were to revamp this editor today, I'd put a table for parameters (plus description and default values) in place - unless anyone has other fun ideas.
Outside the two examples noted by Nick in the other thread, do you know specific areas where this is needed, or (because of your workaround) is that a question you can't answer?
filterable (on both name and css props [name and value]) style class (with style preview) selector instead of the current huge unfilterable list when selecting style.classes. You could have 200+ style classes and finding anything without filtering is a nightmare
export database query browser resultset to excel (particularly needed for audit log record that have new line, commas, tab character that mess up when you just copy the raw data)
dependency viewer for views
I.e. show the resources that a selected view depends on:
other views (and their chained dependencies)
chained script libraries
session custom props
style classes
css variables, and whether they're coming from a css theme or adv stylesheet
message handlers
and allow exporting them into a project zip - extremely useful for sharing specific views to other projects along with their dependencies)
Extending this, the reverse is also useful -- knowing what views depend on / use a selected view, and hence if that view might be unused (not guaranteed without a "view tracker" similar to the tag reference tracker, due to dynamic references), as well as a full project report for all views (not as useful)
Etc.
I actually don't need any of these as I've already written these tools into a UI accessible from the designer to add these in and more, but it would nice to have them built into the product!
I'm getting ahead of this topic with this one, but I also added a bulk tag security configuration tool that can bulk apply tag security within a tagpath (e.g. an area folder) to the tags within it on a per-UDT type level so that I can apply area-based tag security if needed. For example, if device commands/setpoint tags within "Area 51" can only be written by users with the GovernmentOfficial role who are located within a specific security zone, currently it's a nightmare to roll this out. I can use this tool to list all of the unique UDT types within that folder, select the tags to apply the configuration to (e.g. a valve's OpenCmd and CloseCmd tag) and set the write permissions to require that role and security zone, and apply it to all valves under that area.
Really though, this tool is a workaround to an issue that would be far better solved through IA implementing folder-based security which applies additively to the tags' security beneath it. Then you could leave the UDT instance tag security alone for the most part, and add the security zone and role to the folder security write permissions instead. However, this would need to support overriding this for specific tags under the folder if needed... I do realise that it gets complicated fast
In terms of priority, the style selector and resultset to excel are the most critically needed imo, in particular the style class selector as this is always a pain point when you have 100s of style classes
RE the style selector, for reference, this is what I have at the moment, but I have plans to make it better (would be nice to show an example of the applied styling, add another list on top to show selected styles and move them out of the bottom list, add checkboxes?, not sure what else..):
Filtering on css prop is interesting... The former is a lot easier to do. Obviously it's useful to you, since you added it to your bespoke tool, but I'm interested in group consensus on that.
If we could just give you a 'click style.classes, start typing, it auto-filters <some ui element> by name down to whatever you're typing' - would you say that's "good enough" or do you actually reach for the by-prop reference often?
We are getting better at exporting things to Excel in general, though I'll be honest and say I'd probably recommend using a dedicated DB tool for a lot of stuff. But an interesting idea.
I think we talked about this at some point and it never saw actual prioritization - but again, a solid idea.
I'll be honest and say I haven't used this tool yet as I only recently added it . The name filtering though i've wanted for a long time now. I thought to add CSS prop name and value filtering in case I wanted to be able to filter for example on style classes that include specific props, like gap, background-color, color, font-size, border, etc., or that use specific css variable names. I think this will be more useful if you don't know the project in order to find the styles that set the font-size, for example
I think the simple workflow you mention would service most use-cases though imo.
I agree, but if it's a simple select against the audit log to find who touched something last and get that into excel, it's so much easier from the db tool.
I'm gonna kinda sorta disagree with you on this one because it makes the apply button disappear. I remember getting frustrated when I was a noob because I couldn't get my component scripts to save. I read somewhere that the apply button has to be pressed, but there was no apply button. The script editor opens to the same size it was when it was last closed, so once I had lost the button, it wouldn't come back on its own without restarting the designer.
My simple lock icon works well:
Here is the action listener I use on the button:
# Button Action for locking and unlocking the custom method comments, so they can be edited
class CommentLockControl(AbstractAction):
def actionPerformed(self, event):
if event.source.toolTipText == 'Lock Default Comment Editing':
event.source.toolTipText = 'Unlock Default Comment Editing'
disableCommentEditing(SwingUtilities.getAncestorOfClass(ComponentScriptEditor, event.source))
event.source.icon = ImageIcon(ImageLoader.getInstance().loadImage('Builtin/icons/16/lock.png'))
event.source.revalidate()
event.source.repaint()
else:
event.source.toolTipText = 'Lock Default Comment Editing'
enableCommentEditing(SwingUtilities.getAncestorOfClass(ComponentScriptEditor, event.source))
event.source.icon = ImageIcon(ImageLoader.getInstance().loadImage('Builtin/icons/16/lock_open.png'))
event.source.revalidate()
event.source.repaint()
Actually, I don't believe I ever implemented any scroll bar speed modifications in my designer, so I guess the speeds don't bother me. I know that in the easy chart component, the default scroll speed for tag pens selection is way too slow, so I always speed them up in a much more targeted way when the component initializes using this library script:
def setScrollbarIncrement(easyChart, increment):
# iterate through top level components to get the pen panel
for component in easyChart.components:
if 'PMIEasyChart$PenPanel' in component.__class__.__name__:
# Locate the scroll pane within the pen panel
for subComponent in component.components:
if isinstance(subComponent, JScrollPane):
# Set the vertical scroll bar unit increment to twenty
subComponent.verticalScrollBar.unitIncrement = increment
return
I've thought about building a new Perspective property editor using a RSyntaxTextArea.
I really hate the amount of mouse movements required when setting up Perspective components.
Instead of needing the use the UI for adding and changing properties:
. The name filtering though i've wanted for a long time now. I thought to add CSS prop name and value filtering in case I wanted to be able to filter for example on style classes that include specific props, like 
because it makes the apply button disappear. I remember getting frustrated when I was a noob because I couldn't get my component scripts to save. I read somewhere that the apply button has to be pressed, but there was no apply button. The script editor opens to the same size it was when it was last closed, so once I had lost the button, it wouldn't come back on its own without restarting the designer.
