![]() And although the NSColorWell showed newly selected colors, the background remained stubbornly blue. As suggested to me, I added a background modifier to set the background of a portion of the view to the selected color. This is in the Form tab of the UI Samples window. However, the actual var selectedColor value is never mutated in this process beyond the initialized value of NSColor.blue. When the NSColorWell color is changed, it does change the color of the EmbeddedColorWell view. The selectedColor is initialized to NSColor.blue and used to set the color in the NSColorWell view. ![]() I noticed that the selectedColor in the EmbeddedColorWell is not being mutated and is not being used in a two-way manner. I thought this was working properly, but then I got this email: In the User Interface Elements section of the series, I used NSViewRepresentable to embed a standard NSColorWell in a SwiftUI view. The previous two changes have been more a matter of style, but this one is a real error that would stop an app working as it should. This seems to me a much better solution as it sets the correct thread once when the publisher is created and makes using it much cleaner and easier. flipImage)Īnd the onReceive modifier can toggle the imageIsFlipped flag directly, without having to worry about the thread. Private let flipImageMenuItemSelected = NotificationCenter. The sheet view could then toggle this to make the parent view dismiss it. My original technique passed the Boolean that triggered the sheet to appear, as a Binding to the sheet view. Paul Hudson of Hacking with Swift explains how to use both methods very clearly in his article on How to make a view dismiss itself. ![]() This way you don’t need to pass presentation bindings to your sheet views. Just wanted to add that in part 2 when dismissing sheets there are two ways to do that, one of them is the one that you figured out and the other is to have the view dismiss itself by grabbing its PresentationMode from the environment. I just read your series on writing Mac apps with SwiftUI. The relevant sections in the original posts will have links to the fixes suggested here, but I decided it was easier to list the changes in a separate post, rather than asking people to re-read the whole series looking for modifications. Some of the responses I got were pointing out different or better ways to do things, so I am going to list them here, adding to this post as I get new information. It was received very well and revealed that there is still a large amount of interest in programming for the Mac. I would like to thank everyone who contacted me about this series. Last year, I wrote a 3 part series of articles on using SwiftUI to build a Mac app.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |