CPCollectionViewgrinds to a halt with a non-trivial item view and several hundred rows. It can’t be using the modern cell/view reuse found in
CPTableView. The API supports this assessment, although I haven’t (and don’t have time) to look carefully at the source.
you obviously mean the lazy DOM loading feature, that is to put only visible items into the dom. this indeed is not yet in CPCollectionView (i have a branch in my repo). you can alternatively try CPTextView with the new view-embedding feature for this.
CPTextView doesn’t feel like a fit at all, but I’m not certain even a
CPCollectionView scrolling in the vertical axis is - once a collection item is selected we want just a single view visible (the editing interface for the underlying collection item). This is complicated by the editing interface needing a scroll view itself.
This interface is the core functionality of our app and I’m hoping to go beyond the abrupt transitions of simple view swapping - they work, but feel unpolished. Users are in this interface an hour or more a day, so polish is much appreciated by them.
source listTable of Contents. I mentioned in the autumn I was converting an Objective-C SourceList abstraction to Cappuccino - this is what it is for (the abstraction cleans up much of the fiddly setup of source lists). Completing that conversion is my immediate concern (I was pulled away from it over the winter by other work), but within three weeks or so the rest of this module needs to be mostly usable - so I’m beginning to tackle improving the navigation (absolutely needs to be keyboard driven in addition to point-and-click in the source list)
It’s also important to note there are/will be phone and tablet versions (native code) of the app and the navigation concepts should be as similar as possible, within the constraints of screen size (An outline view simply doesn’t work well on a touch interface, and a navigation stack (UINavigationController) in the Cappuccino app loses the always-visible Table of Contents which is very useful to users.
Comments, observations and suggestions welcome
CPViewAnimationmight work, but combining the leading/trailing view with the one acquiring focus would be a nightmare, I suspect. This really is a
CPCollectionViewsituation, I believe. But our current implementation doesn’t look up to the task and I don’t have the luxury of that technical risk at the moment.
NSSplitView. In our case we have different detail views for many of the items in the source list. I’m looking at ways to show a vertical transition as the users moves up and down through the source list view, whether that navigation is by directly clicking an item or using keyboard navigation. This is complicated by the source list representing a tree structure rather than a simple array/list. It’s unclear to me yet what form that navigation should take - moving up and down the source list at the same tree level one is at or, instead, moving in and out in the tree as required.
CPOutlineView/NSOutlineViewcan be fiddly to configure as a
source list, hence the desirablility of an abstraction like this framework.
CPOutlineViewalso maps acceptably to
UINavigationControllerfor iOS usage.
sourcelistexample code https://developer.apple.com/documentation/appkit/cocoa_bindings/navigating_hierarchical_data_using_outline_and_split_views?language=objc implements everything I need or want except detail view animations. It is implemented in Swift (not a problem) and uses modern APIs. Playing with keyboard navigation as implemented in it answers my questions - their choices work very well.
CPOutlineViewbut the framework I started converting from Objective-C has nice abstractions already for that. I’ll likely be coming back to that conversion once our implementation is working. Animations fall into the same category.
Is anyone using
localstorage to save and restore app state, particularly
CPTableView (selected item, outline expanded/collapsed state)? If so, how are you dealing with it?
I’m just beginning to deal with this and came across https://developer.apple.com/documentation/appkit/nsresponder/1526236-encoderestorablestatewithcoder?language=objc. We don’t implement any of the
CPResponder methods described. I had always assumed it would be necessary to code/decode either the entire view (which I don’t like doing because it’s a snapshot linked to data which might have changed) or write a custom mechanism to code/decode something like the state of a