Re: Concurrent loading of images?

[João Varela via Cocoa-dev]

> I also read about the GCD's dispatch queues, but it seems to me that this
would not be the suitable approach since I always only have one task
running concurrently to the main thread.

>
> Why not? Dispatch queues are always available. (The main thread is simply
> a special queue.) You can run the background task by creating a single
> dispatch queue and then using dispatch_async to call a block that does the
> work. The end of the block would call dispatch_async back to the main queue
> and pass the image as a parameter.


I could not agree more with Jens. Great Central Dispatch has been a big
boon. Before GCD, I would not touch multithreaded code with a ten-foot
pole. Now I use it everyday and I can increase responsiveness as never
before. I would definitely take a look at it. You can load images with a
background thread and then when the loading is done you can dispatch it to
the main queue for display. It has never been so easy to do that.

João


>
>
___

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: Customizing the Notarization Workflow fails

[João Varela via Cocoa-dev]

> On 3 May 2020, at 21:31, Gabriel Zachmann  wrote:
> 
> Thanks a million to everybody for responding to my question!
> 
> 
> I have been following Joao's instructions at
> 
>   
> https://stackoverflow.com/questions/53101626/how-to-notarize-an-app-bundle-containing-helpers-embedded-in-it/56799591#56799591
>  
> 
> and those at:
> 
>   https://forums.developer.apple.com/message/338167#338167 
> 
> 
> Notarization of my screen saver seems to work now.
> 
> However, I am still confused, but I prefer to understand what is going.
> So, I'd appreciate it very much if you could enlighten me.
> 
> 
> First of all, in the build settings I have "Code Signing style" = Manual.
> (And in the Signing & Capabilities section, "Automatically manage signing" is 
> OFF.)
> Now, when I build my screen saver, Xcode still opens a dialog saying "code 
> sign wants to access key "Mac Developer ID Application...".
> THat's fine with me, I am just confused: I thought, when automatic code 
> signing is OFF, then Xcode doesn't code sign the screen saver at all.

That should not happen. Are you sure you did the second step and changed "Mac 
Developer" to "Developer ID Application” on your keychain in the Code Signing 
Identity?

> 
> Could some kind soul please shed some light on this?
> 
> 
> Next, when I try to verify the signature like this:
> 
>codesign - -R="anchor apple" /tmp/Release/ArtSaver.saver
> 
> I get this output:
> 
> /tmp/Release/ArtSaver.saver: valid on disk
> /tmp/Release/ArtSaver.saver: satisfies its Designated Requirement
> test-requirement: code failed to satisfy specified code requirement(s)
> 

Perhaps this is linked to the fact that you are not using the proper 
certificate. You must use Developer ID Application certificate on your keychain 
to be able to deploy your screen saver in machines other than the development 
one you are using.

Another problem that can cause it is if you do not set your TeamIdentifier 
properly.

Try this in Terminal and see what you get:

codesign --display --requirements - --verbose=4 /tmp/Release/ArtSaver.saver

May be it will explain to you what is going wrong.


> The last line concerns my a little - should I worry about it?
> What does it mean?
> (Naturally, in Xcode there is no entitlements section since this is a screen 
> saver.)

Yes, you need to worry about it and you need to fix this error.

> 
> 
> Other than that, however, the signing and notarization seems to work.
> At least, the response email from Apple says so.
> 
> 
> 
> Another question is with regards to build settings.
> Xcode now issues the warning "Update to recommended settings",
> and the details say:
> "Target ... - Switch to Development Signing. This will set the 
> CODE_SIGN_IDENTITY setting to "Apple Development" ... "
> I guess I should not let Xcode change that to the "recommended settings" 
> (see Joao's instructions) - am I correct?

Yes, you are correct. You need to disregard this warning. Just uncheck those 
warning checkboxes and go your merry way. Every new version of Xcode will 
always try to make you use the automated version of signing, which you can’t.


> But I am still wondering:
> 1. What do the different options in the "Code Signing Identity" 
> (CODE_SIGN_IDENTITY) mean? Naturally, I googled about it, and read the docs 
> at https://help.apple.com/xcode/mac/current/#/dev154b28f09 
>  , but I am still in 
> the dark)

That’s the certificate you should use. For debugging, Mac Developer certificate 
is OK and is recommended, but for a release version you must use Developer ID 
Application certificate to release it outside the Mac App Store.


> 2. Can I tell Xcode that the current setting is fine and it should not issue 
> a warning about it?
> 

See my comments above.

HTH,

João

___

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: Customizing the Notarization Workflow fails

[João Varela via Cocoa-dev]

Hi, Gabriel

As far as I know, if it is not a standard application package, you cannot use 
the organizer to archive properly a package and then send it to the notarizing 
server. I struggled with it for a long time, more than a year, until Apple gave 
us the proper documentation in WWDC 2019 for us to know what to do. I even 
spent a DTS ticket with no avail. The Apple engineer who was responsible for my 
ticket was never able to tell me what I should do. I found the right way by 
trial and error. Therefore, FORGET organizer, as it will never work with 
non-standard packages. Instead, read my answer in Stack Overflow:

https://stackoverflow.com/questions/53101626/how-to-notarize-an-app-bundle-containing-helpers-embedded-in-it/56799591#56799591
 


Even though you might mot have the exactly same package organization, I’m 
almost sure the way I recommend will work for you as well.

Don’t hesitate to ask if you run into trouble.

João




> 
> Thanks a lot for your response.
> 
>> I?m not sure how you would script the export, but if you go to menu option 
>> Window ->  Organizer, you can see your archives.
> 
> Yes, I can see them.
> But when I do "Show in Finder", then "Show package contents", they contain 
> nothing
> (except for an empty Products folder, and an Info.plist).
> 
>> From there you can export. Apps have the button ?Distribute App?, and a 
>> command line program has the button ?Distrubute Content?.
> 
> Yes, screen savers have the ?Distrubute Content? button, too.
> 
>> Clicking that button lets you export the archive or the app/built products. 
>> Those are exported into a folder named with the date by default.
> 
> Yes, but they contain just an empty "Products" folder.
> 
> 
> Best regards, Gabriel

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Adding helper target to macOS app?

[João Varela via Cocoa-dev]

Hi Jean-Daniel

Good, complex question, and perhaps I am doing something wrong, but this was 
the solution that worked every time. 

My reasons are the following:

1) Because I rolled out my automatic versioning system and needed to edit 
automatically the info.plist files of the main app, of the helpers and of the 
common framework that all apps are using

