Thoughts on a line-at-a-time data-reading class

[Daryle Walker]

I'm thinking of creating a Document-based app for my pet project. And I'm 
thinking about how to read the data in. I could load all the data, change it to 
a string, then process it; but I want to process the data in layers and do some 
work before string conversion. Specifically, I want to handle line breaks at 
the binary-data stage. Whatever I'm going to use will handle CR, LF, and CRLF. 
In my head, I came up with (in Swift):




//=
import Foundation




@objc
public enum LineReadingEnding {
   case None
   case LfOnly
   case CrOnly
   case CrLfPair
   case LfCrPair  // to eliminate spurious line breaks
}




@objc
public protocol LineReadingDelegate {
   public delineateDataFromReader(reader: LineReader, data: NSData, ending: 
LineReadingEnding)
}




public class LineReader: NSObject {
   public var delegate: LineReadingDelegate?




   public func lineateData(data: NSData)
   public func flushDataCallingDelegate(callDelegate: Bool)
}
//=




You pipe your data through "lineateData." (Since NSFileHandle and NSInputStream have 
NSData-related methods, you can pipe through those sources too. I originally had a direct function, 
but switched to a class plus delegate to support these cases.) I certainly get a line after a CRLF 
(or LFCR), but you need "flushDataCallingDelegate" to get the last line, especially if 
the last line isn't capped. Either call sends as many lines as possible to the delegate per call. 
(The data given to the delegate does not have the ending bytes attached.)




I have the algorithm in mind for the parsing, then realized that the handling needed to wait 
for the single line-break characters in case a paired character followed may be generalized. So 
I would add another property for a "Set" of all possible line breaks. 
However, I would need a parse tree, for the cases where some sequences are initial-subsets of 
others. Am I making it too complicated?




It would make a nice challenge, though. Though quick web-searches, I haven't 
seen any code applicable (or applicable enough), especially since the libraries 
tend to be NSString (instead of NSData) oriented. At least other people don't 
have to worry. I'm thinking of making this version on Objective-C, to be closer 
to the metal, and easier compatibility (since Swift is still in flux and needs 
to drag in libraries).



Sent from iCloud
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Setting the Null Placeholder for bindings

[Gerriet M. Denkmann]

I have a TextField bound to Shared User Defaults Controller.
The Null Placeholder is set to “default”.

When the window comes up, it shows the value from NSUserDefaults 
registerDefaults:. Ok
When I remove the string from the TextField, I see a grey value “default”. Also 
to be expected.
The actual value of the UserDefaults seems to come in this case from 
registerDefaults. Also good.

But how can I replace “default” with the actual string? 
Yes, I can do this in Xcode, but I would like to do this from inside my program.

Can this be done? If yes, how?

Gerriet.


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Apple Bug no response

[sqwarqDev]

> You might get an automated email when a future build is available asking you 
> to re-test. You may get a note that your bug is a duplicate. You may never 
> get a response at all.


Or…

…yesterday I got feedback asking if a bug I reported in an early *Yosemite* 
seed was resolved in the latest software. It was in fact resolved before 
Yosemite went GM (September, 2014, IIRC).



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Storyboard weakness

[Rick Mann]

I really wanted to be able to take advantage of the storyboard editor for many 
reasons. Turns out, you can (thanks to Daniel Stenmark for cluing me in).

You just can't drop in a UICollectionViewController (this is a lame weakness). 
But you can put in a UIViewController, and drop in a UICollectionView, and then 
(once you've wired everything up that doesn't get automatically wired), you can 
basically use it as if it were a "proper" UICollectionViewController (that is, 
you can create UICollectionViewCells right in the view, something you didn't 
used to be able to do).

So, now it's all working.

> On Mar 9, 2016, at 19:50 , Alex Zavatone  wrote:
> 
> Would it help if you created an XIB tor that particular scene?
> 
> If you delete your top level view for that scene in the storyboard, but that 
> scene is wired to your view controller, your view controller will load that 
> XIB for the top level view.  That XIB also has to be wired to your view 
> controller.
> 
> Would that have any advantage for you?
> 
> On Mar 9, 2016, at 6:04 PM, Rick Mann wrote:
> 
>> There's a severe weakness in Storyboards for which I'm hoping a better 
>> solution exists.
>> 
>> When you create a scene for say, a UICollectionView, the Storyboard makes it 
>> very easy, but it also imposes a severe limitation. In my case, my 
>> UICollectionViewController subclass lives inside a UINavigationController. 
>> It manages the controls in the toolbar and the title, as well as the content.
>> 
>> But inevitably I want to add additional views beneath the UINavigationBar 
>> that are NOT CONTAINED within the UICollectionView (in this case, a 
>> UISegmentedControl for sorting the contents). The only way I see how to do 
>> this with Storyboards is to create two view controllers, one that embeds the 
>> UICollectionViewController subclass. But now its impossible to wire up 
>> UINavigationBar items to it. I've been forced to split up view control 
>> across two view controllers that really should be one.
>> 
>> This is solved by having the UICollectionView controller subclass have its 
>> view property point to a generic containing view, and its collectionView 
>> property point to the collectionView subview. But it's not really designed 
>> to work this way, and Storyboards definitely doesn't support this.
>> 
>> The Apple-provided way imposes a HUGE burden.
>> 
>> Is there any happy middle ground?
>> 
>> I've written this bug before, but Apple doesn't care.
>> 
>> -- 
>> Rick Mann
>> rm...@latencyzero.com
>> 
>> 
>> 
>> ___
>> 
>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>> 
>> Please do not post admin requests or moderator comments to the list.
>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>> 
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/cocoa-dev/zav%40mac.com
>> 
>> This email sent to z...@mac.com
> 


-- 
Rick Mann
rm...@latencyzero.com



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Storyboard weakness

[Alex Zavatone]

Would it help if you created an XIB tor that particular scene?

If you delete your top level view for that scene in the storyboard, but that 
scene is wired to your view controller, your view controller will load that XIB 
for the top level view.  That XIB also has to be wired to your view controller.

Would that have any advantage for you?

On Mar 9, 2016, at 6:04 PM, Rick Mann wrote:

> There's a severe weakness in Storyboards for which I'm hoping a better 
> solution exists.
> 
> When you create a scene for say, a UICollectionView, the Storyboard makes it 
> very easy, but it also imposes a severe limitation. In my case, my 
> UICollectionViewController subclass lives inside a UINavigationController. It 
> manages the controls in the toolbar and the title, as well as the content.
> 
> But inevitably I want to add additional views beneath the UINavigationBar 
> that are NOT CONTAINED within the UICollectionView (in this case, a 
> UISegmentedControl for sorting the contents). The only way I see how to do 
> this with Storyboards is to create two view controllers, one that embeds the 
> UICollectionViewController subclass. But now its impossible to wire up 
> UINavigationBar items to it. I've been forced to split up view control across 
> two view controllers that really should be one.
> 
> This is solved by having the UICollectionView controller subclass have its 
> view property point to a generic containing view, and its collectionView 
> property point to the collectionView subview. But it's not really designed to 
> work this way, and Storyboards definitely doesn't support this.
> 
> The Apple-provided way imposes a HUGE burden.
> 
> Is there any happy middle ground?
> 
> I've written this bug before, but Apple doesn't care.
> 
> -- 
> Rick Mann
> rm...@latencyzero.com
> 
> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/zav%40mac.com
> 
> This email sent to z...@mac.com


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Can't generate receipt OS X after 173 exit

