Hey,

First of all, thanks for making this publicly available. I certainly prefer this one over OAStackView. I really don't understand why people are making a big deal about TZStackView being "redundant"... It's not redundant! It's awesome, currently is more complete (certainly appreciate the drop-in replacement) and it's all in pure swift!

The only thing that's missing is storyboard support, but I understand that you purposely designed it to be that way.

I was just wondering if it would be difficult or a huge task to add storyboard support? I will attempt it and even submit a PR if I manage to implement it/if you're open for PRs, but just thought I'd ask if it would require a significant amount of work? I've never really done that before so any tips would be appreciated. :)

Thanks

The UIStackView documentation specifies rules for the consistency between arranged subviews and subviews.

In short

• Arranged subviews is a subset of subviews so anytime a view is added to the arranged subviews it should also be added as a subview.
• Every time a subview is removed from the stack view it should also be removed from the arranged subviews if necessary.

Currently TZStackView does not conform to these rules. This PR aims to address that. Not all tests pass as it looks like UIStackView has changed since they were originally written (see https://github.com/tomvanzummeren/TZStackView/issues/21) but the tests I've written to verify the consistency worked when ran against beta 4

Just curious if this is being worked on by anyone? May be a pretty simple conversion after Xcode 8's covert tool. (I may give it a shot but I really don't know Swift 😅 )

I know your documentation says that this is not supported, but the use of Interface Builder and UIStackView are not mutually exclusive. There is no reason that I shouldn't be able to put a stack view in an Interface Builder document and use it to manage the auto layout constraints I would have had to write otherwise.

Hello,

First, thanks a lot for your work !

I'm getting this error :

Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'An instance 0x7c15b6a0 of class UILabel was deallocated while key value observers were still registered with it. Current observation info: <NSKeyValueObservationInfo 0x7c170270> (
<NSKeyValueObservance 0x7c12bf90: Observer: 0x7c17a520, Key path: hidden, Options: <New: YES, Old: YES, Prior: NO> Context: 0x7c17a5b0, Property: 0x7c16fd30>

I'm using TZStackView inside a custom UIView for a simple test :

        let v1 = UILabel()
        v1.backgroundColor = UIColor.greenColor()
        v1.text = "efze"

        let v2 = UILabel()
        v2.backgroundColor = UIColor.blueColor()
        v2.text = "efze"

        let v3 = UILabel()
        v3.backgroundColor = UIColor.yellowColor()
        v3.text = "efze"

        container = TZStackView(arrangedSubviews: [
            v1,v2,v3
            ])

        container.setTranslatesAutoresizingMaskIntoConstraints(false)
        container.backgroundColor = UIColor.purpleColor()
        container.axis = .Vertical
        container.distribution = .FillEqually
        container.alignment = TZStackViewAlignment.Fill
        container.spacing = 15


        self.addSubview(container)

This UIView is displayed when the user selects an item in a collectionView (via a NavigationController) and the UIView with the TZStackView is correctly displayed. The error happens when the user click the back button.

Did I do something wrong ? I saw a similar issue (#7) but I'm using 1.0.3 and it is still happening.

Thanks for your help !

I have a UIView that contains few buttons. They are all separated from each other with 8 points space. The buttons have no height constraints.

This view is then added to your stackview and the axis is set to vertical. When I hide the view, it actually set a constraint saying the view should have a height of 0. Then I get an UIViewAlertForUnsatisfiableConstraints error because I have some fixed constraints (8 points gaps) in my view.

What's my solution to avoid those errors?

Thanks.

I'm assuming this is because you changed the codebase to be Swift 2.0. This seems a little pre-emptive as Xcode 7 is still pre-release.

Great project btw, can't wait to use it.

Tristan

Follow-up for issue #19.

Carthage needs to find the xcodeproj and a shared framework target. As such it is impedimental to have multiple xcodeproj files and subprojects, especially when the xcodeproj file has a different name than the Project and no shared framework.

I have a TZStackView hierarchy with a bunch of UILabels in it. They have numberOfLines = 0. The problem is that if I attempt the same code with UIStackView on iOS 9, or TZStackView on iOS 9, the UILabels wrap. However with TZStackView on iOS 8.x, the UILabel is ellipsized. Any thoughts on this?

Overrides the backgroundColor property inherited from UIView to be disabled.

This is in order to mimic an actual UIStackView, which is a non-drawing view, and protect users of TZStackView from becoming reliant on setting a TZStackView's background color. This should be one less surprise for users when they eventually migrate from TZStackView to UIStackView in the future.

This PR represents one possible way to implement Interface Builder support for TZStackView. The strategy taken here was:

1. Make all the necessary parameters configurable through IBInspectable. This is relatively inoffensive (aside from being delicate because Xcode can't have enumerated types as IBInspectable) and makes for a nice addition.
2. At design time, insert nonsense subviews into the hierarchy to preview the behavior of the stack view. At run time, convert any subviews into arrangedSubviews. This is a bit more controversial.

Ultimately, I think this code as it stands is not production ready. However, I think it's a good starting point to discuss how to implement this feature.

I have a crash:

Fatal Exception: NSInternalInconsistencyException
An instance 0x151eabd0 of class UIView was deallocated while key value observers were still registered with it. Current observation info: <NSKeyValueObservationInfo 0x151b6c10> ( <NSKeyValueObservance 0x14384cd0: Observer: 0x151b0090, Key path: hidden, Options: <New: YES, Old: YES, Prior: NO> Context: 0x151b0180, Property: 0x8814fc0> )

In my view I have this code:

deinit {
    stackView.arrangedSubviews.forEach { view in
      stackView.removeArrangedSubview(view)
    }
  }

After investigation I found that method removeArrangedSubview does not call removeHiddenListener. Why?

You are removing listeners by code:

deinit {
        // This removes `hidden` value KVO observers using didSet()
        { self.arrangedSubviews = [] }()
    }

But arrangedSubviews are already empty. Why don't you remove listeners for all listeners in registeredKvoSubviews array?

Here's a quick pass of the Swift 4 conversion we're using in a project. Unfortunately some 'vertical' tests fail. firstAttribute and secondAttribute are traling instead of leading.

TZStackView cannot be subclassed in Swift 3, since the class is public instead of open.

We have to add some additional functionality to this class, so it would be great if you could make this class open. Thanks!