Re: How to reposition subviews without Auto Layout

[じょいすじょん via Cocoa-dev]

> On Oct 17, 2020, at 9:57 PM, Andreas Falkenhahn via Cocoa-dev 
>  wrote:
> 
> Hi,
> 
> I have an NSView that I set as the content view of my NSWindow. The NSView 
> has three subviews. Where should I reposition and resize those three subviews 
> when the NSWindow size changes? 
> 
> I see that NSView has a "layout" method that can be overridden but AFAIU this 
> is only to be used for Auto Layout. I don't want to use Auto Layout because 
> my whole layout is very simplistic and just involves those three subviews 
> which I can easily position and size manually. I just need to know where to 
> put the code that sets their new position and size... anyone?
> 
> -- 
> Best regards,
> Andreas Falkenhahn  mailto:andr...@falkenhahn.com 
> 

I'm not sure why you would avoid Auto Layout at this point. It's generally 
easier than the alternative.
Either way, Auto Layout is really the default these days and things more or 
less get to live in and Auto Layout world.

That said, what have you tried?
This method might do the trick, but there might be more involved than you 
expect.
You might want to look at the methods in NSWindowDelegate as well as the 
NSNotificationNames of NSNotifications you can register for in NSWindow.h
There are a variety of ones regarding resize and zoom.
You might also want to consider ones that involve the view being occluded or 
moving to a display with a different resolution, as well as different 
accessibility and appearance changes.
Then you have internationalization.
One of the big benefits of Auto Layout is getting fairly free support for 
left-to-right and right-to-left language layouts, and another is views that can 
automatically (mostly) expand and contract to support variations in string 
lengths by localization.
Please consider all of these points and how they might affect your layouts.
The rabbit hole is deep sometimes.
___

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

[じょいすじょん via Cocoa-dev]

> On Jun 29, 2020, at 15:24, Sandor Szatmari  
> wrote:
> 
> 
> 
>> On Jun 28, 2020, at 22:29, じょいすじょん via Cocoa-dev  
>> wrote:
>> 
>> One way to do this is with the command line tool:
>> caffeinate
>> 
>> You could run a background task that starts it with something like 
>> caffeinate -dimsu
>> 
>> You can probably also find its source code on opensource.apple.com to 
>> understand what it does and how.
>> 
>> Like here is a version:
>> 
>> https://opensource.apple.com/source/PowerManagement/PowerManagement-637.20.2/caffeinate/caffeinate.c.auto.html
>> 
>> You certainly still want a user to approve things.
> 
> I would say that if the user has the checkbox selected in system preferences 
> that ties sleep/screensaver to security (prompt for password on 
> sleep/screensaver activation) they have already answered this question.  In 
> this situation any app that calls caffeinate in the background (or uses an 
> API) to circumvent this security settings without informing the user should 
> be considered dubious at best and perhaps even malware.  In effect this is 
> disabling that security choice.  If the user has not selected this setting in 
> system prefs then there is no issue preventing screensaver from activating.  
> I’d recommend this criteria for the basis of whether to interfere with normal 
> system operations.
> 
> Sandor

Nobody said circumvent anything.
I believe a user would have to authorize an NSTask or similar usage anyway, 
unless they have disabled SIP.
I just provided reference to a tool that is already built and bundled that does 
this (less code) and the source to that tool (inspiration for other code).
I will not make any claims as to how that works with sandboxing. I 
whole-heartedly expect and want any such functionality to be made clear to 
users.
That said, it is easy to understand loads of legitimate use-cases for this.

___

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

[じょいすじょん via Cocoa-dev]

One way to do this is with the command line tool:
caffeinate

You could run a background task that starts it with something like 
caffeinate -dimsu

You can probably also find its source code on opensource.apple.com to 
understand what it does and how.

Like here is a version:

https://opensource.apple.com/source/PowerManagement/PowerManagement-637.20.2/caffeinate/caffeinate.c.auto.html

You certainly still want a user to approve things.


___

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: NSDatePicker display format

[じょいすじょん via Cocoa-dev]

Have you tried any of the properties like calendar (NSCalendar), locale 
(NSLocale) and timeZone (NSTimeZone) ?
Those are what drive much of NSDateFormatter…
By default they probably inherit from the current system settings or whatever 
the app inherits at launch.
Date, time and number formats are generally provided defaults as part of locale 
and calendar in Cocoa and largely via the underlying Unicode CLDR and ICU 
standard open source libraries.
But when you need to provide something that differs from the current user's 
system preferences settings, you can do so.
Example, a locale based on en-US would likely have the Month Day Year 
convention so common in everyday life in the USA.
However, some contexts in the USA use other formats, in such cases, your app 
might want to provide that.

> On Jan 22, 2020, at 11:22, Marco S Hyman via Cocoa-dev 
>  wrote:
> 
> On Jan 21, 2020, at 3:04 PM, robmar...@frontiernet.net wrote:
>> 
>> Have you tried adding a NSDateFormatter to the DatePickerCell (in code or in 
>> the xib) and setting its format string to what you want?
> 
> There doesn’t seem to be any way to get the DatePickerCell to use the 
> formatter.  At least not one that I’ve yet to find.  Bummer.
> 
> Marc
> ___
> 
> 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/dangerwillrobinsondanger%40gmail.com
> 
> This email sent to dangerwillrobinsondan...@gmail.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: Hide badge of NSDraggingSession

[じょいすじょん via Cocoa-dev]