[Trygve Inda]

I am no longer able to generate a receipt after exiting with code 173.

When I launch, I get a box saying that the app was purchased on another
computer and that I need to validate it. I enter my Apple ID and password,
but I get "An unexpected error occurred while signing in"

The Apple ID could not be found or the password is incorrect.

Any ideas?

I tried quiting the store processes in Activity monitor. No joy.

Very frustrating.




___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Storyboard weakness

[Rick Mann]

> On Mar 9, 2016, at 18:09 , Daniel Stenmark  wrote:
> 
> If you’re still having issues, feel free to post up and send us a GitHub link 
> to a sample project exhibiting this behavior.  Setting up a UICollectionView 
> fairly straight-forward; something’s being overlooked here.

Yeah, I think I found it. I'm still having issues, but I may be getting closer.

> 
> Dan
> 
>> On Mar 9, 2016, at 5:55 PM, Daniel Stenmark  wrote:
>> 
>> Did you set the prototype cell’s Reusability Identifier?
>> 
>> http://i.imgur.com/1uLxYPo.png
>> 
>> Dan
>> 
>> On Mar 9, 2016, at 5:29 PM, Rick Mann 
>> > wrote:
>> 
>> 
>> On Mar 9, 2016, at 16:05 , Daniel Stenmark 
>> > wrote:
>> 
>> Because I want all the benefits the specific view controller gives me, 
>> namely the ability to build the cells right in the view.
>> 
>> What’re you talking about?  You can still build custom UICollectionView 
>> cells right into the view when using a plain old UIViewController.
>> 
>> Yeah, it doesn't seem to work to do this. If you have it working, how? When 
>> I call dequeueReusableCellWithReuseIdentifier(), it asserts.
>> 
>> 
>> --
>> Rick Mann
>> rm...@latencyzero.com
>> 
>> 
>> 
>> ___
>> 
>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>> 
>> Please do not post admin requests or moderator comments to the list.
>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>> 
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/cocoa-dev/dstenmark%40opentable.com
>> 
>> This email sent to dstenm...@opentable.com
> 


-- 
Rick Mann
rm...@latencyzero.com



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Storyboard weakness

[Daniel Stenmark]

If you’re still having issues, feel free to post up and send us a GitHub link 
to a sample project exhibiting this behavior.  Setting up a UICollectionView 
fairly straight-forward; something’s being overlooked here.

Dan

> On Mar 9, 2016, at 5:55 PM, Daniel Stenmark  wrote:
> 
> Did you set the prototype cell’s Reusability Identifier?
> 
> http://i.imgur.com/1uLxYPo.png
> 
> Dan
> 
> On Mar 9, 2016, at 5:29 PM, Rick Mann 
> > wrote:
> 
> 
> On Mar 9, 2016, at 16:05 , Daniel Stenmark 
> > wrote:
> 
> Because I want all the benefits the specific view controller gives me, namely 
> the ability to build the cells right in the view.
> 
> What’re you talking about?  You can still build custom UICollectionView cells 
> right into the view when using a plain old UIViewController.
> 
> Yeah, it doesn't seem to work to do this. If you have it working, how? When I 
> call dequeueReusableCellWithReuseIdentifier(), it asserts.
> 
> 
> --
> Rick Mann
> rm...@latencyzero.com
> 
> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/dstenmark%40opentable.com
> 
> This email sent to dstenm...@opentable.com


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Storyboard weakness

[Daniel Stenmark]

Did you set the prototype cell’s Reusability Identifier?

http://i.imgur.com/1uLxYPo.png

Dan

On Mar 9, 2016, at 5:29 PM, Rick Mann 
> wrote:


On Mar 9, 2016, at 16:05 , Daniel Stenmark 
> wrote:

Because I want all the benefits the specific view controller gives me, namely 
the ability to build the cells right in the view.

What’re you talking about?  You can still build custom UICollectionView cells 
right into the view when using a plain old UIViewController.

Yeah, it doesn't seem to work to do this. If you have it working, how? When I 
call dequeueReusableCellWithReuseIdentifier(), it asserts.


--
Rick Mann
rm...@latencyzero.com



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Storyboard weakness

[Rick Mann]

I did. This is at least the second bug about this I've reported.

Basically, every few years I end up having to do this, and work around the 
problem one way or another. I usually write a bug report when I do.

It seems Apple has improved things slightly (e.g., you can actually still build 
cells in Storyboard if you drop in a UICollectionView), but they're still 
broken (e.g. those cells seem to be inaccessible to the view controller).

> On Mar 9, 2016, at 17:31 , Gary L. Wade  wrote:
> 
> Write a bug like I did saying how difficult it is using Interface Builder to 
> construct the UI you desire. Give as concrete an example as you can, and if 
> you've seen an Apple app do similar, mention it. If you've seen a third party 
> app do it, mention it, too. Sometimes you'll get some free tech support from 
> your radar (I did for one tricky auto layout issue), sometimes you'll get 
> ignored. You get nothing if you report nothing.
> --
> Gary L. Wade (Sent from my iPhone)
> http://www.garywade.com/
> 
>> On Mar 9, 2016, at 5:23 PM, Rick Mann  wrote:
>> 
>> I might be able to require iOS 9. But of course that doesn't really address 
>> the overarching issue that prevents any non-trivial use of these tools and 
>> APIs.


-- 
Rick Mann
rm...@latencyzero.com



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Storyboard weakness

[Gary L. Wade]

Write a bug like I did saying how difficult it is using Interface Builder to 
construct the UI you desire. Give as concrete an example as you can, and if 
you've seen an Apple app do similar, mention it. If you've seen a third party 
app do it, mention it, too. Sometimes you'll get some free tech support from 
your radar (I did for one tricky auto layout issue), sometimes you'll get 
ignored. You get nothing if you report nothing.
--
Gary L. Wade (Sent from my iPhone)
http://www.garywade.com/

> On Mar 9, 2016, at 5:23 PM, Rick Mann  wrote:
> 
> I might be able to require iOS 9. But of course that doesn't really address 
> the overarching issue that prevents any non-trivial use of these tools and 
> APIs.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Storyboard weakness

[Rick Mann]

> On Mar 9, 2016, at 16:05 , Daniel Stenmark  wrote:
> 
>> Because I want all the benefits the specific view controller gives me, 
>> namely the ability to build the cells right in the view.
> 
> What’re you talking about?  You can still build custom UICollectionView cells 
> right into the view when using a plain old UIViewController.

