Accessibility Settings

2024-01-10 Thread Tom Doan via Cocoa-dev
I'm trying to figure out how to query the value for the 
Accessibility---Display---Text Size for MacOS (Objective-C). I can't 
for the life of me find any documentation on it, and anything that 
looks even close appears to be for iOS and Swift. Can anyone point 
me in the right direction?

Best regards,

Tom Doan
---
Estima
2717 Harrison St
Evanston, IL 60201
USA


___

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: Intermittent invisible NSWindow

2021-11-18 Thread Tom Doan via Cocoa-dev
Unfortunately, it appears that it's 100% predictable---it fails on a M1 
chipped computer and works on an Intel chipped computer (or an 
M1 running the software through Rosetta).

> I can say it has been true in the past, even if it is no longer the
> case. It is not something I test with each OS release. I certainly can
> move a window almost entirely offscreen-enough to not notice it at
> least. Also, your suggestion that the window may have an invalid size
> could also be the case, additionally revealed by logging the window
> frame. I have seen some auto layout wonkiness that forces  too-small
> frame, though not enough to  make it disappear. 
> 
> Keary Suska
> Esoteritech, Inc.
> "Demystifying technology for your home or business"
> 
> 
> 
> > On Nov 15, 2021, at 7:13 AM, Tom Doan via Cocoa-dev
> >  wrote:
> > 
> > Thanks, but is that true? I've tried forcing the window off screen
> > with setFrame: and it still shows up (generally pinned to the top of
> > the visible frame) even though the [NSWindow frame] returns the
> > "off-screen" location that I programmed in. The only way I have
> > found to make the window "invisible" is to give it a non-positive
> > size, and then pulling it off the window menu still won't show it.
> > 
> >> Have you logged the window coordinates? It might be placed fully
> >> offscreen, and that would produce the behavior you are seeing.
> >> 
> >> Keary Suska
> >> Esoteritech, Inc.
> >> "Demystifying technology for your home or business"
> >> 
> >> 
> >> 
> >>> On Nov 13, 2021, at 9:52 AM, Tom Doan via Cocoa-dev
> >>>  wrote:
> >>> 
> >>> I'm having a problem with an application where a small percentage
> >>> of users have one particular NSWindow type which doesn't show even
> >>> though it goes through a makeKeyAndOrderFront. It's on the window
> >>> list and will open if they do a tile, cascade or window switch
> >>> operation, but doesn't come up initially. I can't reproduce this
> >>> on any of my computers running three different flavors of MacOS
> >>> (including Big Sur and Monterey). What should I be looking for
> >>> that might cause this behavior.
> >>> 
> >>> Best regards,
> >>> 
> >>> Tom Doan
> >>> ---
> >>> 2717 Harrison St
> >>> Evanston, IL 60201
> >>> USA
> >>> 
> >>> 
> >>> ___
> >>> 
> >>> 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/cocoa-dev%40esot
> >>> er itech.com
> >>> 
> >>> This email sent to cocoa-...@esoteritech.com
> >> 
> > 
> > 
> > ---
> > 2717 Harrison St
> > Evanston, IL 60201
> > USA
> > 
> > 
> > ___
> > 
> > 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/cocoa-dev%40esoter
> > itech.com
> > 
> > This email sent to cocoa-...@esoteritech.com
> 


---
2717 Harrison St
Evanston, IL 60201
USA


___

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: Intermittent invisible NSWindow

2021-11-15 Thread Tom Doan via Cocoa-dev
Thanks, but is that true? I've tried forcing the window off screen with 
setFrame: and it still shows up (generally pinned to the top of the 
visible frame) even though the [NSWindow frame] returns the 
"off-screen" location that I programmed in. The only way I have 
found to make the window "invisible" is to give it a non-positive size, 
and then pulling it off the window menu still won't show it.

> Have you logged the window coordinates? It might be placed fully
> offscreen, and that would produce the behavior you are seeing.
> 
> Keary Suska
> Esoteritech, Inc.
> "Demystifying technology for your home or business"
> 
> 
> 
> > On Nov 13, 2021, at 9:52 AM, Tom Doan via Cocoa-dev
> >  wrote:
> > 
> > I'm having a problem with an application where a small percentage of
> > users have one particular NSWindow type which doesn't show even
> > though it goes through a makeKeyAndOrderFront. It's on the window
> > list and will open if they do a tile, cascade or window switch
> > operation, but doesn't come up initially. I can't reproduce this on
> > any of my computers running three different flavors of MacOS
> > (including Big Sur and Monterey). What should I be looking for that
> > might cause this behavior.
> > 
> > Best regards,
> > 
> > Tom Doan
> > ---
> > 2717 Harrison St
> > Evanston, IL 60201
> > USA
> > 
> > 
> > ___
> > 
> > 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/cocoa-dev%40esoter
> > itech.com
> > 
> > This email sent to cocoa-...@esoteritech.com
> 