> On Jul 26, 2019, at 10:50, Dragan Milić via Cocoa-dev 
>  wrote:
> 
>> pet 26.07.2019., at 03.08, Rob Petrovec wrote:
>> 
>> I would not recommend using those deprecated API.  They are not long for 
>> this world.  With that said, I don’t have a better solution.
> 
> Yeah, I’d like ti avoid using that too.
> 
> 
>> pet 26.07.2019., at 03.30, Steve Mills via Cocoa-dev wrote:
>> 
>> Yeah, hard to say how much longer they'll be available. You could always add 
>> a single item using a custom NSPasteboardWriting class and supply your own 
>> image. It would hold the multiple items and write them.
> 
> The thing is, in that dragging session I have to supply a list of URLs, so 
> that other applications expecting URLs (like Finder, for example) would 
> accept them. As a matter of fact, speaking about specifics, what I really 
> want is to do is drag a couple of URLs into System Preferences’ “Full Disk 
> Access” list, and that one accepts only lists of URLs, as far as I know.
> 
> Now, I want it to look like a user is only dragging an icon of my application 
> (which he/she really does), but application’s privileged helper needs to be 
> added into “Full Disk Access” too. I don’t want user to see that (and 
> potentially get confused), so my intention is to show just application’s icon 
> during the drag. That works okay (the second dragging items has no content), 
> but since I actually have two dragging items, the count badge appears, and 
> that doesn’t look very nice.
> 
> Speaking of above mentioned deprecated method, I tried to use it and write 
> URLs to the dragging pasteboard using -[NSPasteboard writeObjects:]. That 
> worked well and looked exactly as I wanted on Mojave, but on Catalina it 
> throws exception for “there are two dragging items but only one dragging 
> image, there should be one image per item”.
> 
> Finally, I know of application which does exactly the same as I described and 
> want. The session contained three dragging items, but the badge was hidden. 
> So I thought there could be something obvious I may be missing. Now it seems 
> to me that only can be done through private API calls and/ore other hackery.
> 
> Cheers,
> -- Dragan
You want to look at the hairy block property of NSDraggingItem.h

@property (nullable, copy) NSArray * __nonnull 
(^imageComponentsProvider)(void);

It's been years ago now, but Raleigh Ledet did a WWDC presentation on Drag 
Flocking.
See
https://developer.apple.com/videos/play/wwdc2011/115/

It's one of the most intensely valuable videos for understanding scrolling, 
swiping and dragging in macOS. Still very very very valuable video.
It's a dense presentation, but if you *can* do this, this is where you will 
find out how.


___

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: Hide badge of NSDraggingSession

[じょいすじょん via Cocoa-dev]

> On Jul 26, 2019, at 12:19, Steve Mills via Cocoa-dev 
>  wrote:
> 
> On Jul 25, 2019, at 20:50:18, Dragan Milić via Cocoa-dev 
>  wrote:
>> 
>> The thing is, in that dragging session I have to supply a list of URLs, so 
>> that other applications expecting URLs (like Finder, for example) would 
>> accept them. As a matter of fact, speaking about specifics, what I really 
>> want is to do is drag a couple of URLs into System Preferences’ “Full Disk 
>> Access” list, and that one accepts only lists of URLs, as far as I know.
>> 
>> Now, I want it to look like a user is only dragging an icon of my 
>> application (which he/she really does), but application’s privileged helper 
>> needs to be added into “Full Disk Access” too. I don’t want user to see that 
>> (and potentially get confused), so my intention is to show just 
>> application’s icon during the drag. That works okay (the second dragging 
>> items has no content), but since I actually have two dragging items, the 
>> count badge appears, and that doesn’t look very nice.
> 
> According to documentation, it's up to the drop location to decide how many 
> items it will accept and change the numberOfValidItemsForDrop property on the 
> NSDraggingInfo, like if one item is a jpg file and the other is a text file, 
> but it only wants images, so it sets it to 1, but then if the mouse moves 
> over some other app or destination that wants all files, it would change back 
> to 2.
> 
> --
> Steve Mills
> Drummer, Mac geek

I wonder if it could work if the content types are carefully crafted to be all 
one kind.
___

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: Is "-init" really needed?

[じょいすじょん]

> On Aug 8, 2017, at 9:09, Jens Alfke  wrote:
> 
> 
>> On Aug 7, 2017, at 5:02 PM, David Hoerl  wrote:
>> 
>> But then I though - heck, if Foo has NSObject as its super class, gee, maybe 
>> -init isn't really need. I mean, if all of Foo's ivars and properties are 
>> initialized, its a shortcut, right.
> 
> -[NSObject init] happens to be a no-op empty method. So if a direct subclass 
> of NSObject has no -init method of its own, you could get by with just 
> calling +alloc. However, I think this would be a really bad idea. If at some 
> point you needed to add an -init method to class Foo, like to initialize an 
> ivar, you’d have to go and fix all this code that wasn’t calling -init, or 
> else you’d suddenly have a number of bugs in your code. Even worse, if 
> someone else added the -init method and didn’t know about this quirk of how 
> callers initialized Foo, they might have  no idea why their method didn’t get 
> called. Yuck.
> 
> —Jens
> ___
> 
It definitely should never pass in a code review for exactly these reasons and 
should be fixed by either adding the init call or changing the alloc call to a 
new call (since new is a synonym for alloc init).
If you saw it pre-existing in code that was being checked in, require it to be 
fixed. Refusal to type a few characters is absolutely a shortcut to trouble 
later (Y2K).
___

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: [webkit-dev] How to display new MIME types?

