Creating a user setable module front skin gets common more and more. But there is still a problem for manufacturers: Unfortunately there isn't any method to change it's color. One can overlay it with an image, a label or rectangle. But all these objects will cover the screws.
And in the end it seams one has to use complete front images. That makes it really a hard work, when at least only a control is added or moved, because all labels have to be moved too within all externally created skin images.
It should be possible to create variable module fronts even with VMD.
So my requests:
1. Let VoltageRectangles' Z value be between modules front and screws, even when they are not marked as "is background object".
2. Provide a method to set module front color.
Sometimes SetGlobalProperty() and SetManufacturerProperty() are used to switch common properties as skins and colors and others.
Once these properties are set, they will stay as data trash in the system forever even when they are not needed anymore.
3. In order to keep the system "clean", methods as "RemoveGlobalProperty()" and "RemoveManufacturerProperty()" could be used to remove old stuff.
Best Regards
Roland
Feature request for module front properties
Re: Feature request for module front properties
You can probably clean up the properties by manual editing of the XML files in AppData\Roaming\Voltage\Settings (on a PC) though I wouldn't worry too much about clutter as you shouldn't use properties in any time-critical code anyway.
Skinning is something I've looked at before and am doing so again at the moment. There are multiple problems.
There ought to be some basic API support but there isn''t any. The only real access is to use a VoltageCanvas and to grab an AWT Graphics2D interface.
A nasty problem is the yellow selection outline mysteriously being drawn BEFORE the rest of the GUI instead of after.
Here's the drawing order as best as I can establish...
1. Background image or solid color specified in VMD Module Properties
2. Any GUI elements with "Is Background Object" checked
3. The yellow selection outline
4. Other GUI elements in Z-order - although VDM simply rearranges the initialisation order of elements when you use right click Bring Forward, Send Backwards etc. Presumably as an optimization so that only if an element has SetZOrder() called on it is a Z sort done.
However, SetZOrder() doesn't work as one would expect. You have to make calls to it with ascending z orders for it to work properly.
rectangle0.SetZOrder( 4 );
rectangle1.SetZOrder( 3 );
rectangle2.SetZOrder( 2 );
rectangle3.SetZOrder( 1 );
...doesn't work but...
rectangle3.SetZOrder( 1 );
rectangle2.SetZOrder( 2 );
rectangle1.SetZOrder( 3 );
rectangle0.SetZOrder( 4 );
...does, even though both should give the same result.
### EDITED: I just checked this z-order thing again and it seems to have been fixed since I last tested it.
Also the yellow selection outline is only a problem in the VMD test client, it works OK in VM proper. ###
Other probems I've encountered in customization include there being no apparent way to change behaviour involving the move handle at the top of the panel or to extend the right-click menus.
Skinning is something I've looked at before and am doing so again at the moment. There are multiple problems.
There ought to be some basic API support but there isn''t any. The only real access is to use a VoltageCanvas and to grab an AWT Graphics2D interface.
A nasty problem is the yellow selection outline mysteriously being drawn BEFORE the rest of the GUI instead of after.
Here's the drawing order as best as I can establish...
1. Background image or solid color specified in VMD Module Properties
2. Any GUI elements with "Is Background Object" checked
3. The yellow selection outline
4. Other GUI elements in Z-order - although VDM simply rearranges the initialisation order of elements when you use right click Bring Forward, Send Backwards etc. Presumably as an optimization so that only if an element has SetZOrder() called on it is a Z sort done.
However, SetZOrder() doesn't work as one would expect. You have to make calls to it with ascending z orders for it to work properly.
rectangle0.SetZOrder( 4 );
rectangle1.SetZOrder( 3 );
rectangle2.SetZOrder( 2 );
rectangle3.SetZOrder( 1 );
...doesn't work but...
rectangle3.SetZOrder( 1 );
rectangle2.SetZOrder( 2 );
rectangle1.SetZOrder( 3 );
rectangle0.SetZOrder( 4 );
...does, even though both should give the same result.
### EDITED: I just checked this z-order thing again and it seems to have been fixed since I last tested it.
Also the yellow selection outline is only a problem in the VMD test client, it works OK in VM proper. ###
Other probems I've encountered in customization include there being no apparent way to change behaviour involving the move handle at the top of the panel or to extend the right-click menus.
Re: Feature request for module front properties
Hi Colin,
these hints are useful. Thanks.
I'seen that yellow module selection border becomes almost invisible, when module front is overlayed by other objects. Is that the reason that
you are managing this frame yourself instead of the VM managed one? - It looks to me, you're doing so with drawing step 3.
Roland
these hints are useful. Thanks.
I'seen that yellow module selection border becomes almost invisible, when module front is overlayed by other objects. Is that the reason that
you are managing this frame yourself instead of the VM managed one? - It looks to me, you're doing so with drawing step 3.
Roland
Re: Feature request for module front properties
The problem with the yellow outline now only occurs in the VMD test client. I think it used to occur in VM proper too but now I'm wondering if it only ever occured in VMD. It might be something that got fixed in an update by CA or I could have been mistaken.
The problem being that a component such as a rectangle, image or canvas that occupied the entire module's space obscured the yellow selection outline that VM draws around the currently selected module. So you couldn't tell that a module was selected.
The Skin mechanism in LSSP works by having the "classic" background as the default background image set in VMD Module Properties. Then if "plain" is selected in the Skin module this is communicated to all LSSP modules via manufacturer properties and they enable visibility of a low z rectangle with xywh = 2, 2, width - 4, height - 4 so that there's a 2 pixel gap around the edges. Therefore it doesn't obscure the yellow selection outline. BUT this means that a 2 pixel wide strip of the classic background shows through around the edge when a module isn't selected.
I couldn't do it the other way around with the background being plain and the classic background being an image that is painted on top because you can't change the color of the background and there'd still be a "wrong" 2 pixel border when in classic mode anyway.
But as I now see that the problem doesn't occur in VM proper I can change the xywh to 0, 0, width, height. I'll release this change for the Chord, Chord Memory and 8 to 1 Poly Switch as soon as they are approved (as these are bundled with GS and N-Step) but I'm waiting on the rest of the LSSP modules because I might do a new version of Skin when I've finished my current research for skinning my next big project.
If there were API calls such as SetBackgroundColor() or SetBackgroundImage() we could avoid having to have a rectangle, image or canvas floating on top of the background and it would be more efficient.
The floating mechanism as well as requiring a redraw also obscures any elements with "Is Background Object" checked so these need to be rendered live on each redraw event instead of just once on module initialization.
But it's unlikely that the API will change anytime soon so there isn't any other option if you want skinning.
The problem being that a component such as a rectangle, image or canvas that occupied the entire module's space obscured the yellow selection outline that VM draws around the currently selected module. So you couldn't tell that a module was selected.
The Skin mechanism in LSSP works by having the "classic" background as the default background image set in VMD Module Properties. Then if "plain" is selected in the Skin module this is communicated to all LSSP modules via manufacturer properties and they enable visibility of a low z rectangle with xywh = 2, 2, width - 4, height - 4 so that there's a 2 pixel gap around the edges. Therefore it doesn't obscure the yellow selection outline. BUT this means that a 2 pixel wide strip of the classic background shows through around the edge when a module isn't selected.
I couldn't do it the other way around with the background being plain and the classic background being an image that is painted on top because you can't change the color of the background and there'd still be a "wrong" 2 pixel border when in classic mode anyway.
But as I now see that the problem doesn't occur in VM proper I can change the xywh to 0, 0, width, height. I'll release this change for the Chord, Chord Memory and 8 to 1 Poly Switch as soon as they are approved (as these are bundled with GS and N-Step) but I'm waiting on the rest of the LSSP modules because I might do a new version of Skin when I've finished my current research for skinning my next big project.
If there were API calls such as SetBackgroundColor() or SetBackgroundImage() we could avoid having to have a rectangle, image or canvas floating on top of the background and it would be more efficient.
The floating mechanism as well as requiring a redraw also obscures any elements with "Is Background Object" checked so these need to be rendered live on each redraw event instead of just once on module initialization.
But it's unlikely that the API will change anytime soon so there isn't any other option if you want skinning.
Re: Feature request for module front properties
The yellow frame problem didn't appear to me until now, because I did not use full format objects on modules front yet. I think, that frame is done as a VoltageRectangle border. And that grows to rectangle center when it's thickness is enlarged. That confused me first because I assumed it would grow to outside as borders do for HTML elements.
These pictures shows, that select frame consists actually of two borders with two and one pixel thickness.
In VMD that frame gets hidden by the black rectangle, in VM it does not.
At the moment I don't plan to renew all module's skins, but I will allow skin changes for next ones.
These pictures shows, that select frame consists actually of two borders with two and one pixel thickness.
In VMD that frame gets hidden by the black rectangle, in VM it does not.
- 20230505_select_frame_in_VMD.jpg (6.28 KiB) Viewed 1823 times
- 20230505_select_frame_in_VM.jpg (1.52 KiB) Viewed 1823 times