Yeah, it doesn't seem to work to do this. If you have it working, how? When I 
call dequeueReusableCellWithReuseIdentifier(), it asserts.


-- 
Rick Mann
rm...@latencyzero.com



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Storyboard weakness

[Rick Mann]

> On Mar 9, 2016, at 17:13 , Gary L. Wade  wrote:
> 
> If you can require iOS 9, pinning appears to be supported. If earlier, you 
> might be able to do what you want by overriding a layout class. I haven't 
> tried it myself, though. I know your pain with respect to a 
> UITabBarController, though, but that was easy to re-enclose in another view, 
> although I had to do it in code.

I might be able to require iOS 9. But of course that doesn't really address the 
overarching issue that prevents any non-trivial use of these tools and APIs.

> --
> Gary L. Wade (Sent from my iPhone)
> http://www.garywade.com/
> 
>> On Mar 9, 2016, at 5:06 PM, Rick Mann  wrote:
>> 
>> Supplementary views scroll with the content. I want non-scrolling views.


-- 
Rick Mann
rm...@latencyzero.com



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Storyboard weakness

[Gary L. Wade]

If you can require iOS 9, pinning appears to be supported. If earlier, you 
might be able to do what you want by overriding a layout class. I haven't tried 
it myself, though. I know your pain with respect to a UITabBarController, 
though, but that was easy to re-enclose in another view, although I had to do 
it in code.
--
Gary L. Wade (Sent from my iPhone)
http://www.garywade.com/

> On Mar 9, 2016, at 5:06 PM, Rick Mann  wrote:
> 
> Supplementary views scroll with the content. I want non-scrolling views.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Storyboard weakness

[Rick Mann]

> On Mar 9, 2016, at 17:05 , Gary L. Wade  wrote:
> 
> I'm not sure exactly about your layout, but maybe what you want are 
> supplementary views?

Supplementary views scroll with the content. I want non-scrolling views.

> --
> Gary L. Wade (Sent from my iPhone)
> http://www.garywade.com/
> 
>> On Mar 9, 2016, at 3:04 PM, Rick Mann  wrote:
>> 
>> There's a severe weakness in Storyboards for which I'm hoping a better 
>> solution exists.
>> 
>> When you create a scene for say, a UICollectionView, the Storyboard makes it 
>> very easy, but it also imposes a severe limitation. In my case, my 
>> UICollectionViewController subclass lives inside a UINavigationController. 
>> It manages the controls in the toolbar and the title, as well as the content.
>> 
>> But inevitably I want to add additional views beneath the UINavigationBar 
>> that are NOT CONTAINED within the UICollectionView (in this case, a 
>> UISegmentedControl for sorting the contents). The only way I see how to do 
>> this with Storyboards is to create two view controllers, one that embeds the 
>> UICollectionViewController subclass. But now its impossible to wire up 
>> UINavigationBar items to it. I've been forced to split up view control 
>> across two view controllers that really should be one.
>> 
>> This is solved by having the UICollectionView controller subclass have its 
>> view property point to a generic containing view, and its collectionView 
>> property point to the collectionView subview. But it's not really designed 
>> to work this way, and Storyboards definitely doesn't support this.
>> 
>> The Apple-provided way imposes a HUGE burden.
>> 
>> Is there any happy middle ground?
>> 
>> I've written this bug before, but Apple doesn't care.
>> 
>> -- 
>> Rick Mann
>> rm...@latencyzero.com
>> 


-- 
Rick Mann
rm...@latencyzero.com



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Storyboard weakness

[Gary L. Wade]

I'm not sure exactly about your layout, but maybe what you want are 
supplementary views?
--
Gary L. Wade (Sent from my iPhone)
http://www.garywade.com/

> On Mar 9, 2016, at 3:04 PM, Rick Mann  wrote:
> 
> There's a severe weakness in Storyboards for which I'm hoping a better 
> solution exists.
> 
> When you create a scene for say, a UICollectionView, the Storyboard makes it 
> very easy, but it also imposes a severe limitation. In my case, my 
> UICollectionViewController subclass lives inside a UINavigationController. It 
> manages the controls in the toolbar and the title, as well as the content.
> 
> But inevitably I want to add additional views beneath the UINavigationBar 
> that are NOT CONTAINED within the UICollectionView (in this case, a 
> UISegmentedControl for sorting the contents). The only way I see how to do 
> this with Storyboards is to create two view controllers, one that embeds the 
> UICollectionViewController subclass. But now its impossible to wire up 
> UINavigationBar items to it. I've been forced to split up view control across 
> two view controllers that really should be one.
> 
> This is solved by having the UICollectionView controller subclass have its 
> view property point to a generic containing view, and its collectionView 
> property point to the collectionView subview. But it's not really designed to 
> work this way, and Storyboards definitely doesn't support this.
> 
> The Apple-provided way imposes a HUGE burden.
> 
> Is there any happy middle ground?
> 
> I've written this bug before, but Apple doesn't care.
> 
> -- 
> Rick Mann
> rm...@latencyzero.com
> 

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Storyboard weakness

[Rick Mann]

> On Mar 9, 2016, at 16:05 , Daniel Stenmark  wrote:
> 
>> Because I want all the benefits the specific view controller gives me, 
>> namely the ability to build the cells right in the view.
> 
> What’re you talking about?  You can still build custom UICollectionView cells 
> right into the view when using a plain old UIViewController.

This doesn't seem to work, at least not directly:

Terminating app due to uncaught exception 'NSInternalInconsistencyException', 
reason: 'could not dequeue a view of kind: UICollectionElementKindCell with 
identifier Model - must register a nib or a class for the identifier or connect 
a prototype cell in a storyboard'

How do you access the cells in this situaion?

-- 
Rick Mann
rm...@latencyzero.com



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Safe cross references between scenes in an OS X storyboard

[Quincey Morris]

On Mar 9, 2016, at 16:22 , Quincey Morris  
wrote:
> 
>> NSWindowController

Sorry, my brain was stuck on window controllers, but you’re doing this in the 
view controller. Same code, really.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Safe cross references between scenes in an OS X storyboard

[Quincey Morris]

On Mar 9, 2016, at 13:31 , Bill Cheeseman  wrote:
> 
>static var controller: MainContentViewController? {
>get {
>return  MainContentViewController.controller
>}
>set(newController) {
>MainContentViewController.controller = newController
>}
>}

No, it’s *really* a property, so like this:

> class MainContentViewController: NSWindowController {
> 
>   static private(set) var controller: MainContentViewController! // 
> defaults to nil until set
>   
>   override func windowDidLoad () {
>   precondition (MainContentViewController.controller== nil)
>   MainContentViewController.controller = self
>   }
> }

It’s a “regular” stored property, so you don’t have to write a setter or 
getter. (Your original version really is recursive.)

I’ve declared the property “private(set)” so that no one outside the class can 
change it, and I’ve added a check that there’s only one 
MainContentViewController ever created.
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Apple Bug no response

[Bill Cheeseman]