2) Because very often, if not always, Xcode would complain that a product was 
already present in a given location and would fail copying the new version of 
the helper (perhaps that issue was already resolved, but that was my 
experience) -> This is only true for locations inside the bundle to which Xcode 
does not offer an option using the popup menu of the Copy Files phase. For 
example, for putting frameworks in the right location, that’s not needed.

3) I found easier to use scripts to create the Helpers and the LoginItems 
directories inside the bundle and only then use the copy files phases to copy 
the apps to the proper locations

4) To better control the stripping of the executables, because when I started 
working with Xcode the stripping process was not as thorough as I wanted it to 
be.

Perhaps, I’m doing a few extra steps right now, but if things are working, I’m 
not going to change them.

HTH

João


> On 4 Apr 2020, at 20:26, Jean-Daniel  wrote:
> 
> 
> 
>> Le 3 avr. 2020 à 15:44, João Varela via Cocoa-dev 
>>  a écrit :
>> 
>> Hello, Laurent
>> 
>> As far as I know, the documentation is still valid. 
>> 
>> I would start reading this:
>> 
>> https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/DesigningDaemons.html#//apple_ref/doc/uid/1172i-SW4-BBCBHBFB
>>  
>> <https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/DesigningDaemons.html#//apple_ref/doc/uid/1172i-SW4-BBCBHBFB>
>> 
>> and this:
>> 
>> https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/DesigningDaemons.html#//apple_ref/doc/uid/1172i-SW4-BBCBHBFB
>>  
>> <https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/DesigningDaemons.html#//apple_ref/doc/uid/1172i-SW4-BBCBHBFB>
>> 
>> and this:
>> 
>> https://developer.apple.com/library/archive/documentation/CoreFoundation/Conceptual/CFBundles/Introduction/Introduction.html#//apple_ref/doc/uid/1123i-CH1-SW1
>>  
>> <https://developer.apple.com/library/archive/documentation/CoreFoundation/Conceptual/CFBundles/Introduction/Introduction.html#//apple_ref/doc/uid/1123i-CH1-SW1>
>> 
>> 
>> macOS has a plethora of options, and that depends a lot on what you want to 
>> achieve and the degree of security you need / you want to impose on the main 
>> app and its helpers.
>> 
>> Personally, I have an app bundle that look like this:
>> 
>> MainApp.app/
>>  Contents/
>> info.plist
>> MacOS/
>>   MainExecutable
>> Helpers/
>>   Helper1.app
>>   Helper2.app
>> Library/
>>   LoginItems/
>>  LoginItem.app
>> Resources/
>>… all resources here, including help and icon files
>> 
>> I create different targets for the main app and for each helper and login 
>> item and then use scripts to build the whole bundle
> 
> Out of curiosity, why are you using custom scripts and not simply some « Copy 
> File » Build step to assemble the bundle ?
> 

___

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: Adding helper target to macOS app?

[João Varela via Cocoa-dev]

Hello, Laurent

As far as I know, the documentation is still valid. 

I would start reading this:

https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/DesigningDaemons.html#//apple_ref/doc/uid/1172i-SW4-BBCBHBFB
 


and this:

https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/DesigningDaemons.html#//apple_ref/doc/uid/1172i-SW4-BBCBHBFB
 


and this:

https://developer.apple.com/library/archive/documentation/CoreFoundation/Conceptual/CFBundles/Introduction/Introduction.html#//apple_ref/doc/uid/1123i-CH1-SW1
 



macOS has a plethora of options, and that depends a lot on what you want to 
achieve and the degree of security you need / you want to impose on the main 
app and its helpers.

Personally, I have an app bundle that look like this:

MainApp.app/
   Contents/
  info.plist
  MacOS/
MainExecutable
  Helpers/
Helper1.app
Helper2.app
  Library/
LoginItems/
   LoginItem.app
  Resources/
 … all resources here, including help and icon files

I create different targets for the main app and for each helper and login item 
and then use scripts to build the whole bundle and sign it properly using the 
inside-out principle. To know then how to notarize this complex bundle, I 
recommend my answer at Stack Overflow, because not even DTS could help me with 
it. Only the documentation of WWDC was able to show me the light, so to speak:

https://stackoverflow.com/questions/53101626/how-to-notarize-an-app-bundle-containing-helpers-embedded-in-it
 


HTH

J. Varela


> 
> I?m looking for information about how to properly add a helper app to a macOS 
> application. So far, I?ve found just piecemeal here and there about some 
> parts, but nothing that is recent and documents the entire process. It seems 
> that there are many moving parts, e.g. sandboxing, adding it to the login 
> items, etc.
> 
> Anyone knows some good references?
> 
> Thanks in advance!
> 
> -Laurent.
> -- 
> Laurent Daudelin  
> laur...@nemesys-soft.com 
> Skype: LaurentDaudelin
> Logiciels N?m?sys Software
> http://www.nemesys-soft.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: Seeing nil passed to isEqual:, despite non-null declaration

[João Varela]

Hi Sean

Yes, I was bitten by that too, very, very recently, when I was translating a 
few files into Swift and I got warning when I didn’t use an optional for the 
object of the method.

Actually, I suspect that’s a bug in the headers, or probably that’s a 
non-audited header for nullability.

Although isEqual: is part of the NSObject protocol and isEqualTo: is part of 
the NSComparisonMethods protocol of NSObject, the latter expects a nullable 
receiver (check that in NSScriptWhoseTests.h). Check the Swift version of it 
and you will see that isEqual(to: Any?) expects an optional. Therefore, I 
suspect that the same is true for isEqual: and that this API has not yet been 
audited for nullability.

Perhaps you should file a bug against that header.

João



> 
> 
> NSObject.h declares:
> 
> - (BOOL)isEqual:(id)object;
> 
> Note the parameter is not nullable.  And yet, I'm seeing nil passed to one of 
> my class's overrides of isEqual: when I invoke Edit>Undo.  Backtrace:
> 
> #4-[RRLookupTable isEqual:]
> #5-[NSManagedObject(_NSInternalMethods) _updateFromUndoSnapshot:] ()
> #6-[NSManagedObjectContext(_NSInternalChangeProcessing) _undoInsertions:] 
> ()
> #7-[_NSUndoStack popAndInvoke] ()
> #8-[NSUndoManager undoNestedGroup] ()
> #9_os_activity_initiate ()
> #10   -[NSApplication(NSResponder) sendAction:to:from:] ()
> #11   -[NSMenuItem _corePerformAction] ()
> #12   -[NSCarbonMenuImpl performActionWithHighlightingForItemAtIndex:] ()
> #13   _os_activity_initiate ()
> #14   -[NSMenu performKeyEquivalent:] ()
> #15   routeKeyEquivalent ()
> #16   -[NSApplication(NSEvent) sendEvent:] ()
> #17   -[NSApplication run] ()
> #18   NSApplicationMain ()
> #19   main
> 


