Re: Triggering a segue from code

[mail...@ericgorr.net]

Based on stuff I have been playing with, #2 seems like the “right” solution 
based on the design of the framework. A segue is currently not designed to 
support this behavior and it is always a mistake, I have learned, to try to 
fight the framework (which eliminates #1 & #4).


> On Sep 25, 2016, at 3:52 PM, Quincey Morris 
>  wrote:
> 
> On Sep 25, 2016, at 11:59 , mail...@ericgorr.net 
>  wrote:
>> 
>> 2. The reason why I do a performClose is because I want it to do the same 
>> thing as when the user presses the close button on the panel, which they are 
>> allowed to do. Unless I were to remove the close button from the inspector 
>> panel (which I do not want to do), my overall problem remains. 
> 
> 
> There are a couple of different approaches you can take:
> 
> 1. You know now that if you performClose or close the panel, a storyboard 
> segue is going to create a new instance. You can deal with that by keeping 
> enough panel state outside the panel view controller to re-configure a new 
> panel if it’s created. That is, you don’t need the existence of the panel to 
> be continuous. All you need is one panel at a time.
> 
> 2. Don’t use segues for this. Move the panel to its own storyboard or XIB 
> file. (Instantiate the storyboard in code, or load the NIB via the view 
> controller initWithNibName initializer.)
> 
> 3. Don’t do the performClose behavior. The point of the button-highlighting 
> behavior is to indicate the window being affected when the user does 
> something non-specific like choosing File -> Close or typing Command-W. 
> Neither of those (presumably) will affect your inspector panel — otherwise 
> it’d be too confusing for the user, whether a document window or the 
> inspector was going to be closed.
> 
> If the user has to click a button (e.g. toolbar or regular window button) to 
> hide the inspector, the animated interaction *is* that button’s down/up 
> transition, so there’s no need for it in the panel’s title bar.
> 
> 4. You could, I suppose, subclass NSPanel and override the “close” method. 
> The documentation says that “performClose” invokes “close”. You should be 
> able to have the “close” override  do an “orderOut:” instead.
> 

___

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: Triggering a segue from code

[Quincey Morris]

On Sep 25, 2016, at 11:59 , mail...@ericgorr.net wrote:
> 
> 2. The reason why I do a performClose is because I want it to do the same 
> thing as when the user presses the close button on the panel, which they are 
> allowed to do. Unless I were to remove the close button from the inspector 
> panel (which I do not want to do), my overall problem remains. 


There are a couple of different approaches you can take:

1. You know now that if you performClose or close the panel, a storyboard segue 
is going to create a new instance. You can deal with that by keeping enough 
panel state outside the panel view controller to re-configure a new panel if 
it’s created. That is, you don’t need the existence of the panel to be 
continuous. All you need is one panel at a time.

2. Don’t use segues for this. Move the panel to its own storyboard or XIB file. 
(Instantiate the storyboard in code, or load the NIB via the view controller 
initWithNibName initializer.)

3. Don’t do the performClose behavior. The point of the button-highlighting 
behavior is to indicate the window being affected when the user does something 
non-specific like choosing File -> Close or typing Command-W. Neither of those 
(presumably) will affect your inspector panel — otherwise it’d be too confusing 
for the user, whether a document window or the inspector was going to be closed.

If the user has to click a button (e.g. toolbar or regular window button) to 
hide the inspector, the animated interaction *is* that button’s down/up 
transition, so there’s no need for it in the panel’s title bar.

4. You could, I suppose, subclass NSPanel and override the “close” method. The 
documentation says that “performClose” invokes “close”. You should be able to 
have the “close” override  do an “orderOut:” instead.

___

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: Triggering a segue from code

[mail...@ericgorr.net]

Thank you again for your reply Quincey. 

1. I have updated the code to keep a reference to the window controller instead 
of the window as you suggest. As you suspected, the bad behavior does not 
change.

2. The reason why I do a performClose is because I want it to do the same thing 
as when the user presses the close button on the panel, which they are allowed 
to do. Unless I were to remove the close button from the inspector panel (which 
I do not want to do), my overall problem remains. 

At this point, I may be left with simply using one of my TSI’s to resolve this 
problem and determine what the correct behavior is. It will be interesting if 
this turns out to be a bug that needs to be reported.

If anyone has any ideas on how I can get this working as expected, please let 
me know.

Again, the sample test project is located at:

https://github.com/ericgorr/nspanel_show 




> On Sep 19, 2016, at 11:07 PM, Quincey Morris 
>  wrote:
> 
> On Sep 19, 2016, at 18:10 , mail...@ericgorr.net 
>  wrote:
>> 
>> The strange behavior I am now seeing is that when I show & hide the panel 
>> using the buttons are what appears to be two (not three, not four, etc.) 
>> different instances of the inspector panel. The autosave information only 
>> appears to apply to one but not the other.
> 
> A couple of things:
> 
> 1. You’re keeping the panel window instance reference in 
> InspectorWindowController.sharedInstance, but not keeping a reference to its 
> window controller. That causes its window controller to be deallocated early, 
> although that likely has nothing to with the rest of the problem, since the 
> panel doesn’t have any custom behavior yet. You should keep a reference to 
> the window controller instead, and that will keep the panel alive too.
> 
> 2. You’re doing a “performClose” to hide the panel. If you do an orderOut 
> instead, you get the behavior you want.
> 
> Note that you are getting a new instance of the panel because the window 
> segue mechanism decides the first one has disappeared. Again because it’s not 
> documented how window segues work, there’s no way of knowing what the 
> “correct” behavior is supposed to be. (Your panel window is correctly set to 
> “Single” mode in the storyboard, which is what’s supposed to prevent multiple 
> instances from appearing.)
> 
> Also undocumented — forever AFAIK although others on this list may know more 
> about this — is what a window “close” (or “performClose”) does, other than 
> ordering out the window and (if it’s set to release on close) to release it. 
> Whatever a “close” actually does, it’s making the storyboard mechanism unable 
> to find the panel instance, so it creates a new one. (Your panel is *not* set 
> to release on close, and I was able to verify that it’s not being released 
> regardless, so this is not anything you appear to be doing wrong.)
> 

___

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: Triggering a segue from code

[Kyle Sluder]

On Sep 22, 2016, at 10:13 PM, Shane Stanley  wrote:
> 
>> On 23 Sep. 2016, at 1:17 pm, Kyle Sluder  wrote:
>> 
>> -close used to render windows more thoroughly dead
> 
> So can we assume that the close button generally calls -close?

No. You can assume it is morally similar to -performClose, but that is all the 
documentation promises.

> 
> On a tangent here...
> 
> In Safari, it used to be that if a script asked for the app's windows, 
> -orderedWindows would return a list of open windows. Under Sierra, however, 
> the list returned can include windows that have been closed via the close box 
> -- you might have closed them half-an-hour ago. They show with a visible 
> property of false, but by setting it to true they reappear -- no Web 
> contents, but the URL, title, etc all intact. And the only way to close them 
> is again via script -- their close buttons do nothing.
> 
> It's probably just a bug, although DTS don't seem to think so, but these 
> windows seem surprisingly resistant to death.

Did you file a Radar or merely contact DTS? Note that starting in Sierra you 
can use Cmd-Z to unclose more than just the most-recently-closed tab.

--Kyle Sluder

> 
> -- 
> Shane Stanley 
> , 
> 
> 


___

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: Triggering a segue from code

[Shane Stanley]

On 23 Sep. 2016, at 1:17 pm, Kyle Sluder  wrote:
> 
> -close used to render windows more thoroughly dead

So can we assume that the close button generally calls -close?

On a tangent here...

In Safari, it used to be that if a script asked for the app's windows, 
-orderedWindows would return a list of open windows. Under Sierra, however, the 
list returned can include windows that have been closed via the close box -- 
you might have closed them half-an-hour ago. They show with a visible property 
of false, but by setting it to true they reappear -- no Web contents, but the 
URL, title, etc all intact. And the only way to close them is again via script 
-- their close buttons do nothing.

It's probably just a bug, although DTS don't seem to think so, but these 
windows seem surprisingly resistant to death.

-- 
Shane Stanley 
, 



___

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: Triggering a segue from code

[Quincey Morris]

On Sep 22, 2016, at 20:17 , Kyle Sluder  wrote:
> 
> And as Eric has discovered, it instructs the
> Storyboard runtime to create a new instance of the window controller
> rather than unhiding the existing one.

Thanks for clarifying this all. I think the upshot of it is that closing a 
window has a number of side effects (that are unsurprising), but there’s also a 
private “is closed” state that controls its future behavior, but is not 
accessible by developers.

The follow-on question (Life of Brian notwithstanding) is then what state 
transitions the window can have after it’s closed. Can it be shown? How does it 
relate to the window controller or document later?

___

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: Triggering a segue from code

[Kyle Sluder]

On Thu, Sep 22, 2016, at 02:47 PM, Quincey Morris wrote:
> On Sep 22, 2016, at 12:34 , Kyle Sluder  wrote:
> > 
> > -close asks the window’s delegate (via -windowShouldClose:) if it should
> > close. If the window is owned by a window controller that’s associated
> > with a document, the document will also get a chance to weigh in via
> > -shouldCloseWindowController:…. It will also send
> > NSWindowWillCloseNotification.
> > 
> > -orderOut: just hides the window (removes it from the window list). You
> > can always order it back in again later.
> 
> Yes, but ignore for a moment the “shouldClose…” interaction, and assume
> the window is NOT set to release on close. What *else* does “close” do
> vs. “orderOut”?

This question sounds vaguely similar to “What have the Romans done for
us?” from Life of Brian. ;-)

