I'd like to be able to override properties on Masters and then have (at least) my overrides appear on the subcomponents

[rickmcgeer]

So this issue came up when I wanted to have a master "close window button' component, since this is something I do a lot. So I got a dark button, and set its label to be the icon 'close-window', tooltip to be "Close Window', and tooltip on label to be Close Window. When I copy the component, the label reverts to "a button". Which I understand; that's the label on the original master. But I can't seem to find a way to override that and make the default label the close-window icon for morphs that use this as a master

[merryman]

This is more a problem with Buttons themselves than the master component. By directly changing the label of the button, you have bypassed the label property of the button, which is not a derived property, but stores the label info locally. I have tried to change this into a fully derived property which would get rid of this issue but it for some reason always creates problems. I will investigate this and come back with a PR that solves this.

[merryman]

Coming back to this, it recently occurred to me what the underling issue here is: We have two conflicting interfaces that are not aligned and can therefore lead to inconsistent results in the system. Interface 1 is the programmatic interface of a button which essentially encapsulates the buttons submorphs and just exposes a custom property (here label) to be used by the programmer for convenience. Now technically the programmer can still bypass said interface by directly mangling with the label morph and arguably in the very simple case of a button that may likely happen, but the interface itself promotes a different approach (just using the label prop instead of button.submorphs[0].textString). On the other hand Interface 2 is the visual direct manipulation interface that as of now does not support or convey said scoping (This is also the interface the master components use, so this is where we close the loop). You can just as easily manipulate the label directly as you can decide to use enclosing derived properties. This is because the Direct manipulation interface is not aware of the programmatic encapsulation and breaks it. Solving this issue means essentially aligning these two interfaces. We can either remove said derived prop entirely and force a programmer also to use the cumbersome button.submorphs[0].textString (and similar problems arise with a buttons fontColor, fontFamily etc...) or we can think of a mechanism that prevents the designer from bypassing the interface by restricting the system to directly change the contents/fontColor/fontFamily of the button label via halo, instead utilising a custom property control in the side bar. Both have pros and cons and enter the bigger question: how do we expose programmatic abstractions that can be broken by the designer to the designer without obstructing their workflow? Put bluntly in another example: If an input field is tied up to a variety of control flows essential to a tool, should the designer be able to delete it?

I may open up a discussion on this issue. However my current answer is that we actually do the former approach and solve the inconvenience for the programmer by not having to touch the visual properties in the general case. What that means is, the derived properties like label color, label font etc should not be necessary since the programmer will not directly set those at all in the general sense but just make use of the master components the designer prepares. Data driven props like label can then be replaced by update routines that project the view model state onto the component structure devised by the designer. The designer essentially limits the variation of custom behaviour they have to deal with and neither should they. 99% of the time the designer does not want behaviour to obstruct the design process (like clicking a button invoking a change in the UI that is being worked on).