I have a VStack nested inside of an HStack that I want to take up 35% of the safe area width. So far through beta 3 I've been able to do the by:
HStack {
VStack {
.
.
.
}.relativeWidth(0.70)
}
But I now have a warning that:
'relativeWidth' is deprecated
That's it. Nothing about what to use as a replacement. In fact, the documentation hasn't yet marked it as deprecated.
Any ideas on what I can use as an alternative? GeometryReader? It seems that that is overkill. (I know, relativeWidth still works, but I prefer removing all warnings if possible.)
Yes, it is deprecated. The release notes say:
The relativeWidth(:), relativeHeight(:), and
relativeSize(width:height:) modifiers are deprecated. Use other
modifiers like
frame(minWidth:idealWidth:maxWidth:minHeight:idealHeight:maxHeight:alignment:)
instead. (51494692).
Your only alternative seems to be GeometryReader :-(
Related
How do I fix this? The recommended fix just causes more problems. I have code in another project where this exact same scenario works but when I'm applying it to this project I get an error I've never seen before. Am I missing something? Thanks
Figured it out it had something to do with the function buttonhit. Once I fixed it, it works now
Write the Image and both Text in VStack in the Navigation Link.
Following part 3 of Apple's tutorial on SwiftUI, Handling User Input, I get this error:
Unable to infer complex closure return type; add explicit type to disambiguate
I'm using the same code as the tutorial (even coping from the 'Complete' sample code doesn't resolve the error).
Does anyone have a cue what is going wrong here?
struct LandmarkRow: View {
var landmark: Landmark
var body: some View {
HStack {
landmark.image(forSize: 50)
Text(verbatim: landmark.name)
Spacer()
if landmark.isFavorite {
Image(systemName: "star.fill")
.imageScale(.medium)
}
}
}
}
Regardless of the cause of the issue, how could you indeed add an explicit type to disambiguate here? What would the return type in such a case be?
--
Update
Apparently you should not continue with your result of the 2nd tutorial with the 3rd. Some things changed in between of the tutorials that is not documented in the tutorial. I've added the project files to Github so you can check out the diff.
It's better to start the 3rd tutorial fresh with a fresh download of the Project files of the 3rd tutorial.
The issue is not with the closure, but with the isFavorite property on landmark.
It is not declared on the Landmark type, and the compiler instead of showing the undeclared property error, unable to resolve the stacks build closure return type, so it shows and error there.
Great job Apple tutorial writers and even better one Xcode11 compiler.
To fix:
Declare isFavorite variable on the Landmark type.
Make sure you update the landmarkData.json for every landmark record with the isFavorite = false entry, otherwise the app will crash at runtime.
Some background to this problem
Like #dirtydanee already answered there is a difference between those two tutorials. But the problem behind the problem is that while it looks like you're doing a configuration it's actually just functions nested in functions using generics and protocols to "magically" parse everything into a compiling function.
However conformance to these generics and protocols need to be pretty precise because if not the whole tree of functions cannot compile anymore. But it's hard to determine for the compiler what conformance actually failed. This is why you see an error at the top rather than at the point where it actually happens.
It's strongly advised to make sure your views are decomposed into natural and simple blocks so you're not pouring over hundreds of lines of View code to find that one bug.
Dave DeLong had a really great talk about how to compose Views from ViewControllers that still holds true until today: basically you never use View as a subview inside another View but you need to decompose your View of many, simple Views. Otherwise these errors'll drive you nuts.
For people getting this error on SwiftUI and looking for a way to debug their view stack
This error happens mainly when there is a compilation issue on one child View.
1 - Make sure your parent view can support multiple subviews (VStack, ZStack) and you have less than 10 subviews. Sometime you may want to add a Group wrapper.
2 - If this is not the problem, there is probably an issue with one subview. Try to isolate the one you suspect to have the issue. Usually I copy the subview into a property and a different error appears
var debug: some View {
MyViewWithError(property: self.property)
}
Most of the time you'll encounter this because you pass the property (self.property) instead of a binding (self.$property)
Hope this can help some people
I have run into this error when made a typo. Also this error appears when a code has syntax issues. Just check if your changes are correct
I encountered the problem in a subview where a #Binding prop was of a different type of the #Binding source.
I just tried to install the latest version of Realm (2.1.0) for Swift 3 and I'm getting an error on this line: let realm = RLMRealm(path: databasePath) - DataManager.swift:258:21: Argument labels '(path:)' do not match any available overloads
The declaration of the argument is here:
var databasePath : String
I know that swift 3 is requiring label for the first argument, but I've looked everywhere for the replacement and can't find an answer.
+ [RLMRealm realmWithPath:] was an API that was deprecated and entirely removed from Realm many months ago. It was replaced with + [RLMRealm realmWithConfiguration:], where you supply an RLMRealmConfiguration object with the file path to the target file set in its fileURL property.
let configuration = RLMRealmConfiguration.defaultConfiguration()
configuration.fileURL = URL(path: databasePath)
let realm = RLMRealm(configuration: configuration)
On a side note, unless you've got a specific reason for using the Objective-C version of Realm in Swift, I highly recommend you use the native Swift version of Realm instead. That one should be a lot easier, and feel a lot more natural in Swift 3. :)
I'm trying to configure clang-format so that usually braces will start on their own line:
void func()
{
if (...)
{
printf("Ta Da\n");
}
}
But I want it to be so when braces are empty, it will be kept in a single line. (Mainly used for ctors):
Bar::Bar(int val):
_val(val)
{}
currently it will look like this:
Bar::Bar(int val):
_val(val)
{
}
Any ideas?
(Edited to make the situation clearer)
UPDATE: Hurray! It is now possible with Clang 5.0 or later with custom BreakBeforeBraces.
See SplitEmptyFunction in the documentation.
Configuration example:
BreakBeforeBraces: Custom
BraceWrapping:
SplitEmptyFunction: false
↓↓↓ Original answer (outdated) ↓↓↓
Unfortunately, it is not possible to achieve with Clang 4.0 the current clang-format options (as of Clang 4.0).
Source: I had the same question. After studying every documented option, and many tweaking attempts, I could not achieve this. In my experience, clang-format is just not as flexible as one would hope. As soon as you want to step out of the predefined styles and tweak things to your liking, it just does not cut it.
I used combination of
"AllowShortFunctionsOnASingleLine": true,
and
"BreakBeforeBraces": "Allman",
to get it to one line when declaring empty constructors etc..
I was reading the GTK+ 3 reference about the function gtk_button_new_from_stock. There is this part:
gtk_button_new_from_stock has been deprecated since version 3.10 and
should not be used in newly-written code. Use
gtk_button_new_with_label() instead.
Then, I read the reference about gtk_button_new_with_label(), but there is no word about the possibility of creating a button from stock.
I've tried using
gtk_button_new_with_label("gtk-media-play");
but I only get a button with the label gtk-media-play.
Any way, when I use
gtk_button_new_from_stock("gtk-media-play");
I obtain what I want but I have also a lot of warnings about deprecation.
How do I use the suggested function gtk_button_new_with_label in order to obtain a button with stock image?
How can I solve this situation without using deprecated functions?
Stock items in general have been deprecated. You probably want new_from_icon_name() instead (I think the documentation should actually refer to that). There's a standard for icon names.