> 
> The example app mentioned in this thread demonstrates that “close” has
> some other effect beyond what “orderOut” does. In particular, a
> “single”-mode storyboard segue re-uses an ordered-out window, but not a
> closed one.

I must first admit, especially for the benefit of anyone who read the
documentation after I replied to you, that I was mistaken.
-shouldCloseWindowController: and -windowShouldClose: are only sent from
-performClose:, not from -close. Which makes sense: -close is the
unconditional way for an app (that might have even implemented its own
confirmation flow) to close a window.

Having made my apologies, -orderOut: and -close live at two levels of
abstraction. -orderOut deals with the window’s order and membership in
the window list. -close deals with higher-level semantics like window
controllers, documents, and notifications. As part of these higher-level
semantics, -close calls -orderOut:. For document-based apps, it also
dissociates the window from the document (and the window controller the
document made for it). And as Eric has discovered, it instructs the
Storyboard runtime to create a new instance of the window controller
rather than unhiding the existing one.

(-close used to render windows more thoroughly dead in the era of
releaseWhenClosed and one-shot backing stores. But those days are in the
past.)

--Kyle Sluder

___

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: Triggering a segue from code

[Quincey Morris]

On Sep 22, 2016, at 12:34 , Kyle Sluder  wrote:
> 
> -close asks the window’s delegate (via -windowShouldClose:) if it should
> close. If the window is owned by a window controller that’s associated
> with a document, the document will also get a chance to weigh in via
> -shouldCloseWindowController:…. It will also send
> NSWindowWillCloseNotification.
> 
> -orderOut: just hides the window (removes it from the window list). You
> can always order it back in again later.