> On Mar 9, 2016, at 6:52 PM, Michael David Crawford  
> wrote:
> 
> I have a bug in Apple's sample code that would be a trivial fix, that
> has been open for eight years.
> 
> By contrast I've reported a few kernel bugs.  Each was fixed in the
> very next build.


My experience is similar. I've reported accessibility API bugs since 2002 that 
have always been fixed immediately. Maybe that's because accessibility is 
important to Apple (as a lawyer, I can tell you that it is very important 
legally); maybe that's because they know I'm experienced on accessibility 
issues; maybe that's because the accessibility team is particularly interested 
in getting things together. Bugs that I've reported in other areas sometimes 
get responses, sometimes they get fixed, other times they get ignored as far as 
I can tell. So, Apple is a big organization, with lots of different 
departments, and it's hard to see consistency. The one thing I'm very confident 
about is that well written bug reports get better attention than poorly written 
bug reports.

-- 

Bill Cheeseman - wjcheese...@comcast.net

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Storyboard weakness

[Rick Mann]

> On Mar 9, 2016, at 16:05 , Daniel Stenmark  wrote:
> 
>> Because I want all the benefits the specific view controller gives me, 
>> namely the ability to build the cells right in the view.
> 
> What’re you talking about?  You can still build custom UICollectionView cells 
> right into the view when using a plain old UIViewController.

Oh wow, that's new. You didn't used to be able to do that.

-- 
Rick Mann
rm...@latencyzero.com



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Storyboard weakness

[Daniel Stenmark]

> Because I want all the benefits the specific view controller gives me, namely 
> the ability to build the cells right in the view.

What’re you talking about?  You can still build custom UICollectionView cells 
right into the view when using a plain old UIViewController.

Dan

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Storyboard weakness

[Rick Mann]

Because I want all the benefits the specific view controller gives me, namely 
the ability to build the cells right in the view.

I guess I have to give up on that. One small silver lining is I can break those 
into NIBs and not duplicate them (I have three different collection views that 
all reuse the  same cells).

But the other reason is that I'VE ALREADY BUILT THIS. The requirement to add 
views came much later. If Apple had just done it right from the start, I 
wouldn't be suffering like this.

> On Mar 9, 2016, at 15:46 , Daniel Stenmark  wrote:
> 
> Why are you locking yourself into a heavily customized 
> UICollectionViewController?  Why not just use a generic UIViewController and 
> hook up your view elements the old fashioned way?
> 
> Dan
> 
>> On Mar 9, 2016, at 3:04 PM, Rick Mann  wrote:
>> 
>> There's a severe weakness in Storyboards for which I'm hoping a better 
>> solution exists.
>> 
>> When you create a scene for say, a UICollectionView, the Storyboard makes it 
>> very easy, but it also imposes a severe limitation. In my case, my 
>> UICollectionViewController subclass lives inside a UINavigationController. 
>> It manages the controls in the toolbar and the title, as well as the content.
>> 
>> But inevitably I want to add additional views beneath the UINavigationBar 
>> that are NOT CONTAINED within the UICollectionView (in this case, a 
>> UISegmentedControl for sorting the contents). The only way I see how to do 
>> this with Storyboards is to create two view controllers, one that embeds the 
>> UICollectionViewController subclass. But now its impossible to wire up 
>> UINavigationBar items to it. I've been forced to split up view control 
>> across two view controllers that really should be one.
>> 
>> This is solved by having the UICollectionView controller subclass have its 
>> view property point to a generic containing view, and its collectionView 
>> property point to the collectionView subview. But it's not really designed 
>> to work this way, and Storyboards definitely doesn't support this.
>> 
>> The Apple-provided way imposes a HUGE burden.
>> 
>> Is there any happy middle ground?
>> 
>> I've written this bug before, but Apple doesn't care.
>> 
>> -- 
>> Rick Mann
>> rm...@latencyzero.com
>> 
>> 
>> 
>> ___
>> 
>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>> 
>> Please do not post admin requests or moderator comments to the list.
>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>> 
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/cocoa-dev/dstenmark%40opentable.com
>> 
>> This email sent to dstenm...@opentable.com
> 


-- 
Rick Mann
rm...@latencyzero.com



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Apple Bug no response

[Michael David Crawford]

I have a bug in Apple's sample code that would be a trivial fix, that
has been open for eight years.

By contrast I've reported a few kernel bugs.  Each was fixed in the
very next build.
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Storyboard weakness

[Daniel Stenmark]

Why are you locking yourself into a heavily customized 
UICollectionViewController?  Why not just use a generic UIViewController and 
hook up your view elements the old fashioned way?

Dan

> On Mar 9, 2016, at 3:04 PM, Rick Mann  wrote:
> 
> There's a severe weakness in Storyboards for which I'm hoping a better 
> solution exists.
> 
> When you create a scene for say, a UICollectionView, the Storyboard makes it 
> very easy, but it also imposes a severe limitation. In my case, my 
> UICollectionViewController subclass lives inside a UINavigationController. It 
> manages the controls in the toolbar and the title, as well as the content.
> 
> But inevitably I want to add additional views beneath the UINavigationBar 
> that are NOT CONTAINED within the UICollectionView (in this case, a 
> UISegmentedControl for sorting the contents). The only way I see how to do 
> this with Storyboards is to create two view controllers, one that embeds the 
> UICollectionViewController subclass. But now its impossible to wire up 
> UINavigationBar items to it. I've been forced to split up view control across 
> two view controllers that really should be one.
> 
> This is solved by having the UICollectionView controller subclass have its 
> view property point to a generic containing view, and its collectionView 
> property point to the collectionView subview. But it's not really designed to 
> work this way, and Storyboards definitely doesn't support this.
> 
> The Apple-provided way imposes a HUGE burden.
> 
> Is there any happy middle ground?
> 
> I've written this bug before, but Apple doesn't care.
> 
> -- 
> Rick Mann
> rm...@latencyzero.com
> 
> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/dstenmark%40opentable.com
> 
> This email sent to dstenm...@opentable.com


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Storyboard weakness

[Peter Tomaselli]

I might be misunderstanding, but why not just use a regular UIViewController 
scene, throw a collection view in it, throw your other view into it too, and 
then conform to UICollectionViewDataSource and -Delegate “manually”?

It’s a few more outlets to connect by hand but isn’t UICollectionViewController 
(itself; as a class) essentially a convenience? Or is there functionality 
obtainable via UICollectionViewController only?

Peter