[じょいすじょん]

> On Jul 27, 2017, at 10:13, Conrad Shultz  wrote:
> 
> 
> 
>> On Jul 22, 2017, at 7:32 PM, Jens Alfke  wrote:
>> 
>> 
>>> On Jul 21, 2017, at 7:19 PM, Conrad Shultz  wrote:
>>> 
>>> You can build a Safari extension as an app extension bundled with an app, 
>>> meaning you can write your extension in Swift or Objective-C (and 
>>> JavaScript).
>> 
>> It doesn’t look like these can do what the OP wants to do — display a 
>> specific MIME type in Safari. Safari Extensions are triggered by web pages 
>> loading, and can inject JS or CSS, which implies that the page is already 
>> HTML-based. If Safari encounters a page whose MIME type is 
>> “application/foobar”, it’s not going to display any HTML, it’s going to 
>> download it as a file and the extension never gets to run.
>> 
>> —Jens
>> 
> 
> Yes, you will not able to directly display a new MIME type in Safari using 
> the existing extensions API. I encourage filing a bug at 
> https://bugreport.apple.com  requesting new 
> functionality.
> 
> However, you might be able to emulate a similar behavior. For example, your 
> extension could add script that detects a link (or other reference) in HTML 
> to the content of interest, then routes it (either as downloaded data or the 
> resource URL) to your native code, which could then render it either in your 
> associated app or in a popover in Safari.
With emulation of the link sniffing, 
would Web Assembly make it doable potentially?
That's a big black box still to me...
> 
> -Conrad
> ___
> 
> 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/dangerwillrobinsondanger%40gmail.com
> 
> This email sent to dangerwillrobinsondan...@gmail.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: Sometimes all my menus are disabled

[じょいすじょん]

> On Feb 14, 2017, at 1:58, Andreas Falkenhahn  wrote:
> 
> On 13.02.2017 at 17:33 じょいすじょん wrote:
> 
>> Yeah, my first suggestion didn't work, but points out the problem overall in 
>> you nib.
>> Looks like somebody did try to edit the xml before and munged it.
> 
> I certainly did not mess with the XML! Xcode must have messed this up when 
> converting
> the nib file from the old Xcode PowerPC project format to the new one. 
> 
>> You also have nested menu duplicates inside your menus in the nib file 
>> itself!
> 
>> MainMenu
>>Hollywood
>>Menu
>>About Hollywood
>>Separator
>>MainMenu (duplicated here as sub menu...)
>>Preferences
>>... (and on)
> 
> 
>> Delete that other MainMenu inside and it seems to work thus far.
> 
> I've removed the complete duplicate MainMenu tree (the one after the separator
> item, see above) from designable.nib using a text editor. However, it still
> doesn't work. Same behaviour as before. 
Strange, because after the changes I've suggested I am no longer able to get 
any issues.
You really do just need to fix your nib. It's not that hard. If you're having 
trouble with modern Xcode, well, you have to pick it up.
IB has been pretty self similar for many years now.
Just spend the time doing fixing it.
It's not unreasonable to expect some project gets a little borked transitioning 
it from a 10 year old version of Xcode to a modern one. A LOT has changed since 
then.
 

> 
> 
> 
> This annoying issue is just another reason why I prefer doing things in code.
> This has already cost me hours over hours and it's still not solved. Even
> worse, there's a profound feeling of helplessness in the air. And re-creating
> everything from scratch is not an option! I certainly did not mess with the
> XML. Xcode must have messed this up when converting the project from the
> old format to the new one. All such things wouldn't be possible with code.
> Code could be cleanly adapted to new designs while nobody can tell what black
> magic is going on inside those arcane nib files. It's quite depressing. $0.02
> 
> 
> 
> -- 
> Best regards,
> Andreas Falkenhahnmailto:andr...@falkenhahn.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: Sometimes all my menus are disabled

[じょいすじょん]

Yeah, my first suggestion didn't work, but points out the problem overall in 
you nib.
Looks like somebody did try to edit the xml before and munged it.

You also have nested menu duplicates inside your menus in the nib file itself!

MainMenu
Hollywood
Menu
About Hollywood
Separator
MainMenu (duplicated here as sub menu...)
Preferences
... (and on)


Delete that other MainMenu inside and it seems to work thus far.


> On Feb 14, 2017, at 0:56, Andreas Falkenhahn  wrote:
> 
> On 13.02.2017 at 16:40 じょいすじょん wrote:
> 
>> You have a lot of dupes in your nib file connections.
> 
>> For example, select the AppDelegate in the nib in IB, and look at the 
>> Connections Inspector.
>> You'll see it has 2 Main Menu referencing outlets.
>> So it's hitting a random one of the two.
>> You have this kind of duplication in lots of places in your nib.
>> Rewire your nib.
> 
> True, I can see that. But how do I rewire my nib? I don't remember anything
> about Interface Builder. As I said, I last worked on this project about 10
> years ago on a PowerPC Mac.
> 
> So what exactly do I have to do? I've tried deleting the duplicate "mainMenu"
> entry in "Referencing Outlets" but this didn't change anything...
> 
> -- 
> Best regards,
> Andreas Falkenhahnmailto:andr...@falkenhahn.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: Sometimes all my menus are disabled

[じょいすじょん]

You have a lot of dupes in your nib file connections.

For example, select the AppDelegate in the nib in IB, and look at the 
Connections Inspector.
You'll see it has 2 Main Menu referencing outlets.
So it's hitting a random one of the two.
You have this kind of duplication in lots of places in your nib.
Rewire your nib.