Yes, but ignore for a moment the “shouldClose…” interaction, and assume the 
window is NOT set to release on close. What *else* does “close” do vs. 
“orderOut”?

The example app mentioned in this thread demonstrates that “close” has some 
other effect beyond what “orderOut” does. In particular, a “single”-mode 
storyboard segue re-uses an ordered-out window, but not a closed one.

___

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: Triggering a segue from code

[Kyle Sluder]

On Mon, Sep 19, 2016, at 10:07 PM, Quincey Morris wrote:
> On Sep 19, 2016, at 18:10 , mail...@ericgorr.net
>  wrote:
> > 
> > The strange behavior I am now seeing is that when I show & hide the panel 
> > using the buttons are what appears to be two (not three, not four, etc.) 
> > different instances of the inspector panel. The autosave information only 
> > appears to apply to one but not the other.
> 
> A couple of things:
> 
> 1. You’re keeping the panel window instance reference in
> InspectorWindowController.sharedInstance, but not keeping a reference to
> its window controller. That causes its window controller to be
> deallocated early, although that likely has nothing to with the rest of
> the problem, since the panel doesn’t have any custom behavior yet. You
> should keep a reference to the window controller instead, and that will
> keep the panel alive too.
> 
> 2. You’re doing a “performClose” to hide the panel. If you do an orderOut
> instead, you get the behavior you want.
> 
> Note that you are getting a new instance of the panel because the window
> segue mechanism decides the first one has disappeared. Again because it’s
> not documented how window segues work, there’s no way of knowing what the
> “correct” behavior is supposed to be. (Your panel window is correctly set
> to “Single” mode in the storyboard, which is what’s supposed to prevent
> multiple instances from appearing.)
> 
> Also undocumented — forever AFAIK although others on this list may know
> more about this — is what a window “close” (or “performClose”) does,
> other than ordering out the window and (if it’s set to release on close)
> to release it.