---
2717 Harrison St
Evanston, IL 60201
USA


___

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


Intermittent invisible NSWindow

2021-11-13 Thread Tom Doan via Cocoa-dev
I'm having a problem with an application where a small percentage 
of users have one particular NSWindow type which doesn't show 
even though it goes through a makeKeyAndOrderFront. It's on the 
window list and will open if they do a tile, cascade or window switch 
operation, but doesn't come up initially. I can't reproduce this on any 
of my computers running three different flavors of MacOS (including 
Big Sur and Monterey). What should I be looking for that might 
cause this behavior.

Best regards,

Tom Doan
---
2717 Harrison St
Evanston, IL 60201
USA


___

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: ARC and C++ structures

2021-09-15 Thread Tom Doan via Cocoa-dev
Thanks. That did it. Interestingly, not only did the Applie Migration 
tool not flag a potential problem, but the docs on NSWindow and 
releaseWhenClosed don't even hint of it.


> Hi Tom,
> 
> > On Sep 14, 2021, at 9:53 AM, Tom Doan via Cocoa-dev
> >  wrote:
> > 
> > I have a multiple platform application (Windows, Mac, GTK) that is
> > primarily organized using C++ with Objective-C used for the
> > Mac-specific interface. I recently switched to use ARC (as we are
> > using Scintilla which recently switched to ARC). However, I am
> > getting a zombied release of an NSWindow instance. So far as I can
> > tell, the memory handling of this seemed to be fine pre-ARC.
> > Unfortunately, because it's an NSWindow, the Instruments output for
> > it has 100's of toolbox calls, so it's very hard to tell where the
> > extra release is. What should I be looking for? 
> > 
> > Just to describe this, there's an EWindow C++ structure which has
> > the NSWindow * as a member (under Mac OS; it's an HWND under Windows
> > and Widget under GTK). It's after the delete of the EWindow that
> > things go south. I'm assuming that ARC is putting in a release, but
> > I haven't really seen any good description of how ARC interacts with
> > C++. A release there seems fine---the question is where is the
> > earlier (apparently erroneous) release.
> 
> ARC will insert code at the end of your C++ destructor to release any
> strong id members.
> 
> One possible wrinkle is the default release-when-close behavior of
> NSWindow.  By default, when an NSWindow is `-close`d (which can only
> happen once in its lifetime), AppKit sends it a `-release`.  The idea
> is that this release balances the initial `+alloc`.
> 
> However, this is somewhat incompatible with ARC, which doesn´t know
> about this special behavior and will attempt to insert its own release
> to balance the alloc.
> 
> Here is an example of a program that works perfectly fine under MRR
> but crashes under ARC:
> 
> #import 
> 
> NSWindow *window;
> 
> int main(void) {
> @autoreleasepool {
> window = [[NSWindow alloc]
> initWithContentRect:NSMakeRect(0., 0., 100.,
> 100.) styleMask:NSWindowStyleMaskTitled
> backing:NSBackingStoreBuffered defer:NO];
> [window makeKeyAndOrderFront:nil]; [window
> close]; window = nil;
> }
> }
> 
> You can disable this behavior by changing the `releasedWhenClosed`
> property of the window to `NO`:
> 
> [window setReleasedWhenClosed:NO];
> 
> Matt
> 


---
2717 Harrison St
Evanston, IL 60201
USA


___

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


ARC and C++ structures

2021-09-14 Thread Tom Doan via Cocoa-dev
I have a multiple platform application (Windows, Mac, GTK) that is 
primarily organized using C++ with Objective-C used for the 
Mac-specific interface. I recently switched to use ARC (as we are 
using Scintilla which recently switched to ARC). However, I am 
getting a zombied release of an NSWindow instance. So far as I 
can tell, the memory handling of this seemed to be fine pre-ARC. 
Unfortunately, because it's an NSWindow, the Instruments output 
for it has 100's of toolbox calls, so it's very hard to tell where the 
extra release is. What should I be looking for? 

Just to describe this, there's an EWindow C++ structure which has 
the NSWindow * as a member (under Mac OS; it's an HWND under 
Windows and Widget under GTK). It's after the delete of the 
EWindow that things go south. I'm assuming that ARC is putting in a 
release, but I haven't really seen any good description of how ARC 
interacts with C++. A release there seems fine---the question is 
where is the earlier (apparently erroneous) release.