> On Mar 9, 2016, at 6:04 PM, Rick Mann  wrote:
> 
> There's a severe weakness in Storyboards for which I'm hoping a better 
> solution exists.
> 
> When you create a scene for say, a UICollectionView, the Storyboard makes it 
> very easy, but it also imposes a severe limitation. In my case, my 
> UICollectionViewController subclass lives inside a UINavigationController. It 
> manages the controls in the toolbar and the title, as well as the content.
> 
> But inevitably I want to add additional views beneath the UINavigationBar 
> that are NOT CONTAINED within the UICollectionView (in this case, a 
> UISegmentedControl for sorting the contents). The only way I see how to do 
> this with Storyboards is to create two view controllers, one that embeds the 
> UICollectionViewController subclass. But now its impossible to wire up 
> UINavigationBar items to it. I've been forced to split up view control across 
> two view controllers that really should be one.
> 
> This is solved by having the UICollectionView controller subclass have its 
> view property point to a generic containing view, and its collectionView 
> property point to the collectionView subview. But it's not really designed to 
> work this way, and Storyboards definitely doesn't support this.
> 
> The Apple-provided way imposes a HUGE burden.
> 
> Is there any happy middle ground?
> 
> I've written this bug before, but Apple doesn't care.
> 
> -- 
> Rick Mann
> rm...@latencyzero.com
> 
> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/vast.grapes%40gmail.com
> 
> This email sent to vast.gra...@gmail.com


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Apple Bug no response

[Richard Charles]

> On Mar 9, 2016, at 1:32 PM, Trygve Inda  wrote:
> 
> I have an open bug report
> 
> How long should I expect to wait for a response?

My experience with issues.

If you have a graphics related bug (OpenGL, Core Animation, Graphics Adapter 
Specific) they get on it right away and you will get a response.

If you have another kind of bug you will generally wait and hear nothing.

If you submit a technical support incident you will get a response.

--Richard Charles


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Storyboard weakness

[Rick Mann]

There's a severe weakness in Storyboards for which I'm hoping a better solution 
exists.

When you create a scene for say, a UICollectionView, the Storyboard makes it 
very easy, but it also imposes a severe limitation. In my case, my 
UICollectionViewController subclass lives inside a UINavigationController. It 
manages the controls in the toolbar and the title, as well as the content.

But inevitably I want to add additional views beneath the UINavigationBar that 
are NOT CONTAINED within the UICollectionView (in this case, a 
UISegmentedControl for sorting the contents). The only way I see how to do this 
with Storyboards is to create two view controllers, one that embeds the 
UICollectionViewController subclass. But now its impossible to wire up 
UINavigationBar items to it. I've been forced to split up view control across 
two view controllers that really should be one.

This is solved by having the UICollectionView controller subclass have its view 
property point to a generic containing view, and its collectionView property 
point to the collectionView subview. But it's not really designed to work this 
way, and Storyboards definitely doesn't support this.

The Apple-provided way imposes a HUGE burden.

Is there any happy middle ground?

I've written this bug before, but Apple doesn't care.

-- 
Rick Mann
rm...@latencyzero.com



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Safe cross references between scenes in an OS X storyboard

[Bill Cheeseman]

> On Mar 9, 2016, at 1:00 PM, Quincey Morris 
>  wrote:
> 
> What you can do instead is subclass NSWindowController, and use 
> ‘windowDidLoad’ as your opportunity to save your own strong reference to the 
> WC. (In Swift, I think I’d make it a static property of the WC class. This 
> also lets you check that nothing creates a second main window.)

I haven't been able to figure out how to do this, and I've run out of time for 
today. Any hints would sure be appreciated.

I'm doing it in my MainContentViewController class. I have declared the static 
variable mainContentViewController, with getter and setter. I have set its 
value when the view loads, in viewDidLoad(). And I use the static variable in 
AppDelegate. It compiles without error, but at runtime the setter is called 
repeatedly until it crashes -- apparently an infinite loop.

Like so:

static var controller: MainContentViewController? {
get {
return  MainContentViewController.controller
}
set(newController) {
MainContentViewController.controller = newController
}
}


-- 

Bill Cheeseman - wjcheese...@comcast.net

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Safe cross references between scenes in an OS X storyboard

[Quincey Morris]

On Mar 9, 2016, at 11:36 , Bill Cheeseman  wrote:
> 
> But don't I still need to use optionals if I declare the window controller or 
> content view controller instance variable in AppDelegate but don't set it 
> until later in the window controller's windowDidLoad() method? I am still at 
> risk of using the instance variable before its value has been set. (I could 
> solve that problem, or rather localize it, by not making it an instance 
> variable but instead a local variable where I actually use it, but the whole 
> point of my current exercise is to have a chain of storyboard scene cross 
> references.)

As a mere technical detail, your reference to the window controller has to be 
nil initially. However, it’s necessarily going to be set by the time you 
actually reference it, so that’s a good candidate for an implicitly unwrapped 
optional (“!”) instead of a plain optional (“?”). Why “necessarily”? Because:

— NSApplicationMain is documented to instantiate the main storyboard.

— What NSApplicationMain does occurs before applicationDidFinishLaunching. 
(Some of what it does might occur before applicationWillFinishLaunching, too, 
but that doesn’t make any difference here.)

— Therefore your windowDidLoad, where you will set a non-nil value for the 
window controller reference, will execute before applicationDidFinishLaunching.

— Therefore in applicationDidFinishLaunching or anytime later, you can safely 
refer to your window controller.

> You say you would make it a static property of the window controller class. 
> But I need to refer to it in AppDelegate. So, I guess you're saying I can 
> refer to a static class variable from anywhere. This is what the Swift 
> language guide refers to as a "type property," right? I see from the guide 
> that I can refer to it from any class in my application as a property of the 
> type as opposed to a property of an instance. It strikes me that this is 
> exactly what I need. And it feels so much more appropriate to place the 
> reference in the window controller itself, instead of in AppDelegate. (So, a 
> Swift "singleton" class can have a type property that refers to its own sole 
> instance? And that type property is accessible everywhere in the application? 
> Weird. And amazingly convenient. So much still to learn about Swift!)

Yes, that’s a type property. It’s the same thing as Obj-C class methods like 
“[NSApplication sharedApplication]” except that it’s a genuine property, which 
can’t be done at the class level in Obj-C. So you can think in terms of 
singletons, or you can think of global variables (encased within a class’s 
“namespace”) or you can think of it as a property of the class object, 
whichever works for you. It’s accessible everywhere, subject to the normal 
access controls.

It can be a property of the app delegate if you want (or a class property of 
AppDelegate if you want). The decision probably depends on which class you feel 
is in control of WC instances.

> It is uncomfortable, but storyboards are making lots of things uncomfortable 
> -- or, rather, they are forcing me to do a lot of rethinking of old 
> principles. I find myself spending a lot of time wondering which scene to use 
> for code that in the old days used to get thrown into a single, massive 
> window controller class where worries like this did not intrude. In this 
> project, I am making heavy use of view controllers to break my code down into 
> much smaller pieces, which storyboards encourage. In addition, having a lot 
> of scenes in a single storyboard, as opposed to multiple nib files, 
> encourages one to think that code can be put anywhere. That's why I'm 
> inventing all the ways I can think of to create workable cross references 
> between scenes. And Apple encourages that in the WWDC 2014 video by repeating 
> way too many times that you really have to implement 
> prepareForSegue(_:sender:) all over the place if you use storyboards. I guess 
> it has always been considered more acceptable for view controllers to cross 
> reference one another, as opposed to model classes and view classes that are 
> supposed to be as reusable as possible.