-performClose: is documented to highlight the Close button, so that it
is highlighted if any “unsaved changes” confirmation sheets are
displayed. That helps the user understand what will happen to the
document window if they confirm the Save panel.

-close asks the window’s delegate (via -windowShouldClose:) if it should
close. If the window is owned by a window controller that’s associated
with a document, the document will also get a chance to weigh in via
-shouldCloseWindowController:…. It will also send
NSWindowWillCloseNotification.

-orderOut: just hides the window (removes it from the window list). You
can always order it back in again later.

--Kyle Sluder

> Whatever a “close” actually does, it’s making the
> storyboard mechanism unable to find the panel instance, so it creates a
> new one. (Your panel is *not* set to release on close, and I was able to
> verify that it’s not being released regardless, so this is not anything
> you appear to be doing wrong.)
> 
> ___
> 
> 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/kyle%40ksluder.com
> 
> This email sent to k...@ksluder.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: Triggering a segue from code

[Quincey Morris]

On Sep 19, 2016, at 18:10 , mail...@ericgorr.net  
wrote:
> 
> The strange behavior I am now seeing is that when I show & hide the panel 
> using the buttons are what appears to be two (not three, not four, etc.) 
> different instances of the inspector panel. The autosave information only 
> appears to apply to one but not the other.

A couple of things:

1. You’re keeping the panel window instance reference in 
InspectorWindowController.sharedInstance, but not keeping a reference to its 
window controller. That causes its window controller to be deallocated early, 
although that likely has nothing to with the rest of the problem, since the 
panel doesn’t have any custom behavior yet. You should keep a reference to the 
window controller instead, and that will keep the panel alive too.

2. You’re doing a “performClose” to hide the panel. If you do an orderOut 
instead, you get the behavior you want.

Note that you are getting a new instance of the panel because the window segue 
mechanism decides the first one has disappeared. Again because it’s not 
documented how window segues work, there’s no way of knowing what the “correct” 
behavior is supposed to be. (Your panel window is correctly set to “Single” 
mode in the storyboard, which is what’s supposed to prevent multiple instances 
from appearing.)

Also undocumented — forever AFAIK although others on this list may know more 
about this — is what a window “close” (or “performClose”) does, other than 
ordering out the window and (if it’s set to release on close) to release it. 
Whatever a “close” actually does, it’s making the storyboard mechanism unable 
to find the panel instance, so it creates a new one. (Your panel is *not* set 
to release on close, and I was able to verify that it’s not being released 
regardless, so this is not anything you appear to be doing wrong.)

___

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: Triggering a segue from code

[mail...@ericgorr.net]

Thank you for your reply Quincey. I am definitely getting closer to the 
behavior I want. 

Performing the “Show Inspector” segue from the my custom document window 
controller (WindowController.swift) allows both by regular button and toolbar 
button to show the Inspector.

