Re: LSSharedFileList API bug(s) -- workaround?
The three applications I've written which use my Cocoa wrapper are normal applications with the exception that they have LSUIElement set to YES, and means they live in the menu bar as NSStatusItems, not in the Dock. Therefore, as far as I understand from reading http://developer.apple.com/technotes/tn2005/tn2083.html, Login Items is the appropriate solution here, not a launchd service. Although it is worth taking into consideration. On Mon, Oct 27, 2008 at 4:00 PM, Jerry Krinock <[EMAIL PROTECTED]> wrote: > > On 2008 Oct, 27, at 13:24, Steven Degutis wrote: > > I've been writing my own wrapper for the LSSharedFileList API to be able >> to >> stick it in my Cocoa app. However I've found a few bugs. >> One isn't that big of a deal, but I've filed a rdar for it anyway, and >> it's >> that you can't actually set the Hide property. It just fails in odd ways. >> > > Actually, when I wrote ^my^ wrapper for LSSharedFileList, I found that Hide > fails consistently. You might want to reference the bug I filed, 5901742, > 2008-04-30. Still open :( > > The other one, however, is pretty major... >> > > Another good reason to not use Login Items. > > If anyone has any ideas for a workaround or solution, please let me know! >> > > Yes. Instead of using a Login Item, have launchd launch whatever you want > launched at login, and keep it running. This way, your user only has one UI > to deal with adding/removing your login item: Your UI. > > I've come to the conclusion that Login Items is for users who have a > preference to see their Mail.app, iCal, coffee-maker, or whatever launched > at login. For an application to place itself or its Helper in Login Items > is redundant and confusing to the user. And, of course, redundant and > confusing concepts lead one to write lots of buggy code. > > http://developer.apple.com/macosx/launchd.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/steven.degutis%40gmail.com > > This email sent to [EMAIL PROTECTED] > -- Steven Degutis ___ 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 [EMAIL PROTECTED]
Re: LSSharedFileList API bug(s) -- workaround?
On 2008 Oct, 27, at 13:24, Steven Degutis wrote: I've been writing my own wrapper for the LSSharedFileList API to be able to stick it in my Cocoa app. However I've found a few bugs. One isn't that big of a deal, but I've filed a rdar for it anyway, and it's that you can't actually set the Hide property. It just fails in odd ways. Actually, when I wrote ^my^ wrapper for LSSharedFileList, I found that Hide fails consistently. You might want to reference the bug I filed, 5901742, 2008-04-30. Still open :( The other one, however, is pretty major... Another good reason to not use Login Items. If anyone has any ideas for a workaround or solution, please let me know! Yes. Instead of using a Login Item, have launchd launch whatever you want launched at login, and keep it running. This way, your user only has one UI to deal with adding/removing your login item: Your UI. I've come to the conclusion that Login Items is for users who have a preference to see their Mail.app, iCal, coffee-maker, or whatever launched at login. For an application to place itself or its Helper in Login Items is redundant and confusing to the user. And, of course, redundant and confusing concepts lead one to write lots of buggy code. http://developer.apple.com/macosx/launchd.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 [EMAIL PROTECTED]
LSSharedFileList API bug(s) -- workaround?
I've been writing my own wrapper for the LSSharedFileList API to be able to stick it in my Cocoa app. However I've found a few bugs. One isn't that big of a deal, but I've filed a rdar for it anyway, and it's that you can't actually set the Hide property. It just fails in odd ways. The other one, however, is pretty major: When you are running a 32/64-bit Universal binary on your Release target, calling LSSharedFileListItemResolve() at all will trigger your callback. If you have this being called inside your callback to determine if your own application's path is one of the Login Items (for example to update an NSMenuitem's state), this will trigger an infinite loop! This has made my applications' real-memory usage go up over a GB, slowing my Mac to a crawl, for no good reason! Also, the seed value given by each update is unique, so unfortunately we can't just ignore it if it matches the previous seed value. One workaround I've tried is to use LSSharedFileListRemoveObserver() *before* using LSSharedFileListItemResolve(), and then afterwards, add myself back as an observer. This completely fails to do anything useful. As another shot, I tried to add self as an observer again in a method called after a certain delay, for example 2.0 seconds. Again, it doesn't solve the issue. Then out of desperation, I tried to CFRelease(sharedFileList) right after removing myself as an observer, and then create it again using LSSharedFileListCreate() right before calling LSSharedFileListItemResolve(). This availed me nothing. I've not filed a bug on this yet because I've been busy doing as much testing as I can to find a better solution, lest I have to resort to using the old, ugly ways of hacking this Login Item problem. If anyone has any ideas for a workaround or solution, please let me know! Steven Degutis http://www.degutis.org/ http://www.thoughtfultree.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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