It sort of doesn’t matter where the code goes, apart from relatively humble 
considerations (e.g. it’s always been horrible that WCs tend to get bloated 
with action methods and support code; using VCs allows that to be split up into 
pieces of more reasonable size). I think that if your background is 
historically OS X, WCs will seem more natural — because VCs were awkward when 
they weren’t automatically in the responder chain. If your background is iOS, 
VCs seem more natural.

The big difference is that you can’t create cross-scene connections in IB. But 
I don’t see any difficulty with using WCs to mediate between view controllers 
in a fixed hierarchy.  I think passing references to information via 
prepareForSegue is more useful for transient or ad-hoc relationships between 
view 

Re: Apple Bug no response

[Gavin Eadie]

#4145901 .. June 12, 2005

> On Mar 9, 2016, at 4:02 PM, Gary L. Wade  wrote:
> 
> My oldest open bug will be 10 years old by WWDC 2016.


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Apple Bug no response

[Gary L. Wade]

My oldest open bug will be 10 years old by WWDC 2016.
--
Gary L. Wade (Sent from my iPhone)
http://www.garywade.com/

> On Mar 9, 2016, at 12:50 PM, Eric E Dolecki  wrote:
> 
> I have bugs that have celebrated their fifth birthdays. Fire and forget. 
> 
> Sent from my iP6+
> 
>> On Mar 9, 2016, at 3:44 PM, Hunter Hillegas  wrote:
>> 
>> You must be new here. ;-)
>> 
>> You might get an automated email when a future build is available asking you 
>> to re-test. You may get a note that your bug is a duplicate. You may never 
>> get a response at all.
>> 
>> I have many open bugs from years back which usually either means the issue 
>> is still out there or it was fixed but the screeners didn’t wire up the bug 
>> in a way that they know my issue was resolved.
>> 
>> Apple has said (Craig F. on The Talk Show recently) that this is a place 
>> they know they have room to improve.
>> 
>>> On Mar 9, 2016, at 12:32 PM, Trygve Inda  wrote:
>>> 
>>> I have an open bug report
>>> 
>>> How long should I expect to wait for a response?
>> 

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Apple Bug no response

[Eric E Dolecki]

I have bugs that have celebrated their fifth birthdays. Fire and forget. 

Sent from my iP6+

> On Mar 9, 2016, at 3:44 PM, Hunter Hillegas  wrote:
> 
> You must be new here. ;-)
> 
> You might get an automated email when a future build is available asking you 
> to re-test. You may get a note that your bug is a duplicate. You may never 
> get a response at all.
> 
> I have many open bugs from years back which usually either means the issue is 
> still out there or it was fixed but the screeners didn’t wire up the bug in a 
> way that they know my issue was resolved.
> 
> Apple has said (Craig F. on The Talk Show recently) that this is a place they 
> know they have room to improve.
> 
>> On Mar 9, 2016, at 12:32 PM, Trygve Inda  wrote:
>> 
>> I have an open bug report
>> 
>> How long should I expect to wait for a response?
> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/edolecki%40gmail.com
> 
> This email sent to edole...@gmail.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Apple Bug no response

[Hunter Hillegas]

You must be new here. ;-)

You might get an automated email when a future build is available asking you to 
re-test. You may get a note that your bug is a duplicate. You may never get a 
response at all.

I have many open bugs from years back which usually either means the issue is 
still out there or it was fixed but the screeners didn’t wire up the bug in a 
way that they know my issue was resolved.

Apple has said (Craig F. on The Talk Show recently) that this is a place they 
know they have room to improve.

> On Mar 9, 2016, at 12:32 PM, Trygve Inda  wrote:
> 
> I have an open bug report
> 
> How long should I expect to wait for a response?


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Apple Bug no response

[Ken Thomases]

On Mar 9, 2016, at 2:32 PM, Trygve Inda  wrote:
> 
> I have an open bug report
> 
> rdar://24316348
> 
> Apple asked for an example to reproduce which I sent on January 27, but I
> have heard nothing since. This is a fairly simple bug (NSTextFields can't
> fully justify on 10.11).
> 
> How long should I expect to wait for a response?

The Apple bug reporter is a means for getting information _in_ to Apple, not 
out to developers.  You won't hear from them unless/until a) they want more 
information from you (like the example they requested), or b) they have a new 
seed release of the OS which they believe has fixed the issue and want you to 
test and report back.

You can update your bug report with a request for status and they should give 
you that, although it will probably be something like "the issue is still being 
investigated".

You can open a developer technical support incident to ask for a workaround, if 
they know of one.

Regards,
Ken


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Apple Bug no response

[Trygve Inda]

I have an open bug report

rdar://24316348

Apple asked for an example to reproduce which I sent on January 27, but I
have heard nothing since. This is a fairly simple bug (NSTextFields can't
fully justify on 10.11).

How long should I expect to wait for a response?

Thanks,

Trygve



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Safe cross references between scenes in an OS X storyboard

[Bill Cheeseman]

> On Mar 9, 2016, at 1:00 PM, Quincey Morris 
>  wrote:
> 
> On Mar 9, 2016, at 05:59 , Bill Cheeseman  wrote:
>> 
>> But the main thrust of my question was whether this is a safe and sensible 
>> way to crossreference other storyboard scenes -- at least when 
>> prepareForSegue(_:sender:) isn't available, as it isn't here. Having thought 
>> about it for a while now, I guess it is a sensible approach. It has less to 
>> do with storyboards than with the longstanding fact that NSApplication has a 
>> 'mainwindow' property and NSWindow has a 'contentViewController' property.
> 
> I think you ended up solving the “wrong” problem. The lazy initialization is 
> unnecessary, and so is the mucking about with optionals, because the window 
> controller and window both exist by the time applicationDidFinishLaunching is 
> invoked. The window isn’t main yet, but that’s the wrong place to look for 
> it: apart from anything else, your proposed code is fragile because if your 
> app ever has other windows that become main, even temporarily, you 
> temporarily lose the ability to find your shoebox window.

That sort of issue is talked about in a footnote at the end of the very recent 
Tech Q QA1871, which suggests using a view controller's representedObject 
instead of a window for Cocoa bindings in a storyboard for the same reason. But 
I'm reserving representedObject for my model object, as the Q suggests.

It hadn't occurred to me that the issue might not be the existence of the 
window but only whether it had become the mainWindow by the time 
applicationDidFinishLaunching(_:) is called. But by using lazy initialization I 
no longer have to set this instance variable's value in 
applicationDidFinishLaunching(_:). I don't actually use the reference to the 
content view controller until I know it is safe (I use it in a NSMenuDelegate 
method when the user opens a menu in the main menu bar). But that is 
happenstance, not safe coding. I added 'guard', and then Optionals as you 
suggested, out of a sense that Swift encourages this sort of thing for safety's 
sake.