Tom Doan
Estima
---
2717 Harrison St
Evanston, IL 60201
USA

___

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: NSToolbar in Catalina

2020-03-23 Thread Tom Doan via Cocoa-dev
On looking at the particulars of the icons that are working and those 
that are not, it looks like anything that has a high resolution (128 x 
128) is displaying wrong, while the ones that I never updated from 
48 x 48 work correctly.

> I had a similar problem with .icns files showing weird graphics but on
> Mojave and earlier they were fine.  I resolved the issue by using Icon
> Composer (on macOS 10.10) to extract the '.icns' file(s) to iconsets
> and then importing them into an Asset Library.
> 
> The NSImage creation changed to use imageForResource
> 
> image = [NSBundle imageForResource:imgName];
> 
> -Dave
> 
> On 3/23/20, 1:10 PM, "Cocoa-dev on behalf of Tom Doan via
> Cocoa-dev"  on behalf of Cocoa-dev@lists.apple.com> wrote:
> 
> To provide a bit of additional information, the toolbar icons are
> fetched with
> 
> image  = [[NSImage alloc] 
> initByReferencingFile:[mainBundle 
> pathForResource:identifier ofType:@"icns"]];
> 
> 
> > I'm having a very odd problem. I use NSToolbar/NSToolbarItem to
> > manage toolbars in my application. Under Catalina (and
> apparently only > under Catalina), some of our users (only a few,
> and not me on my > development machines) end up with toolbar items
> that have a very odd > appearance---some are fine, some are
> completely whited out, some are > almost completely whited out
> with some odd colors added, usually pale > pink in an area which
> has nothing to do with the original icon > appearance. The washed
> out icons have nothing to do with them being > tagged
> inactive---on my machine, inactive icons look correctly dimmed >
> and the washed out ones are supposed to be active anyway. Does
> anyone > have an idea what the problem might be? > > Best regards,
> > > Tom Doan > Estima > --- > 2717 Harrison St > Evanston, IL
> 60201 > USA > > > ___
> > > 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/tomd%40estima.co
> m > > This email sent to t...@estima.com
> 
> 
> ---
> 2717 Harrison St
> Evanston, IL 60201
> USA
> 
> 
> ___
> 
> 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/david.stjohn%40x
> erox.com
> 
> This email sent to david.stj...@xerox.com
> 
> 


---
2717 Harrison St
Evanston, IL 60201
USA


___

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: NSToolbar in Catalina

2020-03-23 Thread Tom Doan via Cocoa-dev
To provide a bit of additional information, the toolbar icons are 
fetched with

image  = [[NSImage alloc] 
initByReferencingFile:[mainBundle 
pathForResource:identifier ofType:@"icns"]];


> I'm having a very odd problem. I use NSToolbar/NSToolbarItem to 
> manage toolbars in my application. Under Catalina (and apparently only
> under Catalina), some of our users (only a few, and not me on my
> development machines) end up with toolbar items that have a very odd
> appearance---some are fine, some are completely whited out, some are
> almost completely whited out with some odd colors added, usually pale
> pink in an area which has nothing to do with the original icon
> appearance. The washed out icons have nothing to do with them being
> tagged inactive---on my machine, inactive icons look correctly dimmed
> and the washed out ones are supposed to be active anyway. Does anyone
> have an idea what the problem might be?
> 
> Best regards,
> 
> Tom Doan
> Estima
> ---
> 2717 Harrison St
> Evanston, IL 60201
> USA
> 
> 
> ___
> 
> 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/tomd%40estima.com
> 
> This email sent to t...@estima.com


---
2717 Harrison St
Evanston, IL 60201
USA


___

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


NSToolbar in Catalina

2020-03-23 Thread Tom Doan via Cocoa-dev
I'm having a very odd problem. I use NSToolbar/NSToolbarItem to 
manage toolbars in my application. Under Catalina (and apparently 
only under Catalina), some of our users (only a few, and not me on 
my development machines) end up with toolbar items that have a 
very odd appearance---some are fine, some are completely whited 
out, some are almost completely whited out with some odd colors 
added, usually pale pink in an area which has nothing to do with the 
original icon appearance. The washed out icons have nothing to do 
with them being tagged inactive---on my machine, inactive icons 
look correctly dimmed and the washed out ones are supposed to be 
active anyway. Does anyone have an idea what the problem might 
be?

Best regards,

Tom Doan
Estima
---
2717 Harrison St
Evanston, IL 60201
USA


___

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