Re: Triggering a segue from code

2016-09-25 Thread 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 
> <quinceymor...@rivergatesoftware.com> wrote:
> 
> On Sep 25, 2016, at 11:59 , mail...@ericgorr.net 
> <mailto: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

2016-09-25 Thread 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 
<https://github.com/ericgorr/nspanel_show>



> On Sep 19, 2016, at 11:07 PM, Quincey Morris 
> <quinceymor...@rivergatesoftware.com> wrote:
> 
> On Sep 19, 2016, at 18:10 , mail...@ericgorr.net 
> <mailto: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

2016-09-19 Thread 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 
> <quinceymor...@rivergatesoftware.com> wrote:
> 
> On Sep 18, 2016, at 12:22 , mail...@ericgorr.net 
> <mailto: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

Triggering a segue from code

2016-09-18 Thread mail...@ericgorr.net
For reference, I have a sample project location at 

https://github.com/ericgorr/nspanel_show

It is a Document Based and Storyboard application.

On my main window, I have a toolbar with an Toolbar Item called 'Inspector'. I 
have defined a segue between this item and my Inspector Utility Panel called 
"Show Inspector". When I press the Inspector toolbar item, the utility panel 
does show as expected. I can close the panel by pushing the standard window 
close button.

What I would like to do is trigger my "Show Inspector" segue when I push the 
"Show Panel" button. I have tried the code:

@IBAction func showMyPanel( _ sender: AnyObject )
{
NSLog( "How do I show the panel?" )

self.performSegue( withIdentifier: "Show Inspector", sender: self )

}
   
While I do see the log message 'How do I..', my utility panel is not shown.

How can I get this work?

Here is an image that shows the basic setup in Interface Builder.

https://github.com/ericgorr/nspanel_show/blob/master/extra/Screen%20Shot%202016-09-17%20at%208.13.23%20PM.png


___

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

Best method for showing & hiding an inspector nspanel

2016-09-11 Thread mail...@ericgorr.net
I have a sample git project here: https://github.com/ericgorr/nspanel_show

I am working on a swift, core data, and storyboard application.

If it matters, I am using the latest official version of Xcode and OS X.

I can easily show the nspanel by creating a button a called “Show Panel Segue” 
and creating a Show Segue between the button and the Panel Scene. However, I 
get a new panel window every time I press the button. Is there a way to limit 
it to just a single instance? Is using a segue to show the panel the best 
method? If not, what is recommended?

For a storyboard application, what then is the recommended way to hide the 
inspector nspanel?




___

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