Merge 0.9 Version Dev Branch to Master #109
Conversation
Split out sectioning behavior from `ModelCollection` into `SectionedModelCollection` to simplify all the model collection code that only needs to support a single section.
• Basic setup with Pilot dependencies, config files, and on-disk organization.
• Also added bare bones root window controller & view controller to mac.
• Added proper sidebar selection style. • Added basic navigation action and router handling. • Added basic Example MVVM stack for the content list.
- Xcode project file merge forgot two files. - Small test fix for de-sectioning support of `ModelCollection`.
- Update to Swift 4 - Fix build warnings. - De-sectioning support.
- Fix up description code written after the flattening.
- Add all example apps to CI. - Fix framewok search paths so they custom overrides on Travis. This avoids build warnings inside Xcode for non-existent directories.
- Provide an array of `ModelCollectionState` rather than `Model` items. - Conform to `ModelCollection` officially. - Added helpers, and adjusted the CV data source.
- `ComposedModelCollection` can now compose sub-collections into a single section or as individual sections.
- These methods are generally unused and pre-date some significant changes to `ModelCollection`. This also makes the section-wrapping work as expected.
| @@ -16,22 +16,22 @@ public final class ScoredModelCollection: ModelCollection, ProxyingCollectionEve | |||
| self?.handleSourceEvent(event) | |||
| } | |||
|
|
|||
| updateSections() | |||
| updateModels() | |||
| } | |||
|
|
|||
| // MARK: Public | |||
There was a problem hiding this comment.
Totally out of scope for this diff but in retrospect this name ScoredModelCollection seems like it doesn't really describe what this MC does, though this is also one of the changes that looks really good in the flattening (sectionLimit -> limit)
There was a problem hiding this comment.
Agreed — ScoredModelCollection is up for rename in #54 👍
|
|
||
| /// `NSCollectionViewFlowLayout` which presents items as a full-width list. This class handles auto-invalidating itself | ||
| /// when the bounds change in a way that requires a new layout pass. | ||
| open class CollectionViewListLayout: NSCollectionViewFlowLayout { |
There was a problem hiding this comment.
Does open make sense in this context?
| } | ||
| } | ||
|
|
||
| // TODO:(wkiefer) Replace when Pilot has a block-based view binding provider. |
There was a problem hiding this comment.
We do have StaticViewBindingProvider(type: ExampleView.self) which would work here fwiw
| } | ||
| } | ||
|
|
||
| // TODO:(wkiefer) Replace when Pilot has a block-based view binding provider. |
|
|
||
| // MARK: Public | ||
|
|
||
| public static func make(with context: CatalogContext) -> TopicCollectionViewController { |
There was a problem hiding this comment.
random idea, but since we do a lot of things like this in our app it might be nice to provide an optional protocol CVCs can conform to with some static funcs which if conformed to provide a convenience init(context:) initializer
static func defaultModel() -> ModelCollection
static func defaultLayout() -> NSCollectionViewLayout
static func viewBinder() -> ViewBindingProvider
There was a problem hiding this comment.
nice idea! filed #110
| observers.notify(.didChangeState(state)) | ||
| } | ||
| public var state: ModelCollectionState { | ||
| // `sectionedState` is the source-of-truth for this class. |
There was a problem hiding this comment.
maybe log.warn here?
There was a problem hiding this comment.
oh, sorry. you can definitely call this — the comment was meant to explain why this is a dynamic getter. I'll update it to clarify.
Biggest change is the great flattening: 305d49f
Subsequent diffs tweaked the design, added helpers, fixed up examples, added examples to CI, and more.