> On Feb 13, 2017, at 23:12, Andreas Falkenhahn  wrote:
> 
> On 12.02.2017 at 21:49 Kyle Sluder wrote:
> 
>> There are plenty of ways to write refcounting bugs. But the
>> refcounting bug is just a theory. All we know for sure is that
>> something is disabling the menu items. I assume you have not turned
>> off the default autoenablesItems property on the menu, so that leaves a few 
>> possibilities:
> 
>> 1. The target of your menu items is being replaced with an object
>> that does not respond to -menuClick:.
>> 2. The target of your menu items is being deallocated, and a new
>> object is being allocated in its place that does not respond to -menuClick:.
>> 3. The target of your menu items is being deallocated, and
>> NSMenuItem’s weak target pointer is being nilled out (special case of #1).
>> 4. The menu has a delegate, and it implements of one of the menu
>> update callbacks to disable the menu items.
>> 5. Some arbitrary object in your app is grabbing a reference to the menu 
>> items and disabling them.
> 
> Thanks for the feedback. Unfortunately, I'm pretty much out of ideas now.
> 
> I started cutting down my program to the absolute minimum to see if the
> error would go away. Well, it didn't. This is the code that's left of my
> program now:
> 
>   #import "AppDelegate.h"
> 
>   @implementation AppDelegate
>   - (void) clickButton:(id)sender {}
>   - (void) menuClick:(id)sender {}
>   - (void) applicationDidFinishLaunching:(NSNotification *) aNotification
>   {
>   [mainWindow makeKeyAndOrderFront:nil];
>   }
>   @end 
> 
>   
> 
>   #import 
> 
>   int main(int argc, char *argv[])
>   {
>   return NSApplicationMain(argc, argv);
>   }
> 
> And the error is still there. Bottom line: The error must be in the
> MainMenu.nib or in the Xcode project. Maybe Xcode has messed up one of
> the files when migrating it from the old Xcode on PowerPC to Xcode 8.
> 
> Unfortunately, I don't know where to look because I remember nothing about
> Interface Builder. That's why I have uploaded a VERY SMALL test project
> here: http://www.falkenhahn.com/tmp/guitest.tar.gz
> 
> It really only contains the code quoted above, a single window with a
> single button and the original menu bar that is behaving erratically. 
> 
> As I said in my first mail, the really confusing fact is that it usually
> works just fine. But in every 3rd attempt or so suddenly all menus are
> disabled and I have no idea what's going on! It is really weird but it
> is clearly reproducible. I know I said before that it fails in 1 out of 10
> attempts but it's more like 1 in 3 attempts. It's really clearly reproducible.
> It happens all the time though not always.
> 
> As I'm really out of ideas now I'd be extremely glad if somebody with
> IB experience could just take a quick look at this project and maybe come up
> with an explanation. As I said, it's an absolutely minimal project.
> It should be really straightforward to analyze for people who are experienced
> with IB.
> 
> Thanks a lot for any help!
> 
> -- 
> Best regards,
> Andreas Falkenhahnmailto:andr...@falkenhahn.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/dangerwillrobinsondanger%40gmail.com
> 
> This email sent to dangerwillrobinsondan...@gmail.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: PDF to Word ( docx) Conversion

[じょいすじょん]

You might take a look back at the TextEdit source.
It should be pretty straight forward to save as .rtf or .rtfd, if by table you 
mean you have a rich text table.


> On Jan 25, 2017, at 6:35, Peter Hudson  wrote:
> 
> I was trying to avoid having to go to Direct RTF markup. But as you say, it 
> may be the answer. 
> 
> Peter
> 
>> On 24 Jan 2017, at 21:13, Jens Alfke  wrote:
>> 
>> 
>>> On Jan 24, 2017, at 12:58 PM, Peter Hudson  wrote:
>>> 
>>> I wondered about RTF - but I've built everything into a view and I can't 
>>> see a method on NSView to produce rtf. 
>>> I've done it previously with, I think, an NSText. 
>> 
>> I meant producing it programmatically. It’s a markup language, around the 
>> same order of complexity as HTML (although it looks more like TeX.)
>> 
>> [Fun fact: My first paying job after college, in 1987, was to write a 
>> translator program that parsed a weird old phototypesetter markup language 
>> and generated RTF that could be imported into PageMaker.]
>> 
>> —Jens
> ___
> 
> 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/dangerwillrobinsondanger%40gmail.com
> 
> This email sent to dangerwillrobinsondan...@gmail.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: Control default color inconsistencies

[じょいすじょん]

> On 2016 Dec 15, at 0:47, Andreas Falkenhahn  wrote:
> 
> I'm creating my GUI programmatically. It simply consists of a UILabel,
> a UITableView and two UIButtons.
> 
> When creating those three controls I've noticed that they all seem to
> use different color schemes by default which makes the GUI look rather
> silly.
> 
> Here are my observations:
> 
> 1) By default, UILabel seems to set both background and text color to
> black, i.e. nothing is readable before you change the colors to some
> more meaningful values.
> 
> 2) By default, UITableView appears with a gray background and black
> text on top.
> 
> 3) By default, UIButton appears with a black background and blue (!)
> text on top.
> 
> Is there any rationale why all three controls seem to use entirely
> different color schemes by default here? 
> 
> When writing desktop GUIs it's bad practice to use custom color schemes
> because they might clash with the user's theme settings. Doesn't such
> a paradigm apply to iOS as well? Or am I really forced to explicitly
> set foreground and background colors for each UI control? I'd really
> prefer to use the default iOS look instead. On Android I don't have to
> set background and foreground colors either, the OS will automatically
> use some meaningful and consistent (!) default colors.
> 
> This makes me wonder if there is a default iOS color scheme for apps
> at all? Or are all apps supposed to define their own color scheme?
> If there is a default iOS color scheme, why don't the controls use
> it then when not specifying any colors?
> 
> It's all quite confusing... I hope somebody can shed some more light
> onto this. But please no lectures on that I should use Interface Builder,
> Storyboard, or whatever it is called now instead, I really like to do
> things manually - always have, always will ;)
> 
> -- 
> Best regards,
> Andreas Falkenhahn  mailto:andr...@falkenhahn.com

