Re: Context Menu and first responder targets
Thanks Graham, To explain the context, this menu pops out from a custom view in a toolbar item and needs to target the selection in the window so I can't wire it directly to the actual target since it is dynamic. Using the information you supplied, I was able to make this work by passing the current first responder as the view to popUpContextMenu:withEvent:forView This solves the issue but I do wish there was a way to make a context menu behave just like the menus in the menu bar, with target set to nil, it would adjust and send the action to the first responder. Eyal > On 6 Mar 2023, at 1:43, Graham Cox wrote: > > 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
Context Menu and first responder targets
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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Read Extended Attributes with Finder Sync Extension
I'm working on adding a finder sync extension to an app. The app is not sandboxed. In essence, the app is operating on files located in folders that the user chooses, the app stores the status information in an extended attribute for each file. The extension needs to monitor these folders and and assign a badge according to the state indicated in the extended attribute. Everything is working fine, I can get the app and extension to communicate which folders to watch, I can manipulate the files with the app, setting the extended attributes and the extension is getting requestBadgeIdentifierForURL called. However, attempting to read the the extended attribute using getxattr() is blocked by the sandbox. I tried creating an app group and to store the folder urls as security scoped bookmarks in the group but this fails when trying to resolve the bookmark. In retrospect this makes sense since the security scoped bookmark is supposed to be used for accessing the same url by the same app in the same sandbox which is not the case when dealing with an un-sandboxed app and a sandboxed Finder Find Extension. I read somewhere (here: https://developer.apple.com/forums/thread/66259?page=2) from someone, quoting DTS on a similar issue that he can either communicate to the main app process to get the information or use document scoped security scoped bookmarks but I'm having trouble finding information about document scoped bookmarks and I'm not sure if it makes sense either. Thanks in advance 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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Auto-layout, Forcing a top-level view to hug its contents
I have a view in a nib, the constraints are setup so that the view should expand/contract to fit the contents and the nib is localized for several languages. When I check the frame size of the view in awakeFromNib the size I get is the same as the size set in the nib. I tried forcing the view to resize by calling layout but this didn't change the frame size. Is there a way to force the view to resize, before putting it on the screen? 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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Xcode 14 minimum deployment target
Could be, but I just found in the xcode 14 release notes: • Building for deployment to OS releases older than macOS 10.13, iOS 11, tvOS 11, and watchOS 4 is no longer supported. (92834476) https://developer.apple.com/documentation/xcode-release-notes/xcode-14-release-notes Yet I'm am able to do just that without an issue... Eyal > On 28 Oct 2022, at 13:54, Saagar Jha wrote: > > I believe Xcode 14 has the old macOS bits (with the new iOS SDK). Try 14.1? > >> On Oct 28, 2022, at 03:51, Eyal Redler via Cocoa-dev >> wrote: >> >> I read somewhere (can't recall where) that xcode 14 will not support >> deployment target < macOS 10.13. >> I was bracing myself for having to somehow develop my app on two machines >> for a while or ditching my pre 10.13 users but after installing xcode 14 on >> my new M1 machine I found out that I can compile and build my app with >> minimum deployment target of 10.9 and could not find an issue when running >> it on 10.9. >> >> I'm not sure what to make of it, did I misunderstand this, is it a fluke? >> Did Apple change their policy? >> >> 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/saagar%40saagarjha.com >> >> This email sent to saa...@saagarjha.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
Xcode 14 minimum deployment target
I read somewhere (can't recall where) that xcode 14 will not support deployment target < macOS 10.13. I was bracing myself for having to somehow develop my app on two machines for a while or ditching my pre 10.13 users but after installing xcode 14 on my new M1 machine I found out that I can compile and build my app with minimum deployment target of 10.9 and could not find an issue when running it on 10.9. I'm not sure what to make of it, did I misunderstand this, is it a fluke? Did Apple change their policy? 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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSControl subclass and accessibility
Thank you.
Eyal
> On 13 Mar 2022, at 18:31, Rob Petrovec wrote:
>
> Accessibility for NSControls is handled by the NSCell inside it, not the
> NSControl. Good luck.
>
> —Rob
>
>
>> On Mar 13, 2022, at 7:55 AM, Eyal Redler via Cocoa-dev
>> wrote:
>>
>> Hi,
>>
>> I'm having trouble getting a custom NSControl subclass properly visible with
>> regards to accessibility.
>>
>> If I implement my custom control as an NSView subclass and adopt the
>> NSAccessibilityButton protocol, I can "see" my custom control with
>> accessibility inspector when I hover above it.
>> If I take the same class but make it a subclass of NSControl, I'm not able
>> to "see" my control using accessibility inspector when hovering above it. It
>> is detecting something because I can see that when I hover in the containing
>> view, I can see the window ui element, but when I hover above the control
>> itself, I'm only seeing the "app" element. Also, when I inspect the
>> containing view I can see my control listed there and I can access it and
>> perform the action.
>>
>> I feel like I'm missing something obvious. Any ideas?
>>
>> Here's my code, If I replace NSControl with NSView, it seems to work great.
>>
>> @interface MyFancyButton : NSControl
>>
>> @end
>>
>> @implementation MyFancyButton
>> - (void)drawRect:(NSRect)dirtyRect ...
>>
>> - (void)mouseDown:(NSEvent *)event ...
>>
>> - (void)simulateClick ...
>>
>>
>> - (nullable NSString *)accessibilityLabel
>> {
>> return @"my_label";
>> }
>> - (BOOL)accessibilityPerformPress
>> {
>> [self simulateClick];
>> return YES;
>> }
>> @end
>>
>> Thanks in advance,
>>
>>
>>
>>
>> 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/petrock%40mac.com
>>
>> This email sent to petr...@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
NSControl subclass and accessibility
Hi,
I'm having trouble getting a custom NSControl subclass properly visible with
regards to accessibility.
If I implement my custom control as an NSView subclass and adopt the
NSAccessibilityButton protocol, I can "see" my custom control with
accessibility inspector when I hover above it.
If I take the same class but make it a subclass of NSControl, I'm not able to
"see" my control using accessibility inspector when hovering above it. It is
detecting something because I can see that when I hover in the containing view,
I can see the window ui element, but when I hover above the control itself, I'm
only seeing the "app" element. Also, when I inspect the containing view I can
see my control listed there and I can access it and perform the action.
I feel like I'm missing something obvious. Any ideas?
Here's my code, If I replace NSControl with NSView, it seems to work great.
@interface MyFancyButton : NSControl
@end
@implementation MyFancyButton
- (void)drawRect:(NSRect)dirtyRect ...
- (void)mouseDown:(NSEvent *)event ...
- (void)simulateClick ...
- (nullable NSString *)accessibilityLabel
{
return @"my_label";
}
- (BOOL)accessibilityPerformPress
{
[self simulateClick];
return YES;
}
@end
Thanks in advance,
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/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Programmatically created NSButton is drawn in the wrong position.
setting translatesAutoresizingMaskIntoConstraints to yes makes the situation worse. The buttons are drawn further away than their frames indicate. Eyal > On 15 Dec 2020, at 4:05, Ben Kennedy wrote: > > >> On 14 Dec 2020, at 5:39 pm, Eyal Redler via Cocoa-dev >> wrote: >> >> button = [[NSButton alloc] initWithFrame:NSMakeRect(0, 0, 0, 0)]; >> [button setTranslatesAutoresizingMaskIntoConstraints:NO]; >> [button setBezelStyle:NSRoundedBezelStyle]; >> [button setTitle:buttonTitle]; >> [button sizeToFit]; >> [button setFrameOrigin:NSMakePoint(position, 20)]; > > Since you're positioning the frames manually, you need to set > setTranslatesAutoresizingMaskIntoConstraints = YES instead of NO. > > -ben > ___ 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
Programmatically created NSButton is drawn in the wrong position.
I'm configuring a view with some push buttons and other views programmatically
and the buttons are drawn offset to the right.
For example, the first button should be at 0,20 but it is drawn at 6,20. I
checked that the buttons are not moved, the button frames remain the same, the
buttons are just drawn 6 points to the right.
Here's a screenshot: https://s3.amazonaws.com/mellel.outbox/button_woes.png
Here's the code:
NSView* _view = [_window contentView];
CGFloat position;
position = 0;
for (NSString* buttonTitle in @[@"button one",@"button two",@"button three"])
{
NSButton* button;
button = [[NSButton alloc] initWithFrame:NSMakeRect(0, 0, 0, 0)];
[button setTranslatesAutoresizingMaskIntoConstraints:NO];
[button setBezelStyle:NSRoundedBezelStyle];
[button setTitle:buttonTitle];
[button sizeToFit];
[button setFrameOrigin:NSMakePoint(position, 20)];
[_view addSubview:button];
position += [button frame].size.width + 8;
}
Thanks in advance,
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/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Localization under Catalina
I'm familiar with auto-layout actually with other projects. I thought it was needed for the "new" way of localising because you need to resize captions to fit longer strings (in the case of German for example). I'll definitively look into it. Is there a facility in Xcode to extract the current translated strings from the nib files? Is that handled as part of the automatic conversion? Eyal > On 27 May 2020, at 22:50, Rob Petrovec wrote: > > Auto layout (not auto-resizing) is independent of localization. You don’t > need to switch to auto layout to support Base localization. So you can > convert your nibs over to Base Localization with a couple clicks in Xcode, > and then you just need .strings and .stringdict files in your .lprojs instead > of a TON of duplicate .nibs that constantly need updating. If you make a > change in the base nib all the localizations will pick it up. > > With that said, Auto Layout is leaps & bounds better than the old > autoresizing mask stuff. Make sure you read & understand the auto layout > documentation before starting of course. But once you do convert over you > will wish you had done it earlier. It is SO much better. Plus it > handles positioning views automagically between Left-To-Right localizations > like English and Right-To-Left localizations like Hebrew. > > —Rob > > >> On May 27, 2020, at 1:26 PM, Eyal Redler via Cocoa-dev >> wrote: >> >> AppleGlot used to work fine for me but I agree, I should move to Base.lproj >> etc. But now I need to ship a new version of the app and I can't really >> afford to spend the time converting everything to auto-resizing. >> I foolishly upgraded to Catalina only this week, and this put me in a very >> delicate situation. >> >> Eyal >> >>> On 27 May 2020, at 22:14, Martin Wierschin wrote: >>> >>> I remember AppleGlot. I also remember how terrible it was, at least way >>> back when it was first around. In the intervening years I preferred >>> loc-suite. As Georg said, it's a very good tool. But all that's obsolete >>> now. >>> >>> You ultimately should convert your nibs to Base.lproj. The current Xcode >>> localization process is way better than the bad old days where you had to >>> keep endless translated nibs in sync. The conversion job is a good amount >>> of busy work, and autolayout may give you pain initially, but ultimately >>> using Base.lproj + autolayout + translated .strings files is much cleaner. >>> >>> ~Martin Wierschin >>> Nisus Software / Developer >>> Solana Beach ☀️ California >>> >> >> ___ >> >> 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/petrock%40mac.com >> >> This email sent to petr...@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
Re: Localization under Catalina
AppleGlot used to work fine for me but I agree, I should move to Base.lproj etc. But now I need to ship a new version of the app and I can't really afford to spend the time converting everything to auto-resizing. I foolishly upgraded to Catalina only this week, and this put me in a very delicate situation. Eyal > On 27 May 2020, at 22:14, Martin Wierschin wrote: > > I remember AppleGlot. I also remember how terrible it was, at least way back > when it was first around. In the intervening years I preferred loc-suite. As > Georg said, it's a very good tool. But all that's obsolete now. > > You ultimately should convert your nibs to Base.lproj. The current Xcode > localization process is way better than the bad old days where you had to > keep endless translated nibs in sync. The conversion job is a good amount of > busy work, and autolayout may give you pain initially, but ultimately using > Base.lproj + autolayout + translated .strings files is much cleaner. > > ~Martin Wierschin > Nisus Software / Developer > Solana Beach ☀️ California > ___ 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: Localization under Catalina
I think you're describing a more "modern" setup, my app's localisation is pretty old-school and I have a nib for each localisation (140 nibs in the app x 14 localisations). I was tied back to the old method because I had to support pre 10.7 systems until recently so I couldn't move to auto resizing. Eyal > On 27 May 2020, at 20:30, Rob Petrovec wrote: > > I have never used AppleGlot. However, I’m curious why you don’t set up a > .lproj for each localization you support containing .strings files with your > translated strings inside? > > —Rob > > >> On May 27, 2020, at 10:04 AM, Eyal Redler via Cocoa-dev >> wrote: >> >> Hi, >> >> It looks like Apple has dropped support for AppleGlot under Catalina. The >> latest version (from 2017) will not install on Catalina and links and >> mentions to AppleGlot have been removed from their localisation page >> (https://developer.apple.com/localization/). >> >> It looks like Apple wants us to use Xcode's localisation tools which is OK >> but it doesn't seem to address at all the issue of incremental localization, >> my app is already localized in 14 languages and I just need to add the new >> strings/nibs and update the changed nibs, not create a localisation from >> scratch. >> >> I think that for now I'll switch back to Mojave to build this localisation >> using my workflow with AppleGlot but it would be great if I could run >> AppleGlot on Catalina, was anyone successful in doing that? >> Also, is there some support for incremental localisation using the xcode >> localization tools? Maybe I'm missing something here >> >> Thanks, >> >> >> 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/petrock%40mac.com >> >> This email sent to petr...@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
Localization under Catalina
Hi, It looks like Apple has dropped support for AppleGlot under Catalina. The latest version (from 2017) will not install on Catalina and links and mentions to AppleGlot have been removed from their localisation page (https://developer.apple.com/localization/). It looks like Apple wants us to use Xcode's localisation tools which is OK but it doesn't seem to address at all the issue of incremental localization, my app is already localized in 14 languages and I just need to add the new strings/nibs and update the changed nibs, not create a localisation from scratch. I think that for now I'll switch back to Mojave to build this localisation using my workflow with AppleGlot but it would be great if I could run AppleGlot on Catalina, was anyone successful in doing that? Also, is there some support for incremental localisation using the xcode localization tools? Maybe I'm missing something here Thanks, 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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