___

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: Drag and drop on table view

[João Varela]

> 
> I am still not sure if I am doing this the right way (extending NSTableView) 
> because Xcode says "Subclassing NSTableView is usually not necessary”.
> 
> Jan E.

Yes, it is usually not necessary and I would go so far as saying that you 
shouldn’t. I normally create a new delegate class and override the recommended 
NSTableView delegate methods. Subclassing has too many caveats that the normal 
mortal has the tendency to get it wrong. And I’m assuming you are a “normal 
mortal”. ;)

João
> 

___

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: Date Formatter relative date formatting

[João Varela]

As a native Portuguese speaker, I can tell you that it is NOT normal to 
capitalize “Hoje” at the end or in the middle of a sentence. The same is true 
for “today" in English. Thus, I think these variations of capitalisation are 
bugs. A similar bug was true when the days of the week were not capitalised in 
pt_PT, but they should. Apple fixed that bug, but in the meantime the 
governments of Portugal and Brazil tried to come together concerning their 
“spelling differences” and then decided that the days of week should always be 
spelled in low case, even in “pt_Pt”. So there you go! A fixed bug became a bug 
again.

> 
> On Oct 28, 2016, at 03:05:06, Daniel Phillips  > wrote:
>> 
>> When using NSDateFormatter for relative date formatting, I am getting the 
>> localised word for today capitalised in some locales not not all. Is this 
>> expected behaviour?  I’ve tried to research this and it seems the word today 
>> shouldn’t be capitalised (in English at least...) unless it’s used in a 
>> title, if true, then is this a bug in NSDateFormatter?
> 
> I seriously doubt that the team used capitalized letters willy nilly when 
> entering these terms. I'm sure they researched how these terms are used when 
> they appear as a standalone relative date, not used in a sentence. If it bugs 
> you, just run it through lowercaseString before you put it into your "Free 
> until" string, although that would also convert AM/PM to lower if it's 
> included, depending on the user's prefs. Personally, it doesn't bother me 
> that the word "Today" gets the same treatment when used that way as do the 
> names of the days of the week. Think of it as the virtual placeholder name 
> for the referenced day.
> 

___

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

Bugs in HIThemeDrawWindowFrame and HIThemeDrawTitleBarWidget in Sierra?

[João Varela]

Does anyone has had experience in drawing custom windows with the help of 
HIThemeDrawWindowFrame and HIThemeDrawTitleBarWidget? I know Jens has had some, 
as I checked the archives of the list before I posted this.

I have managed to draw a custom window with a vertical title bar and the 
traffic light widgets on the left for many years until I upgraded today to 
Sierra. Now I all I get are empty widgets with no color in them and the 
tracking that I use (and still works) for mouseEntered and mouseExited events 
no longer has any effect on the widgets, such as having the cross and the minus 
being drawn inside them (although the title bar is drawn correctly).

I will definitely file a bug, but in the meantime I would like to know if 
someone has encountered this bug and if you managed to get around it. Any help 
is appreciated.

Thanks,

J.V.
___

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: NSScrollView and NSTrackingArea woes [SOLVED]

[João Varela]

First of all I would like to thank everybody that tried ho give me a hand. I 
really do appreciate it.
I also want to write this email to let people know how I solved the problem, so 
that the readers of this list do not have to go through a week of frustration 
as I have. Well, it took so long because this is a side project, and I am not 
working on it all the time.

For those who did not follow this thread from the beginning, the problem (bug) 
that I was hitting is that setting up NSTrackingArea objects in the document 
view of an NSScrollView works as expected except when the user begins to scroll 
and the inertia scrolling option is on. A way to avoid this is to turn off 
inertia scrolling as Muthu suggested, but then the scrolling is jumpy at best.

Here are my conclusions:

1) Using NSTrackingArea objects is fine and dandy as long as you do not change 
the superview and its subviews and you do not place them in a scrolling view or 
you do not have to add and remove subviews, sometimes in a very dynamic way as 
I had to do (because I wanted a scenario of scrolling vertically, but also 
horizontally, and when the latter case, the old subviews had to be removed and 
new ones had to be created and added to the document view programatically). To 
manage the tracking areas of all the subviews that came and went or that were 
in a scrolling view in such a scenario is really a nightmare. I can understand 
that, because NSTrackingArea objects were not designed to handle such dynamic 
scenarios. Apparently, there are exceptions to this. I checked several example 
of sample code by Apple that NSTrackingArea objects can be used quite well even 
in a scrolling view as along as they are in an NSTableView or NSOutlineView 
(for that I highly recommend that you check the PhotoSearch and the 
HoverTableViewRow sample code).

2) Using NSTrackingArea with the option NSTrackingCursorUpdate and overriding 
cursorUpdate does not work well in small rects (e.g. heights around 7.0 or 
less).

3) I learned that you do not have to override -updateTrackingAreas for the 
NSTrackingArea objects to update in some scenarios. You can check this in the 
HoverTableViewRow sample code by Apple, which uses this method to set up the 
tracking area once without any further work from the developer, which goes 
against the sample code given by the documentation. I tried it in my code and 
it worked although it did not solve the bug I was hitting.

4) After experimenting many, many scenarios suggested by Ken, Quincey and John, 
I find out that that the only way to make everything work as I intended was to 
create a unique NSTrackingArea in the document view and then using mouse-moved 
events inside this rect to find the subview and then dispatch this event to it. 
This solved all my problems and now the tracking is correct even with the 
inertia scrolling on.

I hope this will help someone else in the future. 

> On 17 Jul 2015, at 04:31, dangerwillrobinsondan...@gmail.com wrote:
> 
> Why not just observe bounds change notifications from the clipview?
> Then handle those with the update call.
> 
> Sent from my iPhone
> 

___

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: NSScrollView and NSTrackingArea woes

[João Varela]

On Friday, July 17, 2015, Ken Thomases  wrote:

> On Jul 16, 2015, at 8:19 PM, João Varela  > wrote:
> >
> > I’m passing [self bounds]. And no, I am not using NSTrackingInVisibleRect
>
> Why aren't you using that?  That seems like the most obvious way to get
> correct behavior.  The only reason you wouldn't use it is if you were
> adding a tracking area that was only for a portion of a view, but you say
> you're using the view's bounds.


Passing self.bounds it is the simpler case I am using to test this problem.
Indeed I need to create two tracking areas that do not coincide with the
subview's bounds.

That might make the whole issue go away.  (Or it might not.)
>
> Unfortunately it does not solve that, because I tried that option and the
results are the same.


> Does your implementation of -updateTrackingAreas call through to super?
> The docs say it should.  I notice that your coalescing implementation did
> not.


You are right. I included such call to the super at the beginning or at the
end, and yes the same problem remains.


> > Yes, the tracking area is incorrect and apparently I cannot invoke
> -updateTrackingAreas myself because it apparently messes up with the
> NSTrackingArea’s of the subviews and most likely of the clipView, etc.
> >
> > So I guess this problem could be solved if there were a method to tell
> the OS that the tracking areas are invalid (and thus they need to be
> updated). However, apparently there is none, AFAICT. Or is there?
>
> You can't invoke -updateTrackingAreas yourself, but there's nothing
> preventing you from removing old tracking areas and adding new ones, as
> appropriate, any time you like.  You can put that code in a method of your
> own which is called by -updateTrackingAreas plus any other time you want.


Hmm, that I haven't tried. If that works you'll be my hero.

>
> Regards,
> Ken
>

Thanks, João
___

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: NSScrollView and NSTrackingArea woes

[João Varela]

> On 15 Jul 2015, at 18:28, Quincey Morris 
>  wrote:
> 
> On Jul 15, 2015, at 03:08 , João Varela  <mailto:joaocvar...@gmail.com>> wrote:
>> 
>> However, none of this happens when the user only scrolls (up or down) a 
>> little and does not reach the top or bottom of the document view. In this 
>> case, not only the -updateTrackingAreas method of the subview is not called, 
>> but also the cursor is no longer updated properly, because the 
>> NSTrackingArea’s of the subviews have not updated correctly. It seems as 
>> though I am not the only one getting bitten by this problem. See here:
> 
> Your assumption about *when* updateTrackingAreas will be called is incorrect. 
> Depending on the way you create the tracking area, and the amount of the 
> scroll, the tracking area might not need to be changed at all.

It must be changed because when that happens the tracking area remains in the 
old location, which no longer coincides with the new location of the subview.

> 
> So, there are at least three issues you need to resolve:
> 
> 1. Are you setting up the tracking area properly? For example, are you 
> specifying the area in the correct coordinate system? Are you using suitable 
> options?

Yes, AFAICT. The options I am using are the following:

 NSTrackingAreaOptions options = NSTrackingMouseEnteredAndExited | 
NSTrackingMouseMoved|
NSTrackingActiveInActiveApp;

I tried many other combinations, including NSTrackingActiveAlways instead of 
NSTrackingActiveInActiveApp

but that does not matter. The results are always the same. And yes, I am using 
the subview’s coordinate system, not the superview’s. I’m passing [self 
bounds]. And no, I am not using NSTrackingInVisibleRect

> 
> 2. When you scroll the view, what *actually* happens to the tracking area? 
> For this, you’re not interested so much in what happens immediately to the 
> cursor, but rather whether moving the cursor away and back again will “find” 
> the tracking area, either in the correct place or in an incorrect place.

See above. The tracking area does not follow the subview to its new location. 
However, as soon as the scrolling hits the top or the bottom of the document 
view they suddenly match again, because -updateTrackingAreas was called. If I 
use my hack of invoking the superview and subviews -updateTrackingAreas myself, 
it seems that this messes up the tracking areas, although with the following 
detail: It seems as though that the tracking area has been updated correctly, 
because if I hover the mouse on one of the scrolled subviews the cursor 
initially changes to the correct shape in the expected (correct) location, but 
almost immediately returns to the arrow cursor and stays like this as though 
all tracking areas were no longer there. Very weird. So I cannot use this hack. 
Another interesting thing is that Muthu’s suggestion about disabling inertia 
scrolling eliminates this problem completely, but it is an unacceptable 
solution, because the scrolling is not smooth any longer. So this bug has 
something to do with the inertia scrolling indeed.

> 
> 3. The clip view (the view between the scroll view and the document view in 
> the hierarchy) also has a tracking area, and the scroll view also has a 
> “documentCursor” property. Thus, other views may explicitly change the cursor 
> at unexpected times. You need to investigate whether the tracking area is 
> incorrect, or whether the cursor is just getting re-set to something else.

Yes, the tracking area is incorrect and apparently I cannot invoke 
-updateTrackingAreas myself because it apparently messes up with the 
NSTrackingArea’s of the subviews and most likely of the clipView, etc. 

So I guess this problem could be solved if there were a method to tell the OS 
that the tracking areas are invalid (and thus they need to be updated). 
However, apparently there is none, AFAICT. Or is there?

Another option, which I truly dislike, is to roll out my own tracking of the 
mouse in the document view by adding the tracking areas to this view instead of 
to the subviews, but then I would have to calculate the location of each 
subview, which is a waste, because that would come for free if I did that 
directly in the subview.

> 
> Unfortunately, this is hard to debug, because debugging changes the state of 
> your window and the position of the cursor.

You bet. I’ve been stuck with this apparently simple problem for a few days 
already.



___

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: NSScrollView and NSTrackingArea woes

[João Varela]

> On 15 Jul 2015, at 11:44, Muthulingam Ammaiappan  
> wrote:
> 
> Hi J.Varela,
> 
> 
> i too faced the same problem... and   i found that "inertial scrolling" has 
> the reason for this misbehaviour.
> so "disable the inertia scrolling" will solve this problem.
> 
> just add the following line to your  application init method...
>  [[NSUserDefaults standardUserDefaults] setBool:NO 
> forKey:@"AppleMomentumScrollSupported"];//disable the inertia scrolling 
> 
> 
> 
> Thanks & Regards,
> 
> Muthu
> 
> 

Thanks, Muthu, it really solved the problem I was seeing, but the scrolling is 
not smooth at all with that option off. Thus, I really have to find another 
solution.

___

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

NSScrollView and NSTrackingArea woes

[João Varela]

Hi,