Nobody can guess what you are actually doing.
Please share some code so people can help you.

___

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: NSOpenPanel stopped working in some apps on Sierra

[じょいすじょん]

> On 2016 Dec 8, at 9:22, Jens Alfke  wrote:
> 
> 
>> On Dec 7, 2016, at 3:16 PM, Leo  wrote:
>> 
>> Any attempt to call it with runModal results with the following errors:
>> 
>>   [General] *** -[__NSArrayM objectAtIndex:]: index 0 beyond bounds for 
>> empty array
>>   [General] (null)
> 
> What’s the backtrace?
> 
> Chances are there’s something messed up in the defaults the open-panel 
> stores. If you look at the apps’ defaults and delete any that have 
> “OpenPanel” in the name, that might fix things. (But it’d be a good idea to 
> capture a dump of the defaults first, and put that in a bug report to Apple.)
> 
> —Jens
> ___
I would add that without the stacktrace and without showing code, it's pretty 
hard to do anything for you beyond guessing.
___

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: iOS 9: Adding CALayer to self.view.layer causes EXC_BAD_ACCESS

[じょいすじょん]

> On 2016 Dec 7, at 6:27, Carl Hoefs  wrote:
> 
>> 
>> On Dec 6, 2016, at 1:33 PM, Carl Hoefs  
>> wrote:
>> 
>>> On Dec 6, 2016, at 1:24 PM, David Duncan  wrote:
>>> 
>>> Your safest bets are to either clear the delegate of the layer at an 
>>> appropriate time (possibly in your view controller’s dealloc is all that is 
>>> necessary), or to use a UIView instead of a raw CALayer in this case. 
>>> Removing the layer would also suffice, as that would prevent UIKit from 
>>> seeing it at the time in question. Making the layer weak is probably 
>>> causing your reference to deallocate before it can be added to the layer 
>>> tree, which is why it doesn’t display in that case.
>> 
>> Thanks for this explanation, David! 
>> 
>> I've verified that using either of:
>>   [self.layer setDelegate:nil];
>> or
>>   [self.layer removeFromSuperlayer];
>> will prevent the crash. 
> 
> Followup: It turns out that the 'offending' line of code is:
> 
>  [self.layer setDelegate:self];
> 
> If I don't set this, everything still works correctly, and there's no crash 
> at dealloc time.
> 
> -Carl
> 
That sure looks like a circle until you remove something :)
___

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: Is NSCollectionView size not controllable in 10.10?

[じょいすじょん]

If this is on 10.10 as was noted earlier, NSCollectionViewFlowLayout is not 
available is it?


> On 2016 Nov 7, at 11:34, Rob Petrovec  wrote:
> 
> I haven’t seen Jean-Daniel’s reply (he likely replied directly to you), but I 
> think he is correct.  Your best bet is to subclass NSCollectionViewFlowLayout 
> and override -collectionViewContentSize: to specify what width you want the 
> collection view to be and let NSCollectionViewFlowLayout figure out where the 
> items go within that width or do your own layout by overriding 
> -layoutAttributesForElementsInRect: & -layoutAttributesForItemAtIndexPath:  
> Good luck...
> 
> —Rob
> 
> 
>> On Nov 4, 2016, at 10:01 PM, Steve Mills > > wrote:
>> 
>> On Nov 4, 2016, at 02:56:27, Jean-Daniel  wrote:
>>> 
>>> I don’t get it. NSCollectionView is a very flexible class. If you are not 
>>> happy with the default flow layout, just write your own.
>>> 
>>> From the reference: 
>>> "   • The layout object specifies the position and appearance of items 
>>> onscreen. AppKit defines layout objects that you can use as-is, but you can 
>>> also define custom layouts by subclassing NSCollectionViewLayout. »
>> 
>> Write my own? It might come to that, but it won't help NSCollectionView's 
>> laughable implementation of shift-arrowKey and shift-click selection. And I 
>> shouldn't have to, really, since NSCollectionView is supposed to be The Way 
>> To Do Stuff.
>> 
>> But that doesn't help with my question. It clearly knows how to activate the 
>> horizontal scrollbar when you resize the window. It activates for a bit 
>> before it reshuffles things around to fit the new size, then deactivates it 
>> again. There's no way to make it just stay that width?
>> 
>> --
>> Steve Mills
>> Drummer, Mac geek
>> 
>> 
>> ___
>> 
>> 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/dangerwillrobinsondanger%40gmail.com
>  
> 
> 
> This email sent to dangerwillrobinsondan...@gmail.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: SecStaticCodeCheckValidity fails when app is lauched from Terminal

[じょいすじょん]

Have you also tried NSWorkspace for this?