As you suggested, I also created a  custom window controller for my inspector 
(InspectorWindowController.swift). It looks like:

class InspectorWindowController: NSWindowController
{
static var sharedInstance: NSWindow? = nil

override func windowDidLoad()
{
super.windowDidLoad()

InspectorWindowController.sharedInstance = self.window
}
}

This does allow my hide panel action function to hide the panel by doing:

@IBAction func hideMyPanel( _ sender: AnyObject )
{
InspectorWindowController.sharedInstance?.performClose( self )
}


The strange behavior I am now seeing is that when I show & hide the panel using 
the buttons are what appears to be two (not three, not four, etc.) different 
instances of the inspector panel. The autosave information only appears to 
apply to one but not the other.

I have updated the project which should replicate this behavior.

If you or anyone else has any ideas on how I can get the correct behavior for 
showing and hiding the inspector NSPanel, I would be interested.


> On Sep 18, 2016, at 4:32 PM, Quincey Morris 
>  wrote:
> 
> On Sep 18, 2016, at 12:22 , mail...@ericgorr.net 
>  wrote:
>> 
>> While I do see the log message 'How do I..', my utility panel is not shown.
>> 
>> How can I get this work?
> 
> Most of the problem is that storyboards and segues for the Mac are 
> inadequately documented. This is exacerbated by the fact that understanding 
> the behavior “by analogy with iOS” breaks down when windows are involved, 
> since there’s no such thing (AFAIK) as a segue between windows on iOS.
> 
> By trial and error, I discovered that the problem in your sample project is 
> that a “show” segue from a view controller does not open a new window. This 
> halfway makes sense, although the fact that it does nothing and produces no 
> exception or log message is pretty unhelpful. (Bug report!)
> 
> To get the button to display the panel, you need to have the window 
> controller perform the segue. That means you’ll need a custom window 
> controller subclass for the main window, and you can just move the action 
> method into the window controller. (Hook the button up to First Responder 
> instead of the view controller, too.)
> 
> Alternatively, go back to using a segue from the button to open the panel, 
> which IIRC was working in an earlier version of this test project. (You 
> posted that it wasn’t working, but when I went to look at your project you’d 
> already fixed the problem in your project that was preventing it from 
> working. IIRC.)
> 
> To do all the combinations of hiding and showing a singleton panel, you’ll 
> probably want another custom window controller subclass for the panel itself. 
> Not every window/window controller operation seems to be mapped into 
> storyboard semantics, so you should expect that there are things that still 
> need to be done “the old way”.
> 

___

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: Triggering a segue from code

[Quincey Morris]

On Sep 18, 2016, at 12:22 , mail...@ericgorr.net wrote:
> 
> While I do see the log message 'How do I..', my utility panel is not shown.
> 
> How can I get this work?

Most of the problem is that storyboards and segues for the Mac are inadequately 
documented. This is exacerbated by the fact that understanding the behavior “by 
analogy with iOS” breaks down when windows are involved, since there’s no such 
thing (AFAIK) as a segue between windows on iOS.

By trial and error, I discovered that the problem in your sample project is 
that a “show” segue from a view controller does not open a new window. This 
halfway makes sense, although the fact that it does nothing and produces no 
exception or log message is pretty unhelpful. (Bug report!)

To get the button to display the panel, you need to have the window controller 
perform the segue. That means you’ll need a custom window controller subclass 
for the main window, and you can just move the action method into the window 
controller. (Hook the button up to First Responder instead of the view 
controller, too.)

Alternatively, go back to using a segue from the button to open the panel, 
which IIRC was working in an earlier version of this test project. (You posted 
that it wasn’t working, but when I went to look at your project you’d already 
fixed the problem in your project that was preventing it from working. IIRC.)

To do all the combinations of hiding and showing a singleton panel, you’ll 
probably want another custom window controller subclass for the panel itself. 
Not every window/window controller operation seems to be mapped into storyboard 
semantics, so you should expect that there are things that still need to be 
done “the old way”.

___

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