I am implementing two custom classes, one of them is the document view inside 
an NSScrollView and the other is a subview of the document view. I need to 
create two NSTrackingArea’s to display the appropriate cursor when the mouse 
hovers over specific areas of the subviews. As instructed by Apple, I 
implemented an -updateTrackingAreas method to update the tracking areas when 
needed. Everything works as expected if the window and its views and subviews 
are resized or if the app is re-activated or the window becomes the key window 
again. Everything works well too when the user scrolls up or down to the end of 
the document view. The NSTrackingArea’s are updated correctly and the 
-updateTrackingAreas method is called in all these occasions.

However, none of this happens when the user only scrolls (up or down) a little 
and does not reach the top or bottom of the document view. In this case, not 
only the -updateTrackingAreas method of the subview is not called, but also the 
cursor is no longer updated properly, because the NSTrackingArea’s of the 
subviews have not updated correctly. It seems as though I am not the only one 
getting bitten by this problem. See here:

http://stuccy.com/questions/17731292/mouseovers-in-nscollectionviewnsscrollview 


I tried to circumvent this problem by detecting when the origin.y of the 
document view rect is not changing anymore within the NSScrollView (this is not 
easy on OS X because there is no notification to tell us when scrolling ended 
if you want to support OS X 10.8). For this purpose, I added a method in a 
NSScrollView subclass that does just that:

- (void)updateTrackingAreas
{
if (_y != self.documentVisibleRect.origin.y)
{
_y = self.documentVisibleRect.origin.y;

if (!_isScheduled)
{
dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(1.0 * 
NSEC_PER_SEC)),
   dispatch_get_main_queue(),
   ^{
   if (_y != self.documentVisibleRect.origin.y)
   {
   [self updateTrackingAreas];
   }
   else
   {
   [_documentView updateTrackingAreas];
   }
   
   _isScheduled = NO;
   });

_isScheduled = YES;
}
}
}

This method is called every time the user uses the scroll wheel as it is 
invoked inside the -scrollWheel method of the NSScrollView subclass. It works 
as expected and coalesces all the scroll wheel events into just one call. When 
the scrolling stops, indeed the [_documentView updateTrackingAreas] is called, 
which then invokes the subview’s -updateTrackingAreas method. This should do 
the trick, but it doesn’t.

Thus, before I try the solution given in the link above, which I find even more 
hacky than my own solution, is there something that I am missing? Why wouldn’t 
the NSTrackingArea’s update correctly when they do so if the window is resized 
or becomes key again or the user scrolls up or down to the end? What is the OS 
doing in these situations that I am not doing here?

I would appreciate any feedback,

J. Varela
___

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: Who is launching my helper?

[João Varela]

I’m just guessing here but most probably your helper is being relaunched 
automatically by the OS itself by receiving a reopen command, because it was 
running before the user logged out. I think you need to either prevent that or 
handle that possibility in your code. I had a similar problem that this is only 
seen upon a reopen event and not upon a launch invoked by the user. If you are 
using objective C you could insert this in your NSApplication delegate:

- (BOOL)applicationShouldHandleReopen:(NSApplication *)theApplication
hasVisibleWindows:(BOOL)flag
{
return NO;
}

- (BOOL)applicationShouldOpenUntitledFile:(NSApplication *)sender
{
return NO;
}

If you are using plain C, then you really need to ignore such event or handle 
such arguments in your code.

> 
> If the helper tool gets bad arguments, it logs and displays to the user an 
> error indication.  During the last few months, possibly since Yosemite, this 
> has occurred and been reported to me by users a half dozen times.  The error 
> in their logs indicates that the parent process invoking my helper is, 
> unfortunately, launchd, so that doesn’t tell me much.  It also says that it 
> is receiving two arguments instead of five, and that these two arguments are
> 
> 1.  As expected, the path to the tool.
> 2.  -psn_0_430185  (for example)
> 
> Regarding the second argument, I’ve seen this before.  I know it is a process 
> serial number, but when I launch my *app* by doubleclicking in Finder, I 
> don’t get a -psn argument.  Does the presence of the -psn argument give me 
> any clues as to how or why my helper is being invoked?
> 
> A couple more clues, from one user…
> 
> He told me that the error occurred during login after a restart. It is rare, 
> but part of my design, that if my helper is in the middle of a job and gets 
> terminated due to user logging out, a fail-safe “standby" launchd agent will 
> remain and, the next time the user logs in, will relaunch my tool, properly, 
> with five arguments.  I’ve retested this mechanism recently and, for me, it 
> works fine.  The tool runs, re-does it work, and terminates itself. 
> 
> This user also sent a screenshot showing that, after he dismissed the error, 
> a blue *folder* icon named “Helpers” showed up in his ⌘-tab application 
> switcher!  Believe it:
> 
> 
> 
>   Bigger: https://www.flickr.com/photos/113343850@N03/16143184547/
> 
> I presume that this is related to my tool, because of my “Contents/Helpers”.  
> “Helpers" is not a common folder name.  How could OS X get the crazy idea 
> that my app’s Contents/Helpers folder belongs in the application switcher?  
> Has anyone ever seen a folder in there like that?
> 
> Whenever a user reports something totally off the wall like this, I look in 
> their logs for evidence of any code-injecting hacks, SIMBL in particular.  
> (SIMBL is still around; just caught one last week!)  But I’ve not seen any 
> such hacks in logs from users with this issue.
> 
> Jerry Krinock
> 
> 

___

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: licence key validation method

[João Varela]

Hi

I rolled out my own license scheme so that I don’t have to pay anyone. ;) I 
find that coding license checking methods with Cocoa and Objective-C is 
terribly unsafe. Objective-C has the nasty habit of exposing classes and their 
methods, which you can easily access/find out if you know what you are doing 
(otool and class-dump for starters). I do all my license checking code in C++ 
or just plain C, and use redundant checking in different places. Another trick 
I learned in a conference is to use critical variables as static variables 
rather than class ivars. However, my needs are probably different than yours, 
but all I’m saying be careful how you expose your licensing code if you are 
going to use objective C.

Please read this:

http://loadcode.blogspot.pt/2006/02/cracking-software-on-os-x.html

and this:

http://lifehacker.com/5736101/how-to-crack-just-about-any-mac-app-and-how-to-prevent-it

HTH

J. Varela
___

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: View-based outline view problem

[João Varela]