> On 2016 Sep 27, at 2:38, Markus Spoettl  wrote:
> 
> It is an OSX Cocoa GUI application. I have always started it from the command 
> line by executing the executable inside the bundle. While this always worked, 
> it no longer seems to.
> 
> That said, it didn't occur to me that there's a proper way, by using the 
> "open" command. Thanks for the tip, this works nicely for my purposes!
> 
> Regards
> Markus
> 
> On 26/09/16 19:18, Gary L. Wade wrote:
>> In what way did you start your app from the Terminal?  Is this
>> WindowServer-based or a command line app?  Not sure your purpose in starting
>> from the command line if WindowServer-based, but have you tried launching it
>> with the open command where the argument is the .app bundle vs possibly 
>> another
>> way like the actual executable?
>> --
>> Gary L. Wade
>> http://www.garywade.com/
>> 
>>> On Sep 26, 2016, at 2:44 AM, Markus Spoettl >> > wrote:
>>> 
>>> I'm using SecStaticCodeCheckValidity() to self check the signature of my own
>>> app when it is launched. This works fine and always has.
>>> 
>>> All of a sudden, the call to SecStaticCodeCheckValidity() fails if (and only
>>> if the application) is started from the Terminal. When I start the very same
>>> app from the Dock or from the Finder the check succeeds (iow. the call 
>>> returns
>>> noErr).
>>> 
>>> I don't know exactly when it started failing. I only know it definitely 
>>> worked
>>> before on previous versions of El Capitan but now it no longer does (v 
>>> 10.11.6).
>>> 
>>> Any ideas?
>>> 
>>> Regards
>>> Markus
>>> --
>>> __
>>> Markus Spoettl
>>> ___
>>> 
>>> 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/garywade%40desisoftsystems.com
>>> 
>>> This email sent to garyw...@desisoftsystems.com
>> 
> 
> 
> -- 
> __
> Markus Spoettl
> ___
> 
> 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/dangerwillrobinsondanger%40gmail.com
> 
> This email sent to dangerwillrobinsondan...@gmail.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: C callbacks with NSNotificationCenter?

[じょいすじょん]

Have you considered Core Foundation?

https://developer.apple.com/library/ios/documentation/CoreFoundation/Reference/CFNotificationCenterRef/
It is all C

Another alternative is to look at the Objective-C runtime library routines.
You can do a lot with the language from C...

> On 2016 Sep 8, at 1:09, Andreas Falkenhahn  wrote:
> 
> As a C programmer I'm trying to avoid Objective C whenever and wherever 
> possible.
> The good thing is that I can do most interaction with Cocoa from normal C 
> functions.
> I only had to write very few classes. Most of the Cocoa stuff can be done
> from normal C functions just fine.
> 
> Now I'd like to subscribe to the AVPlayerItemDidPlayToEndTimeNotification
> notification. In an Objective C class, this is purportedly done like this:
> 
>[[NSNotificationCenter defaultCenter] addObserver:self 
> selector:@selector(itemDidFinishPlaying:) 
> name:AVPlayerItemDidPlayToEndTimeNotification object:playerItem];
> 
> This will call the "itemDidFinishPlaying" method in class "self" whenever
> an AVPlayerItem has finished playing.
> 
> Of course, I can't use this code in a normal C function because there are
> references to "self" and the selector thing doesn't look like it's compatible 
> to
> C. So I could just subclass AVPlayerItem and voila, everything's fine.
> 
> Still, I'm wondering: Is it also possible to have NSNotificationCenter call
> a C function for me whenever the notification triggers? Can this somehow
> be achieved or am I forced to use full Objective C here?
> 
> -- 
> Best regards,
> Andreas Falkenhahn  mailto:andr...@falkenhahn.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/dangerwillrobinsondanger%40gmail.com
> 
> This email sent to dangerwillrobinsondan...@gmail.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: Window Opened Notification?

[じょいすじょん]

> On 2016 Sep 6, at 18:49, Dave  wrote:
> 
>> 
>> Ah. 
>> Well in that case, you get accessibility and you need users to allow it 
>> once. 
> 
> I said in my original post - without using Accessibility 
> 
> Cheers
> Dave
I know. I remember. 
Point is, the AX API is your only realistic option to achieve this.
What you never really said is what you are really trying to accomplish.
With that, somebody might be able to point you to something useful.

You could try something with NSWorkspace & NSRunningApplication + CGWindowList

You could also try to hack together an NSEvent global event monitor or a 
CGEventTap approach and try to intercept and guess at events.
Pretty sure that would be very difficult with sandboxing.

Neither one would do quite what you would really like
___

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: Releasing properties?

[じょいすじょん]