> (I’m talking about window controllers because, once you have a reference to 
> the window controller, it’s easy to find the content view controller.)
> 
> The storyboard is automatically instantiated in NSApplicationMain. (When the 
> instantiation happens, there must be a strong reference to the WC stored 
> somewhere, otherwise the WC would be deallocated, but it looks like you don’t 
> get access to that reference in Swift projects. In Obj-C, you used to get a 
> templated property on the app delegate.) What you can do instead is subclass 
> NSWindowController, and use ‘windowDidLoad’ as your opportunity to save your 
> own strong reference to the WC. (In Swift, I think I’d make it a static 
> property of the WC class. This also lets you check that nothing creates a 
> second main window.)

Using windowDidLoad() is a good idea. It is triggered at exactly the right time 
for my purposes. I already find myself setting other instance variables back up 
the storyboard controller hierarchy in similar circumstances. But don't I still 
need to use optionals if I declare the window controller or content view 
controller instance variable in AppDelegate but don't set it until later in the 
window controller's windowDidLoad() method? I am still at risk of using the 
instance variable before its value has been set. (I could solve that problem, 
or rather localize it, by not making it an instance variable but instead a 
local variable where I actually use it, but the whole point of my current 
exercise is to have a chain of storyboard scene cross references.)

You say you would make it a static property of the window controller class. But 
I need to refer to it in AppDelegate. So, I guess you're saying I can refer to 
a static class variable from anywhere. This is what the Swift language guide 
refers to as a "type property," right? I see from the guide that I can refer to 
it from any class in my application as a property of the type as opposed to a 
property of an instance. It strikes me that this is exactly what I need. And it 
feels so much more appropriate to place the reference in the window controller 
itself, instead of in AppDelegate. (So, a Swift "singleton" class can have a 
type property that refers to its own sole instance? And that type property is 
accessible everywhere in the application? Weird. And amazingly convenient. So 
much still to learn about Swift!)

> If you find this inconvenient or distasteful, your other alternative is to 
> take the “isInitialController” status off the WC in the storyboard, and 
> instantiate the WC yourself in (say) applicationDidFinishLaunching. Or, 
> almost the same thing, move the window and view scenes out of the main 
> storyboard into a separate storyboard. 

It is uncomfortable, but storyboards are making lots of things uncomfortable -- 
or, 

Re: Safe cross references between scenes in an OS X storyboard

[Quincey Morris]

On Mar 9, 2016, at 05:59 , Bill Cheeseman  wrote:
> 
> But the main thrust of my question was whether this is a safe and sensible 
> way to crossreference other storyboard scenes -- at least when 
> prepareForSegue(_:sender:) isn't available, as it isn't here. Having thought 
> about it for a while now, I guess it is a sensible approach. It has less to 
> do with storyboards than with the longstanding fact that NSApplication has a 
> 'mainwindow' property and NSWindow has a 'contentViewController' property.

I think you ended up solving the “wrong” problem. The lazy initialization is 
unnecessary, and so is the mucking about with optionals, because the window 
controller and window both exist by the time applicationDidFinishLaunching is 
invoked. The window isn’t main yet, but that’s the wrong place to look for it: 
apart from anything else, your proposed code is fragile because if your app 
ever has other windows that become main, even temporarily, you temporarily lose 
the ability to find your shoebox window.

(I’m talking about window controllers because, once you have a reference to the 
window controller, it’s easy to find the content view controller.)

The storyboard is automatically instantiated in NSApplicationMain. (When the 
instantiation happens, there must be a strong reference to the WC stored 
somewhere, otherwise the WC would be deallocated, but it looks like you don’t 
get access to that reference in Swift projects. In Obj-C, you used to get a 
templated property on the app delegate.) What you can do instead is subclass 
NSWindowController, and use ‘windowDidLoad’ as your opportunity to save your 
own strong reference to the WC. (In Swift, I think I’d make it a static 
property of the WC class. This also lets you check that nothing creates a 
second main window.)

If you find this inconvenient or distasteful, your other alternative is to take 
the “isInitialController” status off the WC in the storyboard, and instantiate 
the WC yourself in (say) applicationDidFinishLaunching. Or, almost the same 
thing, move the window and view scenes out of the main storyboard into a 
separate storyboard. 

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Safe cross references between scenes in an OS X storyboard

[Bill Cheeseman]

> On Mar 9, 2016, at 8:42 AM, Roland King  > wrote:
> 
> just
> 
>   return NSApp.mainWIndow?.contentViewController as? 
> MainContentViewController
> 
> works without all the guard and intermediate variables and still returns the 
> same optional.


Thanks. I should have remembered this is a more direct way to do it:

lazy var mainContentViewController: MainContentViewController? = {
NSApp.mainWindow?.contentViewController as? MainContentViewController
}()

But the main thrust of my question was whether this is a safe and sensible way 
to crossreference other storyboard scenes -- at least when 
prepareForSegue(_:sender:) isn't available, as it isn't here. Having thought 
about it for a while now, I guess it is a sensible approach. It has less to do 
with storyboards than with the longstanding fact that NSApplication has a 
'mainwindow' property and NSWindow has a 'contentViewController' property.

-- 

Bill Cheeseman - wjcheese...@comcast.net 
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: UICollectionView Moving

[Luther Baker]

Ok - I think this is the final question.

I've created a layout that is essentially a bunch of ragged bottom columns
- like a Trello or Kanban board. The items in the collection view are
"stories" with size around 100x100. To begin with, I prepopulate the
underlying datastore and things are great, I've got 2, 3 or 4 stories in
each column. Dragging around works just as expected.

In my case, a column is a SECTION. A 4 column board then has 4 sections.

Problem: if I move ALL the items out of a column (a column is a SECTION)
... I can't move anything back INTO the column (section). I don't think the
SECTION has any HEIGHT if it has no items ... and consequently, dragging a
"story" item over the area that represents a column does nothing because
the CollectionView doesn't actually create anything there if I have at 0
item layoutAttributes for that section.

