Giter Site home page Giter Site logo

snapkit / snapkit Goto Github PK

View Code? Open in Web Editor NEW
19.7K 390.0 2.0K 2.82 MB

A Swift Autolayout DSL for iOS & OS X

Home Page: https://snapkit.github.io/SnapKit/

License: MIT License

Swift 99.51% Ruby 0.49%
auto autolayout snapkit swift xcode dsl cocoapods constraints layout ui

snapkit's People

Contributors

3lvis avatar aleffert avatar bchrobot avatar bendjones avatar brittonmobile avatar charleshkang avatar cloudkite avatar cnoon avatar colinta avatar devxoul avatar eralpkaraduman avatar freak4pc avatar gitpark avatar jctrouble avatar kwakueshun avatar linusu avatar livincent-zhang avatar raylillywhite avatar reflejo avatar robertjpayne avatar rohan-panchal avatar romanpodymov avatar ryanmaxwell avatar sebreh avatar sger avatar tadeaskriz avatar tanaschita avatar uny avatar wolffan avatar yunhao avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

snapkit's Issues

CocoaPods fails with Snap 0.9.1

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 !

Snap does not support platform iOS 7.0

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?

Formulate better plan for leading/trailing and insets

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?

make versus maker

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.

Support animation

It doesn't seem like it's currently supported, but apologies if that's incorrect!

This is probably the same issue as #14...

Basic functionality not working in certain cases

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!

Use of undeclared type Constraint

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.

Does not get included without "import Snappy"

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.

Operator Overloading downsides

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.

About new changes

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?

Cocoapods Support

TL;DR Snappy will have a compatible podspec soon regardless of Cocoapods real support for Swift

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:

  • When compiling a .framework the compiler emits intermediate .o files just like Objective-C code.
  • When compiling a .framework the compiler emits .swiftmodule files for each arch
  • You can combine these .o files into a .a static library
  • You can use the .a in conjunction with the .swiftmodule files and a few other things from the output .framework and link it and use it in code completion etc.

I've managed to successfully use the above to get a working static library that can compile into an iOS target and run.

Caveats:

  • The podspec will likely come with a pre-compiled .a file. The setup and scripts needed to generate it is beyond the scope of what Cocoapods supports currently.
  • The podspec will only be compatible with a single version of Xcode. Because Swift's runtime is bundled in at compile time all external Swift code bases must be compiled with the same version of Xcode to avoid any conflicts.

With a bit of luck I'll have this done tomorrow!

uninstall() is internal

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.

Allow using Snappy from Objective-C code

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.

Support for beta 6

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.

Snap is crashing on Swift 1.2

I'm trying to debug the cause but you can see it crashing just by doing:

        let view = UIView()
        self.view.addSubview(view)

        view.snp_makeConstraints { make in
            make.edges.equalTo(self.view)
        }

screen shot 2015-02-09 at 8 13 32 pm

Unexpected behavior when applying composite insets

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?

cocoapods 0.36.0.beta.1 can't install with ios 7.0

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

Working version of Snappy!

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:

Abstracted away all of 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.

Single 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.

Left to do:

  • There's a potential memory leak if you manually uninstall single constraints
  • There's no support for updateConstraints yet ( easy enough just I hardly ever use it and didn't get around to it tonight )
  • Bring back in delegate

Wrap

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.

What operators should the DSL use?

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.

Change priorities

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.

Podspec request

Looks like a great solution, would be awesome to be kept up to date by a CocoaPod.

snp_updateConstraints, simply updating the left constraint throws error

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 broken

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.

Snappy uses private APIs, can't submit to App Store

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.

screen shot 2014-10-16 at 16 19 22

Updating Constraint contant?

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?

Animating constraints

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.

Tighten what API's are available on a Constraint via Protocols

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.

Question: proportional width / height

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?

How to implement a list of UIViews

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!

Swift Compiler Warning

Another thing to investigate when the time comes!

"Umbrella header for module 'Snap' does not include header 'Snap-Swift.h'
screen shot 2015-02-11 at 09 23 01

iOS 7.0 & Cocoapods

Hi,

Your readme says it is compatible with 7.0 but your podspec says 8. Could you please update one of the two. Cheers!

Xcode 6 beta 6

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. :-)

SnapKit 0.10.0 crash on iOS7 in release on device

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

screenshot 2015-04-18 14 44 25

but even when i remove that part it crashes on some another one.

Could you please give me and advice on this?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.