> On 2016 Aug 27, at 23:31, Keary Suska  wrote:
> 
> 
>> On Aug 27, 2016, at 8:22 AM, じょいすじょん  
>> wrote:
>> 
>> 
>>> On 2016 Aug 27, at 23:09, Keary Suska  wrote:
>>> 
>>>> 
>>>> On Aug 27, 2016, at 5:22 AM, Andreas Falkenhahn  
>>>> wrote:
>>>> 
>>>> Consider the following example properties:
>>>> 
>>>>  NSApplication: @property(strong) NSMenu *mainMenu
>>>>  NSFont: @property(readonly, copy) NSString *familyName
>>>>  NSColorPanel: @property(copy) NSColor *color
>>>> 
>>>> AFAIU I must not release the NSMenu/NSString/NSColor obtained from these
>>>> properties because I don't own the objects returned by those properties and
>>>> Apple's memory management policy docs clearly say:
>>>> 
>>>>  "You must not relinquish ownership of an object you do not own"
>>>> 
>>>> So I think I've got that right but I'd be glad if somebody could just
>>>> confirm that I got it right ;)
>>>> 
>>>> I'm just a little confused because of the keywords "strong" and "copy" in
>>>> the @property declarations but AFAIU these only refer to setting those
>>>> properties, not getting those properties, i.e. the object is copied when
>>>> *setting* the property, not when *getting* it. Right?
>>>> 
>>>> And another question: Can it also happen that a class has a property
>>>> which returns an object which I *must* release or is it a general rule
>>>> that getting a @property always returns objects which I do not own
>>>> and hence mustn't released?
>>> 
>>> There are only specific method conventions that establish ownership: 
>>> alloc+init and new. This is because ownership should only be granted when 
>>> specifically requested by the caller. There is no good reason for an object 
>>> to require that a caller own a returned object. Now, some API could decide 
>>> to buck the convention and have a different object construction naming, but 
>>> the point is the same. If an API does anything else, it is badly designed. 
>>> Cocoa will never do this.
>>> 
>>> One could even argue (and some have) that there is no good reason for *any* 
>>> object method to return a retained object, as that forces the caller to 
>>> explicitly require ownership. And that is key: ownership is a function of 
>>> the caller, not the object.
>>> 
>>> HTH,
>>> 
>>> Keary Suska
>>> Esoteritech, Inc.
>>> "Demystifying technology for your home or business"
>>> 
>>> 
>> Just to keep everyone on the rules, I'm going to post the docs links.
>> It's too easy to quote it wrong. (not saying anybody did)
>> 
>> Objective-C
>> 
>> https://developer.apple.com/library/mac/documentation/General/Conceptual/DevPedia-CocoaCore/MemoryManagement.html
>> 
>> https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/MemoryMgmt/Articles/MemoryMgmt.html
>> 
>> Core Foundation (because you WILL use it at some point)
>> 
>> https://developer.apple.com/library/mac/documentation/CoreFoundation/Conceptual/CFMemoryMgmt/Concepts/Ownership.html
> 
> Doh! Forgot “copy”. Best to point to docs since they are clear and succinct.
> 
Easy to mess up :)


___

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: Releasing properties?

[じょいすじょん]

> On 2016 Aug 27, at 23:09, Keary Suska  wrote:
> 
>> 
>> On Aug 27, 2016, at 5:22 AM, Andreas Falkenhahn  
>> wrote:
>> 
>> Consider the following example properties:
>> 
>>   NSApplication: @property(strong) NSMenu *mainMenu
>>   NSFont: @property(readonly, copy) NSString *familyName
>>   NSColorPanel: @property(copy) NSColor *color
>> 
>> AFAIU I must not release the NSMenu/NSString/NSColor obtained from these
>> properties because I don't own the objects returned by those properties and
>> Apple's memory management policy docs clearly say:
>> 
>>   "You must not relinquish ownership of an object you do not own"
>> 
>> So I think I've got that right but I'd be glad if somebody could just
>> confirm that I got it right ;)
>> 
>> I'm just a little confused because of the keywords "strong" and "copy" in
>> the @property declarations but AFAIU these only refer to setting those
>> properties, not getting those properties, i.e. the object is copied when
>> *setting* the property, not when *getting* it. Right?
>> 
>> And another question: Can it also happen that a class has a property
>> which returns an object which I *must* release or is it a general rule
>> that getting a @property always returns objects which I do not own
>> and hence mustn't released?
> 
> There are only specific method conventions that establish ownership: 
> alloc+init and new. This is because ownership should only be granted when 
> specifically requested by the caller. There is no good reason for an object 
> to require that a caller own a returned object. Now, some API could decide to 
> buck the convention and have a different object construction naming, but the 
> point is the same. If an API does anything else, it is badly designed. Cocoa 
> will never do this.
> 
> One could even argue (and some have) that there is no good reason for *any* 
> object method to return a retained object, as that forces the caller to 
> explicitly require ownership. And that is key: ownership is a function of the 
> caller, not the object.
> 
> HTH,
> 
> Keary Suska
> Esoteritech, Inc.
> "Demystifying technology for your home or business"
> 
> 
Just to keep everyone on the rules, I'm going to post the docs links.
It's too easy to quote it wrong. (not saying anybody did)

Objective-C

https://developer.apple.com/library/mac/documentation/General/Conceptual/DevPedia-CocoaCore/MemoryManagement.html

https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/MemoryMgmt/Articles/MemoryMgmt.html

Core Foundation (because you WILL use it at some point)

https://developer.apple.com/library/mac/documentation/CoreFoundation/Conceptual/CFMemoryMgmt/Concepts/Ownership.html


___

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: NSAlert::runModal doesn't work on 10.6

[じょいすじょん]

> On 2016 Aug 22, at 23:04, Andreas Falkenhahn  wrote:
> 
> On 22.08.2016 at 15:49 dangerwillrobinsondan...@gmail.com wrote:
> 
> 
>>> On Aug 22, 2016, at 10:26 PM, Andreas Falkenhahn  
>>> wrote:
> 
>>> Does anybody have an idea
>>> what could cause this behaviour on 10.6 and how I can fix this?
>> http://bfy.tw/7Kcc 
>> there is a great resource here. 
> 
> You really think I didn't Google before asking? I certainly did, but
> so far I haven't found anything that could help me here. If you have
> anything more than just a Google search for "NSAlert 10.6", please
> elaborate... (or send a link)
> 
> -- 
> Best regards,
> Andreas Falkenhahnmailto:andr...@falkenhahn.com
> 
However you have not really shown any code at all.
So we do not know if you tested the returnCode from runModal against 
NSAlertFirstButtonReturn, NSAlertSecondButtonReturn, NSAlertThirdButtonReturn 
or all or none of these.