Is there a specific way to do this? I still have a supplementary view as
the column header and it always appears ... and in a UITableView, I think,
if I have a empty section but have a section header, the built in move
functionality will allow me to drag an item over the section header and
allow me to drop into the section (but I can't remember if this is true)
--- but dragging an "story" item over the supplementary view does nothing.

In the worst case, do I need to keep some sort of hidden item as the first
element? I take all "stories" out of a column (section), should I put at
least one, invisible item in the column (section) to keep it available as a
drag target?

Hope that makes sense - I tend to be wordy.

Thanks,
-Luther



On Tue, Mar 8, 2016 at 12:05 AM, Luther Baker  wrote:

> Now we're cooking with GAS!!!
>
> override func applyLayoutAttributes(layoutAttributes:
> UICollectionViewLayoutAttributes) {
> print("apply layout attributes!: \(titleLabel.text)")
> }
>
> Thanks Man!
> -Luther
>
>
>
> On Mon, Mar 7, 2016 at 11:54 PM, Luke Hiesterman 
> wrote:
>
>> By teaching a cell to respond to an attribute I merely meant that it
>> should override setLayoutAttributes: and do something in there with the
>> relevant property. Hope that helps.
>>
>> Luke
>>
>> On Mar 7, 2016, at 9:39 PM, Luther Baker  wrote:
>>
>> > teach your cell classes to respond to that property
>>
>> Want to think about this out loud. Wondering what would 'trigger' a
>> lookup on the layout's layoutAttributesForItemAtIndexPath ... and where
>> would I store the indexPath I am dragging around.
>>
>> If I were to be more literal - in my view controller, I handle the
>> UIGestureRecognizerState.Began event. At this point, I can get the
>> indexPath of the element I am about to move and if I change something on
>> that cell at that time, it sticks for the life of the drag without
>> reference to layoutAttributes. I also handle the
>> UIGestureRecognizerState.Changed event and again, if I retrieve the cell at
>> the gesture's locationInView and change things in it ... those changes
>> stick until I let go of the drag.
>>
>> Stepping into the custom layout for a minute ... as you suggested, I am
>> now implementing layoutAttributesForInteractivelyMovingItemAtIndexPath ...
>> and that is getting invoked in response to the
>> updateInteractiveMovementTargetPosition call I am making as the gesture
>> location changes. Now, I know the collection view's methods are triggering
>> the layout's callbacks - but I'm not sure what would trigger me to fetch
>> the custom attributes you are suggesting. At a minimum, to ask the layout
>> for the attributes at that indexPath, I'd have to actually be tracking the
>> 'selectedIndexPath' in which case, I could just get the cell and modify it
>> directly.
>>
>> I guess I'm wondering how to "teach my cells classes to respond to that
>> property" ... Cells are reused so I'm not even sure how I'd go about
>> setting up and tearing down a KVO type relationship for the specific cell I
>> am dragging around. Maybe there is a WWDC video that digs into this? or
>> it's an easy explain?
>>
>> Sorry for being so long-winded. I'm not sure I'm communicating my
>> question well. Hope you can understand my underlying question and nudge me
>> the right way but at any rate, thanks for your help so far. I'd love to use
>> an elegant, "made for CollectionView" solution ... but I don't think I'm
>> looking at it correctly yet. Just in general I guess, how can a change to
>> the layoutAttributes cause my CollectionViewDelegate and DataSources to
>> fetch the cell I'm dragging around and change it (or does it not require
>> the delegates or datasources ... ?)
>>
>> Thanks,
>> -Luther
>>
>>
>>
>> On Mon, Mar 7, 2016 at 2:45 PM, Luke Hiesterman 
>> wrote:
>>
>>> You can create your own subclass of UICollectionViewLayoutAttributes and
>>> add something like an “isMoving” property to that. Then teach your cell
>>> classes to respond to that property by changing the background color.

Re: Safe cross references between scenes in an OS X storyboard

[Roland King]

> On 9 Mar 2016, at 21:32, Bill Cheeseman  wrote:
> 
> I am using storyboards in an OS X application written in Swift 2. It is a 
> single window "shoebox" application that does not use NSDocument or Core 
> Data. It is built with the Xcode 7.2.1 storyboard template, where the 
> storyboard entry point is the main window controller scene and a "window 
> content" relationship segue leads to the window's content view scene.
> 
> In my AppDelegate class, I want to declare an instance property referring to 
> the main window's content view controller. I need to refer to the content 
> view controller because my AppDelegate provides programmatic content for one 
> of the menu bar's menus and it needs to update a duplicate of that menu in a 
> popup button in the content view. I anticipate needing a reference to the 
> content view controller for other purposes, too, so I want to avoid 
> duplicating code by putting it in an instance variable.
> 
> It is of course impossible to set the property's value before the window's 
> content view controller exists. The applicationDidFinishLaunching(_:) 
> delegate method is apparently too early. If I set it there with 
> 'mainContentViewController = NSApp.mainWindow!.contentViewController as! 
> MainContentViewController', I get this fatal error at launch: "unexpectedly 
> found nil while unwrapping an Optional value."
> 
> I therefore set it using a lazy instance variable, like this:
> 
>lazy var mainContentViewController: MainContentViewController = {
>NSApp.mainWindow!.contentViewController as! MainContentViewController
>}()
> 
> This works fine -- but only if I take care to use the instance variable after 
> the content view controller becomes available. My question is whether the 
> following is a safe and sensible way to take care of the possibility that I 
> might accidentally try to use it too early:
> 
>lazy var mainContentViewController: MainContentViewController? = {
>guard let window = NSApp.mainWindow,
>let controller = window.contentViewController
>else {return nil}
>return controller as? MainContentViewController
>}()
> 
> (I tried returning 'controller as! MainContentViewController', but I got this 
> warning: "Treating a forced downcast to 'MainContentViewController' as 
> optional will never produce 'nil'." I have to declare the variable as an 
> Optional type because the guard statement might return nil.)
> 
> — 


just

return NSApp.mainWIndow?.contentViewController as? 
MainContentViewController

works without all the guard and intermediate variables and still returns the 
same optional. 


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Safe cross references between scenes in an OS X storyboard

[Bill Cheeseman]

I am using storyboards in an OS X application written in Swift 2. It is a 
single window "shoebox" application that does not use NSDocument or Core Data. 
It is built with the Xcode 7.2.1 storyboard template, where the storyboard 
entry point is the main window controller scene and a "window content" 
relationship segue leads to the window's content view scene.

In my AppDelegate class, I want to declare an instance property referring to 
the main window's content view controller. I need to refer to the content view 
controller because my AppDelegate provides programmatic content for one of the 
menu bar's menus and it needs to update a duplicate of that menu in a popup 
button in the content view. I anticipate needing a reference to the content 
view controller for other purposes, too, so I want to avoid duplicating code by 
putting it in an instance variable.

It is of course impossible to set the property's value before the window's 
content view controller exists. The applicationDidFinishLaunching(_:) delegate 
method is apparently too early. If I set it there with 
'mainContentViewController = NSApp.mainWindow!.contentViewController as! 
MainContentViewController', I get this fatal error at launch: "unexpectedly 
found nil while unwrapping an Optional value."

I therefore set it using a lazy instance variable, like this:

lazy var mainContentViewController: MainContentViewController = {
NSApp.mainWindow!.contentViewController as! MainContentViewController
}()

This works fine -- but only if I take care to use the instance variable after 
the content view controller becomes available. My question is whether the 
following is a safe and sensible way to take care of the possibility that I 
might accidentally try to use it too early:

lazy var mainContentViewController: MainContentViewController? = {
guard let window = NSApp.mainWindow,
let controller = window.contentViewController
else {return nil}
return controller as? MainContentViewController
}()

(I tried returning 'controller as! MainContentViewController', but I got this 
warning: "Treating a forced downcast to 'MainContentViewController' as optional 
will never produce 'nil'." I have to declare the variable as an Optional type 
because the guard statement might return nil.)

-- 

Bill Cheeseman - wjcheese...@comcast.net

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com