>
>On 11 Jul 2014, at 7:44 am, João Varela  wrote:
>
>>Ithas been officially declared by Apple that cell-based NSOutlineView¹s
>>and
>>NSTableView's are deprecated.
>
>Would you care to point to where? I'm not arguing, but you wouldn't think
>so from the documentation. I see: "NSCell-based tables continue to be
>supported in OS X v10.7 and later, but they’re typically used only to
>support legacy code." That hints at deprecation at some stage, but I
>don't see that it has happened yet.

First of all my apologies for not having changed the subject of my first
email. 

You can check that formal declaration in the WWDC 2014 video called
“What’s new in Cocoa”. Fast forward to 51:00 and you’ll see that formal
declaration. Everything that is NSCell- and NSMatrix-based is deprecated
or on its way to formal deprecation.


HTH

João Varela



___

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: Cocoa-dev Digest, Vol 11, Issue 374

[João Varela]

I am also moving all my cell-based NSOutlineView¹s and NSTableView¹s to
the corresponding view-based versions. There is a good reason for it. It
has been officially declared by Apple that cell-based NSOutlineView¹s and
NSTableView's are deprecated. So start moving your code to the newest
technologies sooner rather than later. If you don¹t now you may be out of
luck in the future. For what I could see it is not very complicated.
Actually, some of things become simpler.

HTH

João Varela

>On 10 Jul 2014, at 5:25 pm, Shane Stanley 
>wrote:
>
>>I'm trying to convert a cell-based outline view to view-based.
>
>
>Is there some good reason to change to view-based, or are you doing it
>just because it seems to be the "modern" thing? I'd say, if it ain't
>broke...
>
>I've recently gone through a large rewrite of a section of our app to use
>a view-based rather than a cell-based table, because it gives us a better
>user interface, but otherwise, given the pain and usual undocumentedness
>of it (as is usual for a new Cocoa feature), I would not have bothered
>just for fun.





___

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: 32bit vs 64bit and QuickTime/AVFoundation

[João Varela]

I second what Mark said. I did exactly as he suggested. To move to 64-bit
I isolated all QuickTime dependent code in a 32-bit only helper. The main
app, the other helpers and a private framework are now fat binaries and I
migrated all the media code to AVFoundation and related APIs. The 32-bit
only helper is only used to handle legacy media that  AVFoundation cannot
handle.

For reasons we cannot discuss publicly in this list there is help on our
way that will allow us to get rid of this 32-bit only dependence for good.
So do follow what Mark suggested. It is how I did. And if you check how
Finder works with legacy media, you will notice that Apple itself followed
the same strategy.

HTH

Joao
 

>
>To me, this seems like the wrong direction to move. This is sort of like
>saying you want to convert your OS X app to a Classic Mac OS app maintain
>support for some Mac OS API.
>
>I'd go 64-bit only for your main app. I'd leave the 32-bit helper
>separate.
>Isolate your dependence on this component. If you're lucky, it will become
>obsolete and you'll be able to replace it without affecting your app
>significantly. Setup an API layer in your 64-bit app that calls
>AVFoundation, but can optionally call out to your 32-bit helper app.
>
>As a general rule, I try to write more for the future and less for the
>past. That means moving to 64-bit apps as quickly as possible.
>My guess, 32-bit frameworks will go away in the not too distant future,
>see: 68K code & PPC code, Carbon APIs, etc.
>
>Mark
>


___

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: Custom NSView / NSToolbar drawing woes [SOLVED]

[João Varela]

Thank you for your reply. It seems as though when you make a thorough
explanation in writing of what your problem is then the right solution is
found more easily. :) I struggled with this problem for a week and
couldn't, for the life of me, find out what the problem was; that is why I
posted my problem here. However, my description led me to comment out all
the drawing code and then reinsert this code line by line until I found
the line of code that was messing the toolbar up. The offending line of
code was an unbalanced call to store the graphics context. Once removed
the problem went away. I'm somewhat amazed of how such a "small" mistake
could mess up the toolbar drawing so much.


On 30/11/12 05:20, "Graham Cox"  wrote:

>When your custom view is activated, it should be made first responder,
>which is responsible for validating the toolbar - check out
>NSUserInterfaceValidation.
>
>Your -drawRect: does not need to account for the toolbar (but it also
>should take some care not to mess up the graphics environment, though
>that is hard to do - I doubt that's the problem)
>
>--Graham
> 
>On 30/11/2012, at 2:32 PM, João Varela  wrote:
>
>>



___

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

Custom NSView / NSToolbar drawing woes

[João Varela]

I would really appreciate if someone could help me with this mixed bag of
problems I'm having while drawing a custom NSView:

I have a textured window on which I display either an NSOutlineView or this
custom view (both are subviews of the window's content view). This window
has a toolbar with several items, a few of which are enabled / disabled
depending upon if there is a selected item on the NSOutline view. When I
display the NSOutlineView the toolbar draws without a glitch, i.e., all
items of the toolbar are properly drawn. However, when the user switches to
the custom view (I implement this by hiding the NSOutlineView and by
unhiding the custom view when the user hits a segmented control) only the
toolbar items that have changed their enable/disable status by the
validating method draw properly; the items whose enable/disable status has
not changed do not draw at all, although they are still enabled (you can
click on them and their actions are triggered even though they became
invisible by this update bug). This toolbar update bug becomes even worse
when you deactivate the window or the app by switching to another
application. After this context switch the toolbar items are not drawn at
all even if the window is made key and is switched to front. However, when
the user switches back to the NSOutlineView then the toolbar items are drawn
properly again.

The workaround I found that works partially on (Mountain) Lion is to force
the toolbar to update by removing and reinserting the toolbar items,
although that causes a flicker in the toolbar, but the items are drawn and
updated properly when the user switches to this custom view. However, this
"hack" does not work when the user deactivates the app or the window (items
seem to be drawn and then erased a few milliseconds afterwards).

It seems as though the custom drawing code of my view is messing up the
drawing of the toolbar items. But why? Does anyone have a clue of what I am
doing wrong? Does my custom code has to take into account the existence of a
toolbar so that the drawing done in drawRect: does not messes up the drawing
of the toolbar?

I would be extremely grateful If someone could point me to a solution to
this problem or to sample code that deals with drawing a custom view on a
window with a toolbar on it.

TIA

João



___

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: Formatting elapsed time

[João Varela]

>
>
>
>I'm getting stuck trying to format a variable quantity of elapsed time
>for the user's locale. The NSDateFormatter class seems to only provide
>formats for actual times (e.g. "1:30 AM"). What I need to do is turn 1
>hour and 30 minutes into "1:30" for my US English settings, and the
>appropriate string for other locales.

Hi Dennis

If you want to have full control of the output of an NSDateFormatter
object and you do not have to support anything earlier than Snow Leopard,
I strongly recommend that you use -[NSDateFormatter
dateFormatFromTemplate:options:locale:].

See the documentation of this method and check the link to the Unicode
Technical Standard #35. You can then ask for the exact time components you
need to print out.

However, if you need to target earlier OS'es that's doable also but you
need more work to accomplish the same thing, something like:

NSDateFormatter *formatter = [[NSDateFormatter alloc] init];
[formatter setDateStyle:NSDateFormatterNoStyle]; // prevents the date
from being printed out
[formatter setTimeStyle:NSDateFormatterShortStyle]; // it will include
the AM/PM

However, you can look for occurrences of the AM/PM strings of a given
locale by sending -[NSDateFormatter AMSymbol] and -[NSDateFormatter
PMSymbol] and then deleted them from the time string with the appropriate
NSString methods.

[formatter release]; // shouldn't forget to release it when you're done

HTH

João



___

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

Adding login items - who's right? The headers or the guide?

[João Varela]

Hello All

I would like to support the new way of adding login items by adopting the
Services Management framework. As I I would like to support Snow Leopard I
was quite pleased when I read that SMLoginItemSetEnabled function was
available on OS X 10.6.6 and later. You can check it here:

http://developer.apple.com/library/mac/#documentation/MacOSX/Conceptual/BPSy
stemStartup/Chapters/CreatingLoginItems.html

However, when I check the header documentation, it states that the very same
function is available on OS X 10.7 and later. You can check it here:

http://developer.apple.com/library/mac/#documentation/ServiceManagement/Refe
rence/SMLoginItem_header_reference/Reference/reference.html#//apple_ref/doc/
uid/TP40012446

So, who's right? The guide or the headers? Does anyone know? I will file a
bug, anyway, but it would help to know.

TIA

J. Varela 


___

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

How to force a message to a overriding method from within an init method

[João Varela]

Hi all

I am porting most of my C++ code into Objective C and at the moment I  
have this problem:


In C++ to force a constructor to call a overriding method of a  
subclass I used pure virtual functions defined in an abstract (super)  
class.


An example:

class Foo
{
Foo();
virtual read( x, y ) = 0; // pure virtual
};

class Bar : public Foo
{
Bar();

virtual Read( x, y );   // implemented in the subclass
};

// Foo constructor
Foo::Foo()
{
Read( x, y ); // <-- this calls Bar::Read and not Foo::Read
  // because the latter is pure virtual
}

I know that the closest thing to a pure virtual function in Objective  
C is a formal protocol. My question is: can you implement such a  
behavior in objective C with a formal protocol?


Related to this, what method gets called inside the init method of the  
superclass: a) the superclass method? or b) the overriding method if  
there is one?


Although this is not strict Cocoa code, I think this is the best place  
to ask this kind of question. Sorry for the mild "OT-ness" of my  
question.


TIA

JV



___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Class introspection [was Re: Forcing allocation of a subclass]

[João Varela]

No, isKindOfClass check for the superclass.  It returns true if self  
class is myClass or a subclass of myClass.

You should use isMemberOfClass: to got something equivalent.


Yes, you are right. Thanks for pointing it out.



because in the first example we are calling -class: in [self class]  
and on the right we are calling +class: in [MyClass class]. This  
actually surprises me. Even though the +class: method is a NSObject  
class method and -class: is part of the NSObject protocol. How is  
that possible there is no collision between these two methods.  
Isn't that a case of overloading???


It's perfectly legal to have class methods and instance methods with  
the same name.


But there is more:

Methods of the Root Class
All objects, classes and instances alike, need an interface to the  
runtime system. Both class objects and instances should be able to  
introspect about their abilities and to report their place in the  
inheritance hierarchy. It’s the province of the NSObject class to  
provide this interface.


So that NSObject's methods don’t have to be implemented twice—once  
to provide a runtime interface for instances and again to duplicate  
that interface for class objects—class objects are given special  
dispensation to perform instance methods defined in the root class.  
When a class object receives a message that it can’t respond to with  
a class method, the runtime system determines whether there’s a root  
instance method that can respond. The only instance methods that a  
class object can perform are those defined in the root class, and  
only if there’s no class method that can do the job.


For more on this peculiar ability of class objects to perform root  
instance methods, see the NSObject class specification in the  
Foundation framework reference





I think read it once but that was long ago and didn't pay attention to  
is as much. Learning about Obj-C and Cocoa every day.


Thanks for answering.

JV___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Class introspection [was Re: Forcing allocation of a subclass]

[João Varela]

On 2009/01/25, at 18:02, João Varela wrote:




So you mean that

if ( self == [aReceiver class] )

is the same as

if ( [self class] == [aReceiver class] ) ?



Yes it is.


Just a simple snippet to try to help you to understand.

We are ok to say that in a method, self represents the receiver.

Now have a look at this call:

[PDFDocument allocWithZone:nil]

You are ok to say that it is equivalents to:

[[PDFDocument class] allocWithZone:nil]

With the second form, you clearly see here that the receiver is  
[PDFDocument class]. And as self is the receiver,  (self ==  
[PDFDocument class]) is perfectly valid to test class equality.




Hmm...

I think this example does not cover my doubt expressed above. I  
actually now think that both examples I wrote above are wrong or at  
least semantically wrong.


The thing is: 'self' is a pointer to class instance and of course an  
actual parameter for the Obj-C runtime routines.


The example you gave is that you are talking about class methods  
that do not and should not be used with pointers to class instances  
but to receivers that are class names (in your example  
'PDFDocument') or class objects returned by, using your example,  
[PDFDocument class]. As far as I know class objects and class  
instances are two different things.


I think the following comparison is semantically wrong:

if ( self == [MyClass class] )

This statement is comparing a pointer to an object instance (self)  
to a MyClass object (returned by the invocation of +[NSObject class]  
method) and these are two different animals altogether, unless the  
Obj-C runtime deals with this and does the right thing.


My fix is actually semantically wrong too:

if ( [self class] == [myClass class] )

because I am using a receiver (self) that should be a class name  
(but it is a pointer to a class instance) in a class method, whose  
receiver must be a class name or a class object.


Actually the fix should have been:

