snapkit / snapkit Goto Github PK
View Code? Open in Web Editor NEWA Swift Autolayout DSL for iOS & OS X
Home Page: https://snapkit.github.io/SnapKit/
License: MIT License
A Swift Autolayout DSL for iOS & OS X
Home Page: https://snapkit.github.io/SnapKit/
License: MIT License
Hey,
I just tried to install Snap via CocoaPods but I keep getting this error....
I tried with the default Podfile provided in the README.md
[!] Unable to satisfy the following requirements:
- `Snap (~> 0.9.1)` required by `Podfile`
I also tried to use the develop branch, Snap is installed but the Snap folder in the pod is empty....
So for the moment I did roll back to 0.0.9
any ideas ?
Thanks !
I recently add Snap to my Swift project following README. But got error: [!] The platform of the target Pods
(iOS 7.0) is not compatible with Snap (0.0.6)
which has a minimum requirement of iOS 8.0 - OS X 10.9.
My pod version is 0.36.0. Is this a bug or README Requirements section is outdated?
This snippet:
loginButton.snp_makeConstraints { make in
make.left.and.right.equalTo(UIEdgeInsetsMake(0.0, 10.0, 0.0, 10.0))
make.height.equalTo(100.0)
make.centerY.equalTo(0.0)
}
produces different results then this one:
loginButton.snp_makeConstraints { make in
make.leading.and.trailing.equalTo(UIEdgeInsetsMake(0.0, 10.0, 0.0, 10.0))
make.height.equalTo(100.0)
make.centerY.equalTo(0.0)
}
The latter does not inset the button at all. Any ideas?
In the README, the examples are listed a bit differently than how the swift files are implemented:
public func snp_makeConstraints(block: (maker: ConstraintMaker) -> ()) {
ConstraintMaker.makeConstraints(self, block: block)
}
so essentially would give maker
which reads a bit strangely versus make
:
self.openCameraButton.snp_makeConstraints { (maker) -> () in
maker.bottom.equalTo(self.view.snp_bottom)
maker.left.equalTo(self.view.snp_left)
maker.right.equalTo(self.view.snp_right)
maker.height.equalTo(75)
}
versus the example (and prior Masonry implementation) of:
view1.snp_makeConstraints { make in
make.top.equalTo(superview.snp_top).with.offset(padding.top) // with is an optional semantic filler
make.left.equalTo(superview.snp_left).with.offset(padding.left)
make.bottom.equalTo(superview.snp_bottom).with.offset(-padding.bottom)
make.right.equalTo(superview.snp_right).with.offset(-padding.right)
}
I just wanted to get clarification around which approach you'll be taking.
It doesn't seem like it's currently supported, but apologies if that's incorrect!
This is probably the same issue as #14...
Okay, this could be a newbie issue, and if so, I apologize in advance... but I'm finding that Snappy occasionally gets into a "mode" where the DSL stops functioning in certain cases. It was pretty difficult to describe what I was seeing, so I went ahead and made a quick screencast to demonstrate: http://quick.as/kzjghljy
I'm totally lost. Any help would be appreciated!
Hey guys,
I'm not sure If I just made mistake in integration of Snap in my project, but I get this error when I try to create property of type constraint in one of my classes.
I use snap on other places and it works well, but now I need to reference particular constraint. Any ideas what might be wrong?
I followed instructions for integrating snap in read me of this repository.
Thanks for help.
I followed the installation instructions in the README, but it did not get included until I added import Snappy
in my AppDelegate.swift
.
I'm not sure if this is a mistake in my part, a change in XCode, or a step that is missing from the README.
I'm working just locally at the moment but brought a similar fork of mine up to speed and actually working, in the progress I've come across some unfortunate quirks for operator overloading:
To rework something like (v1.left.top.right == v2) + UIEdgeInsets(5, 5, 5, 5)
to v1.left.top.right == v2 + UIEdgeInsets(5, 5, 5, 5)
we have to operator overload +
on UIView which starts to get a bit unfortunate.
Priorities typically would always be set last using the Objective-C DSL but with the new DSL we must specify the priority like first like v1.left == v2.priority(500) + 50
or use parans like (v1.left == v2 + 50).priority(500)
. The only other option for this to make it nice and clean would be using a different operator just for priorities. I'm currently using ~
so it looks like v1.left == v2 + 15 ~ 749
but we really start to lose code readability going this far.
Since CocoaPods 0.36.0.beta.1, it's possible to make a swift framework - http://blog.cocoapods.org/Pod-Authors-Guide-to-CocoaPods-Frameworks/
I saw that you removed and
and with
as well as created a new ConstraintDescriptionExtendable
class.
My question is: before this was allowed:
view.snp_updateConstraints { make in
make.top.offset(tableFooterY)
}
How are you planning to support updating a constraint like this?
So Cocoapods support looks a ways off, mostly because Xcode still doesn't really support static libs for Swift.
External compiled Swift libraries need two pieces to work properly. The first is obviously the code which is either going to be a static (.a) or dynamic (.dylib, .framework). The second is a companion .swiftmodule for each arch inside the code library.
While Xcode doesn't support compiling static libraries for Swift yet:
I've managed to successfully use the above to get a working static library that can compile into an iOS target and run.
Caveats:
With a bit of luck I'll have this done tomorrow!
The uninstall()
function is marked as internal, so it can't be used to remove a temporary constraint I have for animation. Is this intended?
I added Snap.xcodeproj
as a sub project to mine and linked Snap.framework
to my targets.
Some people have desired/requested the ability to use Snappy from Objective-C goal. In the end this would likely just mean the merging of Masonry and Snappy in a clean fashion.
For now support for using Snappy from Objective-C is nearly complete in the develop branch.
Only takes a couple of small changes to ConstraintAttributes for it to comply with BitwiseOperationsType.
RawOptionSetType, BooleanType
static var allZeros : ConstraintAttributes { return self(0) }
That's it.
is anyone have sample executable app with this library?
Having followed installation directions to the letter, Snappy.framework remains red-colored in Embedded Binaries and Linked Frameworks and Libraries. (This is after successfully building Snappy as a subproject of my root project.)
Any troubleshooting advice? I tried cleaning / restarting / deleting Derived Data.
Snap has a Microsite on the way!
I am getting different results when I do this:
view.snp_makeConstraints { make in
make.bottom.and.leading.equalTo(superview).with.insets(UIEdgeInsetsMake(0.0, 10.0, 10.0, 0.0))
return
}
vs. this:
view.snp_makeConstraints { make in
make.bottom.and.leading.equalTo(UIEdgeInsetsMake(0.0, 10.0, 10.0, 0.0))
return
}
On the bottom side it is treating the second snippet as an offset rather than an inset. Masonry behaved differently. Any ideas?
:(
gxw-MacBookAir:~/Documents/codes/vcam (rtp_stream *) $ pod install
Analyzing dependencies
Fetching podspec for `kxmovie` from `./kxmovie`
[!] The platform of the target `Pods` (iOS 7.0) is not compatible with `Snap (0.0.2)` which has a minimum requirement of iOS 8.0 - OS X 10.9.
gxw-MacBookAir:~/Documents/codes/vcam (rtp_stream *) $ pod --version
0.36.0.beta.1
I've spent most of tonight porting nearly the entirety of Masonry to Snappy in a fork here: https://github.com/robertjpayne/Snappy
There's a couple of major things I changed which I'm not really sure pros/cons:
NSLayout*
The goal here was to allow us to harden the code base and not allow users to use new features in auto layout when it's not yet been coded in for support as well as be able to build better debugging when it comes to logging etc…
For instance iOS 8.0 allows a lot of new attributes and sorts that are not currently supported but also cannot be mistakingly used or have to be coded in.
Constraint
class and ConstraintItem
I took a look at Composite Constraints and from my point of view the only added feature over ViewConstraint is the ability to have more than 1 layout attribute on the left hand side.
Instead I deduced the classes into one and use a new ConstraintItem
(which was sorta ViewAttribute) which houses the item and the attributes.
Rather than use an array of NSLayoutAttribute's I've defined a ConstraintAttributes
options set which acts like a bitwise mask. This allows edges/size/center to be better first class citizens.
So I'm not really sure what bits we may want to merge or take or what not, @cloudkite maybe we could discuss I'd love to contribute I was only simplifying to help reduce the amount of code and make it easier to follow.
This is a (imho) pretty important design decision: What operators do we use for expressing constraints?
There are basically three different kinds of operators needed. One for expressing the kind of relationship, another for the factor and one for the constant.
For factor and constant, I would say that *
, /
and +
, -
are simple and good choices, since they express perfectly well what they are supposed to do.
For the kind of relationship I am not sure.
We could use ==
, <=
, >=
. These are understandable, but have (again, imho) one problem: They are seldom, if ever, used to do something. Usually, they are always only used to test for something, and do not, in and of themselves perform any action (such as creating a constraint).
So the alternative is to come up with another set of operators different from the comparison operators, and thereby make it clear that these are not normal comparisons and do in fact do something.
I think what this decision boils down to is the following question:
Does the programmer describe a set of checks that the system then tries keep true, or does he explicitly create constraints? Does he say "this attribute should always be equal to that attribute" or does he say "make this attribute equal to that attribute"?
PS: If we choose to invent new operators, we have these characters to play with: / = - + * % < > ! & | ^ . ~
, and I would say it'd be a reasonable choice to take ==
, <=
, >=
and prefix them with one of those characters.
How a view can be aligned to self.topLayoutGuide or bottomLayoutGuide?
I couldn't figure out how to change the priority of an already installed constraint.
Changing the priority of an NSLayoutConstraint
is a cheap operation, and using a combination of priorities and .LessThanOrEqual
+ .GreaterThanOrEqual
for animations is what Apple suggests.
It may even be nice to add some wrapper for this. You'd install
x ≦ 40
x ≧ 40 with priority P
x ≧ 20 with priority P + 1
and you'd then be able to switch x between 40 and 20 by changing the priority on the last constraint between P - 1
and P + 1
.
Looks like a great solution, would be awesome to be kept up to date by a CocoaPod.
Is there a way to use the library in iOS7?
first this:
draftsSiteManagement?.snp_makeConstraints { make in
make.size.equalTo(self.view).with.insets(padding)
make.top.equalTo(107)
make.left.equalTo(self.view.snp_right)
}
then this:
draftsSiteManagement?.snp_updateConstraints({ make in
make.left.equalTo(self.view)
return
})
2015-03-26 20:35:31.701 The Grid[39296:6389862] Unable to simultaneously satisfy constraints.
Probably at least one of the constraints in the following list is one you don't want. Try this: (1) look at each constraint and try to figure out which you don't expect; (2) find the code that added the unwanted constraint or constraints and fix it. (Note: If you're seeing NSAutoresizingMaskLayoutConstraints that you don't understand, refer to the documentation for the UIView property translatesAutoresizingMaskIntoConstraints)
(
"<NSLayoutConstraint:0x7fc7f49a58e0 'UIView-Encapsulated-Layout-Width' H:[UIView:0x7fc7f279d880(375)]>",
"<Snap.LayoutConstraint:0x7fc7f48e2340 H:[UIView:0x7fc7f279d880]-(0)-[The_Grid.DraftsSiteManagementView:0x7fc7f4a2d5e0](LTR)>",
"<Snap.LayoutConstraint:0x7fc7f27a0210 H:|-(0)-[The_Grid.DraftsSiteManagementView:0x7fc7f4a2d5e0](LTR) (Names: '|':UIView:0x7fc7f279d880 )>"
)
Will attempt to recover by breaking constraint
<Snap.LayoutConstraint:0x7fc7f48e2340 H:[UIView:0x7fc7f279d880]-(0)-The_Grid.DraftsSiteManagementView:0x7fc7f4a2d5e0>
Make a symbolic breakpoint at UIViewAlertForUnsatisfiableConstraints to catch this in the debugger.
The methods in the UIConstraintBasedLayoutDebugging category on UIView listed in <UIKit/UIView.h> may also be helpful.
remakeConstraints does not behave correctly since cf977c5 or 0b92c7f. I cannot really tell because the former does not compile.
I cannot really understand what goes wrong, but some constraints don't seem to be applied correctly. If it makes any difference for those views I only used remakeConstraint and not makeConstraints for the first time.
Please let me know if I can provide you with anything to help resolve this issue.
We use TestFlight with internal testers to deploy daily builds of the app, and today's build was rejected. Apparently, Snappy calls those private APIs:
allocBatch:withEntity:count:
allocWithEntity:
fastIndexForKnownKey:
indexForKey:
Searching for those functions through the source code did not yield any results, so it probably is an indirect API usage, but I can't figure out what it is.
Using Xcode 6.1, deployment target is iOS 8.0.
If I hang onto a constraint like:
var leftConstraint: Constraint?
let padding = UIEdgeInsetsMake(107, 0, 0, 0)
draftsSiteManagement?.snp_makeConstraints { make in
make.size.equalTo(self.view).with.insets(padding)
make.top.equalTo(107)
self.leftConstraint = make.left.equalTo(self.view.snp_right)
}
}
How would I update the constant later?
Just making sure this isn't missed.
Is there a way to do an animation with the POP framework and snap like https://github.com/miklselsoe/MSSPopMasonry ?
Do you have any examples updating and animating constraints? I've applied the same approach I used with Masonry but I'm not seeing anything happening.
This is the first step to providing more robust update functionality. Right now one has to learn by a bit of trial and error what API's can be used during the chaining process.
For instance right now one can actually do something like:
make.top.equalTo(50).right.equalTo(60)
which while seems like it should work wont work at all and only has subtle errors. Rather I'd like to via protocols completely prohibit one from even using methods that are should not be available for their current chaining step.
Hello,
I might be overlooking something but cant figure out how to do proportional width / height constraints. I.e. view1 height is 50% of view2 height. Is this supported by Snap?
Hey there, I'm curious to know if Snappy will accomplish my needs. I'd like to have a list of stacked UIView's that fill the width of the screen, each having a dynamic height, and each being seperated by 10 points apart from each other. AKA, something like Facebook's News Feed. Thanks!
Hi,
Your readme says it is compatible with 7.0 but your podspec says 8. Could you please update one of the two. Cheers!
Snappy is not building anymore in Xcode 6 beta 6. Something about RawOptionSetType not implementing Boolean anymore. I found something about that in the release notes. No idea how to solve it. :-)
Could you please add Snappy record for cocoa pods ?
In Masonry, we have the option to makeConstraints
, remakeConstraints
, and updateConstraints
. In Snappy, we can no longer updateConstraints
. It would be nice to still have this functionality.
Hi guys. I have updated my SnapKit submodule so it points now to d44a9be. It's all working fine (had to update code a little bit), but only on iOS7, only in release configuration and only when running on device (not on simulator) it crashes right away. Here is a screen shot of what we have in Fabric https://www.dropbox.com/s/nkecb8lgoh1sfmi/Screenshot%202015-04-18%2014.43.07.png?dl=0
and here is the code that calls it
but even when i remove that part it crashes on some another one.
Could you please give me and advice on this?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.