Re: Context Menu and first responder targets

2023-03-05 Thread Graham Cox via Cocoa-dev
Hi Eyal,

I believe the target for a pop-up menu is the view that you pass in that 
method, at least initially. If there is an established responder chain from 
that view to other responders (up to and including First Responder) then the 
menu items should reach their target. But it’s pretty easy to break that chain, 
for example if the view isn’t set as allowing itself to become first responder. 
Just having a pop-up menu doesn’t refocus the view.

The usual approach is to create a pop-up menu in IB and wire it directly to the 
view that pops it up, targeting actions as needed. You don’t need to do 
anything special to make this menu pop-up, it will do so automatically when you 
right-click, and the target is directly set as the view (or other objects) so 
the whole responder chain management is avoided. If your menu is more dynamic, 
and creating a static menu in IB doesn’t seem to be a good fit, look at the 
menu delegation protocol, which allows you to populate a menu on the fly. You 
can still create a placeholder in IB to get automatic pop-up behaviour.

—Graham

(Forgive any misinformation, I’m getting a little rusty).

> On 6 Mar 2023, at 3:27 am, Eyal Redler via Cocoa-dev 
>  wrote:
> 
> Hi, 
> 
> 
> I'm using popUpContextMenu:withEvent:forView: to show a context menu. The 
> menu contains several items whose target is the first responder (that is, 
> nil). But the items are not enabled and if I turn off autoEnable then the 
> action is never called on the first responder.
> 
> Same target/action setup works just fine for the same items in the main menu, 
> as expected.
> 
> Is this by design or am I missing something?
> 
> Tia
> 
> Eyal Redler
> 
> "If Uri Geller bends spoons with divine powers, then he's doing it the hard 
> way."
> --James Randi
> www.eyalredler.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/graham.cox%40bigpond.com
> 
> This email sent to graham@bigpond.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: Prevent screen saver from starting, but don't prevent computer sleep

2020-06-29 Thread Graham Cox via Cocoa-dev
Then look at some of the other options in that API, e.g. 
IOPMAssertionDeclareUserActivity

AFACS, this is the supported way to do the kinds of things you want, of it can 
be done at all.


> On 29 Jun 2020, at 4:51 pm, Gabriel Zachmann  wrote:
> 
>> but the header for that function says it can be replaced by 
>> IOPMAssertionCreateWithName(). I haven’t looked at that in detail or used it 
>> myself, but one of the defines for that function is 
>> ‘kIOPMAssertionTypePreventUserIdleDisplaySleep’, which appears to do the 
>> same thing as the old
> 
> Would that also prevent the compute from going to sleep?
> 
> Also, I do not want to prevent the display from going to sleep.
> I want to prevent the screen saver to kick in.
> 
> Best regards, Gabriel
> 
> 

___

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: Prevent screen saver from starting, but don't prevent computer sleep

2020-06-28 Thread Graham Cox via Cocoa-dev
In the “old days”, your app could periodically call UpdateSystemActivity( 
UsrActivity ) to prevent the screensaver kicking in. This has been deprecated 
since 10.8, but the header for that function says it can be replaced by 
IOPMAssertionCreateWithName(). I haven’t looked at that in detail or used it 
myself, but one of the defines for that function is 
‘kIOPMAssertionTypePreventUserIdleDisplaySleep’, which appears to do the same 
thing as the old UpdateSystemActivity() call.

Apologies if you already discussed this and rejected it for some reason, but 
otherwise, it may be worth checking out.

—Graham



> On 29 Jun 2020, at 5:31 am, Gabriel Zachmann via Cocoa-dev 
>  wrote:
> 
> Yes, agreed.  That is why I would like to disable ONLY the screensaver, 
> NOT System Preferences / Security / Require password ...
> 

___

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: Prevent screen saver from starting, but don't prevent computer sleep

2020-06-27 Thread Graham Cox via Cocoa-dev
You can make your app trigger a command-line program and pass params using 
NSTask. It’s not difficult to use. But in this case you might want to negotiate 
this with the user - apps that just go ahead and change MY system preferences 
are being user-hostile to say the least.

—Graham



> On 28 Jun 2020, at 2:46 am, Gabriel Zachmann via Cocoa-dev 
>  wrote:
> 
> Basically, what I'd like to do in my app is what I can do using this on the 
> command line:
> 
>   defaults -currentHost write com.apple.screensaver idleTime

___

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: Launching in fullscreen gives "Funk" sound sometimes

2020-06-24 Thread Graham Cox via Cocoa-dev
Set a symbolic breakpoint on NSBeep and see whether it’s your code that’s 
calling it.

—Graham



> On 24 Jun 2020, at 7:23 pm, Gabriel Zachmann via Cocoa-dev 
>  wrote:
> 
> I have an app that should switch to fullscreen automatically, 
> if it is launched with a specific flag.
> 
> This is my code to switch to fullscreen at startup (in AppDelegate.m):
> 
> - (void) applicationWillFinishLaunching: (NSNotification *) notification
> {
>[self.window setFrameAutosaveName: @"de.zach.ArtSaverApp"];   // make 
> window "remember" its positions & size; do it before handling "-f"
> 
>bool startInFullScreen = NO;
> 
>// check flags ...
> 
>if ( startInFullScreen )
>[self.window toggleFullScreen: nil];  
> }
> 
> 
> The problem is that , sometimes, the app does not receive keystrokes.
> At least, I get the typical "Funk" sound when typing a key,
> just like what occurs sometimes in other apps, when the focus is somehow out 
> of sync.
> 
> The problem occurs only sometimes, but I could not find a pattern.
> (Maybe, it's got something to do with timing?)
> Should I put the switch to fullscreen mode somewhere else?
> 
> 
> I tried to add this in -viewDidLoad in MasterWindowController:
> 
>[[[self view] window] makeKeyAndOrderFront: NULL]; 
> 
> But it didn't help.
> 
> Of course, when the app launches normally, and does not call toggleFullScreen,
> then everything is fine with the keyboard focus.
> 
> 
> Any insights or ideas will be greatly appreciated.
> 
> Best regards, Gabriel
> 
> ___
> 
> 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/graham.cox%40bigpond.com
> 
> This email sent to graham@bigpond.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