if ( [self isKindOfClass:[myClass class]] )

because in this case -isKindOfClass is an instance method whose  
receiver is a class instance, not a class object.


If my reasoning is not correct then the Obj-C runtime is rather  
messy, which I think that is not the case.


JV



OK, to answer myself I just checked and the 'class' method can also be  
an instance method of NSObject objects. That explains everything. So



if ( [self class] == [myClass class] )


is as correct as


if ( [self isKindOfClass:[myClass class]] )


because in the first example we are calling -class: in [self class]  
and on the right we are calling +class: in [MyClass class]. This  
actually surprises me. Even though the +class: method is a NSObject  
class method and -class: is part of the NSObject protocol. How is that  
possible there is no collision between these two methods. Isn't that a  
case of overloading???


JV




___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Class introspection [was Re: Forcing allocation of a subclass]

[João Varela]

So you mean that

if ( self == [aReceiver class] )

is the same as

if ( [self class] == [aReceiver class] ) ?



Yes it is.


Just a simple snippet to try to help you to understand.

We are ok to say that in a method, self represents the receiver.

Now have a look at this call:

[PDFDocument allocWithZone:nil]

You are ok to say that it is equivalents to:

[[PDFDocument class] allocWithZone:nil]

With the second form, you clearly see here that the receiver is  
[PDFDocument class]. And as self is the receiver,  (self ==  
[PDFDocument class]) is perfectly valid to test class equality.




Hmm...

I think this example does not cover my doubt expressed above. I  
actually now think that both examples I wrote above are wrong or at  
least semantically wrong.


The thing is: 'self' is a pointer to class instance and of course an  
actual parameter for the Obj-C runtime routines.


The example you gave is that you are talking about class methods that  
do not and should not be used with pointers to class instances but to  
receivers that are class names (in your example 'PDFDocument') or  
class objects returned by, using your example, [PDFDocument class]. As  
far as I know class objects and class instances are two different  
things.


I think the following comparison is semantically wrong:

if ( self == [MyClass class] )

This statement is comparing a pointer to an object instance (self) to  
a MyClass object (returned by the invocation of +[NSObject class]  
method) and these are two different animals altogether, unless the Obj- 
C runtime deals with this and does the right thing.


My fix is actually semantically wrong too:

if ( [self class] == [myClass class] )

because I am using a receiver (self) that should be a class name (but  
it is a pointer to a class instance) in a class method, whose receiver  
must be a class name or a class object.


Actually the fix should have been:

if ( [self isKindOfClass:[myClass class]] )

because in this case -isKindOfClass is an instance method whose  
receiver is a class instance, not a class object.


If my reasoning is not correct then the Obj-C runtime is rather messy,  
which I think that is not the case.


JV





___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Forcing allocation of a subclass

[João Varela]

Hi Jean-Daniel

Yes, when I re-read what I wrote I know it can cause confusion. Of  
course 'self' is a pointer to a class instance, not to a class, but I  
didn't know that 'self' was itself a method. Can you point me to the  
documentation where that is written? Of course "+ [NSObject class]"  
returns a class, not a class name (my bad). I said what I said based  
on listing 2-7 of the page I mentioned, but I now realize there is a  
slight difference with what Antonio has posted.


So you mean that

if ( self == [aReceiver class] )

is the same as

if ( [self class] == [aReceiver class] ) ?

If it is, sorry for the noise, but I would find it weird that a  
pointer to a class instance also had the same end result as invoking  
the NSObject method 'class'. Is it?


JV




On 2009/01/25, at 14:07, Jean-Daniel Dupas wrote:



Le 25 janv. 09 à 14:50, João Varela a écrit :


Olá António

I think your method must be corrected like this:


On 2009/01/25, at 07:28, cocoa-dev-requ...@lists.apple.com wrote:


@implementation PDFDocument (PDFDocument_Alloc)

+ (id)replacementAllocWithZone:(NSZone *)zone
{
if ([self class] == [PDFDocument class]) {
return [ANPDFDocument replacementAllocWithZone:zone];
} else {
return [super allocWithZone:zone];
}
}



Note that you have to invoke the class method of self in order to  
compare it properly. Otherwise you are comparing a pointer to a  
class and the class name, which is the same as comparing apples  
with oranges. For further information read the introspection  
chapter in the Cocoa Fundamentals Guide:




'self' is a Class object as it's a class method, and +[NSObject  
Class] also return a Class (and not a class name).


I don't understand the issues and saw nothing about it in the link  
you provide.



http://developer.apple.com/DOCUMENTATION/Cocoa/Conceptual/CocoaFundamentals/CocoaObjects/chapter_3_section_7.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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Forcing allocation of a subclass

[João Varela]

Olá António

I think your method must be corrected like this:


On 2009/01/25, at 07:28, cocoa-dev-requ...@lists.apple.com wrote:


@implementation PDFDocument (PDFDocument_Alloc)

+ (id)replacementAllocWithZone:(NSZone *)zone
{
if ([self class] == [PDFDocument class]) {
return [ANPDFDocument replacementAllocWithZone:zone];
} else {
return [super allocWithZone:zone];
}
}



Note that you have to invoke the class method of self in order to  
compare it properly. Otherwise you are comparing a pointer to a class  
and the class name, which is the same as comparing apples with  
oranges. For further information read the introspection chapter in the  
Cocoa Fundamentals Guide:


http://developer.apple.com/DOCUMENTATION/Cocoa/Conceptual/CocoaFundamentals/CocoaObjects/chapter_3_section_7.html

HTH

Joao Varela

___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Cocoa-dev Digest, Vol 6, Issue 9

[João Varela]

On 2009/01/06, at 11:21, cocoa-dev-requ...@lists.apple.com wrote:


Date: Tue, 06 Jan 2009 12:36:24 +0530
From: Mahaboob 
Subject: Scheduling an application
To: "cocoa-dev@lists.apple.com" 
Message-ID: 
Content-Type: text/plain;   charset="US-ASCII"

I need to implement Scheduling In my application.For that I designed  
the UI
having date and time fields and ok and cancel button. When I'm  
clicking the
ok button, the opened project should be added into the schedule task  
and it

should work on time.

How can I invoke scheduler to my application? How can I add task to
Scheduler? I didn't find out any document regarding this.

Thanks in advance
mahaboob


I don't know what you mean. If you want schedule your application you  
can use Scheduler for Macintosh. You can download it here:


http://www.macscheduler.net/

JV
___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com