@enquora
@daboe01
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 inCPTableView. 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.
Dear Cappuccino masters: I recently noticed on another site which embeds my Capp. programs that it does not work any more in Chrome. Now I have found that the same happens in a local server (a ruby server because my site is in Jekyll). No error with Safari nor FireFox, but in Chrome this appears when the loading progress bar gets stuck at its end:
VM90:439 Uncaught DOMException: Failed to read the 'localStorage' property from 'Window': Access is denied for this document.
at objj_class.$CPUserDefaultsLocalStore__supportsLocalStorage (eval at _300.setCode (http://localhost:4000/fract/FrACT10/capp/Frameworks/Objective-J/Objective-J.js:10009:16), <anonymous>:439:17)
at _objj_forward (http://localhost:4000/fract/FrACT10/capp/Frameworks/Objective-J/Objective-J.js:10605:13)… etc…
@daboe01 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 list Table 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)
This all feels very much like the first version of this app back in 2003-2005 when it wasn’t at all clear HTML/Javascript was capable of doing what was necessary. And our requirements were much simpler then. The difference is I know now it is possible, but I’ve found no existing Cocoa apps (native or Cappuccino) for inspiration.
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
CPViewAnimation might work, but combining the leading/trailing view with the one acquiring focus would be a nightmare, I suspect. This really is a CPCollectionView situation, 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/NSOutlineView can be fiddly to configure as a source list, hence the desirablility of an abstraction like this framework.
CPOutlineView also maps acceptably to UINavigationController for iOS usage.
sourcelist example 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.
CPOutlineView but 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 CPOutlineView or 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 CPOutlineView.