Without knowing more than the URL you shared saying you implemented what was in 
that document it's really hard to know what you might be doing wrong.

You might try the delegate-based sheet methods to run as described in the 
NSAlert class reference. (be sure to set your delegate and implement the 
callbacks)
You might try the completion handler sheet method. It's super compact.


For runModal, you do it inline, the delegate gets no callback unless you're 
using a help button.

// in simple test app.
- (void)applicationDidFinishLaunching:(NSNotification *)aNotification {
// Insert code here to initialize your application
NSAlert *alert = [NSAlert new];
[alert addButtonWithTitle:@"OK"];
[alert addButtonWithTitle:@"Cancel"];
[alert setInformativeText:@"Informative text here."];
[alert setDelegate:self]; // Does nothing here unless we had a help 
button, because this is app modal.
NSInteger returnCode = [alert runModal];
NSLog(@"%@ %@ alert=%@ returnCode=%ld", self, 
NSStringFromSelector(_cmd), alert, returnCode);
if (returnCode == NSAlertFirstButtonReturn) {
NSLog(@"first button return %ld", returnCode);
} else if (returnCode == NSAlertSecondButtonReturn) {
NSLog(@"second button return");
} else if (returnCode == NSAlertThirdButtonReturn) {
NSLog(@"third button return");
} else {
NSLog(@"unknown button return");
}

}

I sure don't have anything that runs 10.6 so I couldn't even test it there, but 
I see no indication in the NSAlert Class Reference document history that would 
say this should not work.

You can of course also use a switch-case flow here instead of if-else.
Remember runModal is app-modal, so it doesn't return control to anything about 
the app until a button is pressed.

Really, you should consider using the delegate based sheet methods, assuming 
your app as a scripting language tool is document centric by design, wouldn't 
you want alerts to be more contextual?

App modal sheets are also possible.
https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/Sheets/Tasks/UsingAppModalDialogs.html



___

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: Ending NSTask doesn't release file handle opened by the task it wraps.

[じょいすじょん]

> On 22 Jul 2016, at 8:22, Uli Kusterer  wrote:
> 
> On 21 Jul 2016, at 17:20, Graham Cox  wrote:
>> One of my apps uses NSTask to wrap a command line utility that is embedded 
>> in the same app’s resources. This utility writes files to disk - I have no 
>> knowledge of which APIs it uses to do this. If the task has ended (and I can 
>> see that the actual instance of the running command line tool has 
>> disappeared from my process tasks in Activity Monitor), and I send the file 
>> to the trash, I can’t delete it (empty trash) until the app as a whole is 
>> quit - I get the message that the file is still in use.
>> 
>> I’ve checked that I’m closing down the NSTask properly, as far as I can see.
>> 
>> Is this the expected behaviour?
> 
> Are you reading all the data from the task (i.e. its standardOutput, not the 
> file) before you close it? AFAIR that's a prerequisite for it to properly 
> close.
> 
If that fixes it and it's not documented, please file a bug against the docs.


___

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: Tick marks on scroll bars

[じょいすじょん]

Did you do run into any issues with rubberbanding and responsive/momentum 
scrolling?

> On Jun 14, 2016, at 1:03 AM, Jens Alfke  wrote:
> 
> I've done it by subclassing NSScroller. (The code's not open-source, though.)
> As far as I know, that's the only way to do it. It's fairly easy.
> 
> —Jens
> 
> ___
> 
> 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/dangerwillrobinsondanger%40gmail.com
> 
> This email sent to dangerwillrobinsondan...@gmail.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: quicklook audio sample rates

[じょいすじょん]

> On Jun 11, 2016, at 1:43 AM, Kyle Sluder  wrote:
> 
> On Thu, Jun 9, 2016, at 08:03 PM, George Toledo wrote:
>> I'm having a hard time finding documentation that covers this question...
>> 
>> Does Quicklook play audio of a previewed file at the sample rate it was
>> encoded at, or is it somehow doing a samplerate conversion on the fly?
>> 
>> Hopefully this isn't considered off topic. Though it doesn't directly
>> concern Obj-C/Cocoa code, I was looking for an answer in the Quicklook
>> Programming guide, and couldn't find one.
> 
> This is a highly specific question and is unlikely to be documented. I’m
> curious why you’re interested.
> 
> At the end of the day, the audio hardware operates at some particular
> bitrate, so unless your source exactly matches the hardware sample rate
> there’s likely to be a SRC in the audio pipleline *somewhere*.
> 
> --Kyle Sluder
I assumed the OP is interested to know whether listening to the playback in 
QuickLook is going to be a valid exercise
for a pro audio person, versus opening the file in any particular application.
It could certainly be a less onerous workflow for one to quickly review audio 
and choose a good take or a good mix.
If QuickLook were coloring the audio differently than other software that would 
be a workflow to avoid.
(and something to note to a customer!)
Probably worth filing a radar or checking on the core audio list.

> 
>> 
>> Thanks,
>> George Toledo
>> ___
>> 
>> 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/dangerwillrobinsondanger%40gmail.com
> 
> This email sent to dangerwillrobinsondan...@gmail.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