Re: Wanted: new owner for Mac apps
It's funny how when you say "in order of" but omit the direction, people have different assumptions: https://github.com/biohazardffm/grs/network/members On Tue, May 7, 2013 at 1:37 PM, Steven Degutis wrote: > Update: > > The original repo has been deleted. > > Take a look at one of these forks, in order of most-recently-forked > (and therefore most up-to-date): > > https://github.com/biohazardffm/grs > https://github.com/nivekkagicom/grs > https://github.com/cpowers/grs > https://github.com/pariahware/grs > https://github.com/jinie/grs > https://github.com/ddelmonte/grs > https://github.com/shaz/grs > https://github.com/iainx/grs > > Goodness knows how long any of these people will keep their forks > before they each decide to delete their own fork. > > If none of them exist by the time you read this, well then sorry. At > least you'll have learned sooner than later that permanence is an > illusion. > > -Steven > > On Tue, May 7, 2013 at 8:54 AM, Steven Degutis wrote: >> These ones: https://github.com/sdegutis/grs >> >> They're a lovely little set of Mac apps. Most of them are on the App >> Store, and with absolutely no marketing they've been making about $42 >> per month. I'm sure with marketing they'll do much better. >> >> This repo also includes AppGrid, which had a huge cult following for >> the 20 people I've given away free licenses to. They all highly prefer >> it over Divvy/SizeUp/etc. But again, haven't done marketing. >> >> If anyone's interested in taking any or all these apps, just let me >> know. I'll take them off the store and you can put them up. >> >> For the curious, I'm giving them away because >> >> -Steven ___ 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: Saving NSDictionary, Enumeration error
Hmm, yes, its possible saveData method returns an NSDictionary which contains
NSMutableDictionaries if I missed something in my code. Thanks, I'll check it
out.
On May 8, 2013, at 12:13 AM, Jens Alfke wrote:
>
> On May 7, 2013, at 2:32 PM, Tamas Nagy wrote:
>
>> -(NSDictionary)saveData {
>> NSMutableDictionary *dict = [[[NSMutableDictionary alloc] init] autorelease]
>> [dict setObject:...]
>> return NSDictionary dictionaryWithDictionary: [[dict copy] autorelease]];
>
> This does indeed create a new immutable dictionary object to return.
> (Although the last line is doing too much work; -dictionaryWithDictionary:
> does the same thing as -copy.)
>
> However, are you sure the value objects in the dictionary are immutable too?
> Copying is not deep — when you copy a container, the objects stored in the
> container are merely retained, not copied too. So if you use that dictionary
> returned from -saveData on another thread, you're probably using the objects
> stored in it in multithreaded ways.
>
> I don't have your original message handy anymore, but IIRC the backtrace was
> a few levels deep in nested enumerations, which makes me think that the
> mutation exception is happening to a nested dictionary, not the outer one.
>
> —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/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Saving NSDictionary, Enumeration error
Thanks Scott, good point. I'll modify the saveData method to collect the data on the background thread. On May 7, 2013, at 11:39 PM, Scott Ribe wrote: > On May 7, 2013, at 3:32 PM, Tamas Nagy wrote: > >> so does not this made the dictionary already read-only? > > And what happens when dict is modified by another thread during the call to > dict copy? > > You can't solve the problem by layering copy operation on top of copy > operation. You have to synchronize access appropriately. Now, make the copy > is a good idea, so that you only have to synchronize at that point, and after > are free to modify the original while reading the copy. > > -- > Scott Ribe > scott_r...@elevated-dev.com > http://www.elevated-dev.com/ > (303) 722-0567 voice > > > > ___ 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: Wanted: new owner for Mac apps
One more thing: If you end up doing something cool with any of these apps, please let me know. I'm kinda nerdy so I like hearing about that kinda stuff. On Tue, May 7, 2013 at 8:54 AM, Steven Degutis wrote: > These ones: https://github.com/sdegutis/grs > > They're a lovely little set of Mac apps. Most of them are on the App > Store, and with absolutely no marketing they've been making about $42 > per month. I'm sure with marketing they'll do much better. > > This repo also includes AppGrid, which had a huge cult following for > the 20 people I've given away free licenses to. They all highly prefer > it over Divvy/SizeUp/etc. But again, haven't done marketing. > > If anyone's interested in taking any or all these apps, just let me > know. I'll take them off the store and you can put them up. > > For the curious, I'm giving them away because > > -Steven ___ 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
Cocoaheads Lake Forest meets this Wednesday, 5/8, at 7pm
CocoaHeads Lake Forest will be meeting on the second Wednesday of the month. We will be meeting at the Orange County Public Library (El Toro) community room, 24672 Raymond Way, Lake Forest, CA 92630 David Keegan will be talking about Core Graphics. See his post on caching at http://kgn.github.io/blog/2012/03/21/caching-drawing-code/ to get the flavor of his work. Please join us from 7pm to 9pm on Wednesday Bring laptops, code, discussion topics, etc. As always, details can be found on the cocoaheads web site at www.cocoaheads.org ___ 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: Showing numpad key equivs in menu items
On May 8, 2013, at 9:28, Kyle Sluder wrote: >> […] sets the title as an attributed string using an NSTextTableBlock […] > Any reason you're not using a custom view-based NSMenuItem? It might be > easier to get good results that way. A custom view means you have to render everything yourself. That is not only a lot of work as you have to match the OS exactly for the different states a menu item can be in, drawing the selection gradient, and maybe also have to deal with accessibility. But it’s also code that you will need to update if the look of the menus change in the future. No doubt in my mind that the sometimes non-optimal glyph alignment is to prefer over the above. ___ 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: Showing numpad key equivs in menu items
On May 7, 2013, at 7:00 PM, Allan Odgaard wrote: > TextMate’s implementation is here > https://github.com/textmate/textmate/blob/master/Frameworks/OakAppKit/src/NSMenuItem%20Additions.mm#L170-L189 > and sets the title as an attributed string using an NSTextTableBlock to have > the key equivalent string show as the second column. This is fairly > unobtrusive and the only (user visible) shortcoming I have found is that it > doesn’t left/right align the key/modifier glyphs and writes out F1-Fn instead > of using the special glyphs for these keys. Any reason you're not using a custom view-based NSMenuItem? It might be easier to get good results that way. --Kyle Sluder ___ 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: Showing numpad key equivs in menu items
On May 7, 2013, at 5:36 PM, "David M. Cotter" wrote: > Hi, I'm Dave, senior engineer at Adobe Systems. > > We definitely want this functionality, in fact filed a DTS incident for (and > got some help with) custom-drawing menu items, for the express purpose of > drawing an arbitrary string as the "keyboard shortcut" in menus. and i can > tell you the work around was a PITA and is a bit fragile. > > we really want this for the reason originally stated (eg: "Numpad +") but > also to draw any string eg: "tap ⇧") as the "shortcut". > > really the only API we need is something like "SetMenuItemShortcutString()", > and rather than passing in a character, pass in a string, and have the OS > "just take care of it". > > we're wanting this not just for After Effects but also for all "DVA" products > (many of the ones in "Creative Cloud") > > so, please consider that "all of adobe wants this" The correct way to express this request is to file a Radar: http://bugreport.apple.com --Kyle Sluder ___ 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: Showing numpad key equivs in menu items
On May 8, 2013, at 7:36, "David M. Cotter" wrote: > […] filed a DTS incident for (and got some help with) custom-drawing menu > items, for the express purpose of drawing an arbitrary string as the > "keyboard shortcut" in menus. and i can tell you the work around was a PITA > and is a bit fragile. Would you be able to share this code? TextMate also draws a custom string as key equivalent because of Cocoa issues. Carbon worked better but is unavailable when building as 64 bit. TextMate’s implementation is here https://github.com/textmate/textmate/blob/master/Frameworks/OakAppKit/src/NSMenuItem%20Additions.mm#L170-L189 and sets the title as an attributed string using an NSTextTableBlock to have the key equivalent string show as the second column. This is fairly unobtrusive and the only (user visible) shortcoming I have found is that it doesn’t left/right align the key/modifier glyphs and writes out F1-Fn instead of using the special glyphs for these keys. While it (presently) doesn’t do anything special for the numpad modifier, I also see value in rendering the numpad keys. In my case, the user can setup custom key bindings, and expert users do like to bind some stuff only to the numpad keys. I should add that the reason TextMAte uses custom rendering is primarily motivated by not having NSMenuItem handle the key equivalent, as it is unaware of multi-stroke key bindings in progress (dispite being a framework feature) and because it is unable to deal with multiple menu items sharing key equivalent (when the menu items’ action differs). ___ 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: Showing numpad key equivs in menu items
Hi, I'm Dave, senior engineer at Adobe Systems. We definitely want this functionality, in fact filed a DTS incident for (and got some help with) custom-drawing menu items, for the express purpose of drawing an arbitrary string as the "keyboard shortcut" in menus. and i can tell you the work around was a PITA and is a bit fragile. we really want this for the reason originally stated (eg: "Numpad +") but also to draw any string eg: "tap ⇧") as the "shortcut". really the only API we need is something like "SetMenuItemShortcutString()", and rather than passing in a character, pass in a string, and have the OS "just take care of it". we're wanting this not just for After Effects but also for all "DVA" products (many of the ones in "Creative Cloud") so, please consider that "all of adobe wants this" On May 7, 2013, at 5:05 PM, Eric Schlegel wrote: > > On May 7, 2013, at 4:45 PM, gweston wrote: > >>> In that case, I think Steve needs to quit whining that Apple engineers >>> aren't doing his job for him, and implement his own menu drawing for his >>> specialized case. >> >> You need to consider the possibility that Apple decided that not everything >> Carbon was able to do was legitimate to carry forward. That some of it might >> have even been fundamentally detrimental to user experience. It's among the >> most common reasons for behavior to be deprecated. > > In this case, it's really more a lack of demonstrated interest as evidenced > by Radar. I did a little Radar searching and found one Radar requesting > support for numeric keypad command keys. That was from 2002. That bug is > still in Analyze and there's no reason we couldn't do it in a future release > if there's more interest in this feature expressed by developers. But the > fact that it hasn't been done, in this case, has nothing to do with a desire > to deprecate the feature. > > Of course, ideally we would have provided every feature in Cocoa that was in > active use by Carbon developers already. No debate there. But bugs and > features get priority based on demand. > > -eric > ___ 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: Showing numpad key equivs in menu items
On May 7, 2013, at 4:45 PM, gweston wrote: >> In that case, I think Steve needs to quit whining that Apple engineers >> aren't doing his job for him, and implement his own menu drawing for his >> specialized case. > > You need to consider the possibility that Apple decided that not everything > Carbon was able to do was legitimate to carry forward. That some of it might > have even been fundamentally detrimental to user experience. It's among the > most common reasons for behavior to be deprecated. In this case, it's really more a lack of demonstrated interest as evidenced by Radar. I did a little Radar searching and found one Radar requesting support for numeric keypad command keys. That was from 2002. That bug is still in Analyze and there's no reason we couldn't do it in a future release if there's more interest in this feature expressed by developers. But the fact that it hasn't been done, in this case, has nothing to do with a desire to deprecate the feature. Of course, ideally we would have provided every feature in Cocoa that was in active use by Carbon developers already. No debate there. But bugs and features get priority based on demand. -eric ___ 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: Showing numpad key equivs in menu items
That's the problem with legacy. We learn from the past, and realize our mistakes. But sometimes we can't fix them, because users already depend on them. Or rather, we do fix them, and anger lots of people who need it to keep working the old way. Reminds me of http://xkcd.com/1172/ ... "legacy: can't live with it, can't get rid of it". On Tue, May 7, 2013 at 6:45 PM, gweston wrote: > Steve Mills said: > >> Such software has already established the precedent that it needs lots and >> lots of keyboard shortcuts. (Finale is well over 10 years old, IIRC.) Steve >> isn't condemning users to a keyboard shortcut nightmare, he's continuing a >> well-established though specialized UI pattern. On this point I 100% agree >> with Steve's right to continue the tradition without molestation. > > > Finally, somebody that understands. Thanks for explaining it all. > > Don't confuse disagreement with lack of understanding. I understood what you > were asking perfectly. I didn't say you absolutely shouldn't do it. You > might recall that I even made a good faith suggestion for a technique that > might accomplish it. But I also offered a reasoned rationale for why > carrying that forward *might* not be the best use of your efforts. You > reacted with snide hostility to a polite and sincere attempt to help you > make your software as good as it could be. Think about that for a bit. (And > that goes double for Steven who claimed that making such suggestions was the > mark of a "fanboy.") > > > >> In that case, I think Steve needs to quit whining that Apple engineers >> aren't doing his job for him, and implement his own menu drawing for his >> specialized case. > > > It's not that Apple isn't doing my job for me, it's that they're not doing > their own job. Carbon had this ability. They didn't re-add it in Cocoa. > That's what I'm complaining about. Apple killed Carbon and said "use Cocoa! > It's amazing! Convert all your apps now!" That would be a whole lot easier > if Cocoa offered everything that Carbon did. > > You need to consider the possibility that Apple decided that not everything > Carbon was able to do was legitimate to carry forward. That some of it might > have even been fundamentally detrimental to user experience. It's among the > most common reasons for behavior to be deprecated. > > > > Yes, if Apple comes up with better glyphs for numpad keys (and some of the > others while they're at it), then that's all the better. Somewhere I recall > seeing a little numpad icon beside the actual key character. Even that would > be more obvious than a rounded rect around the character. > > You may be surprised to hear that I agree. Remember, I made two arguments. > Not everyone has the keys and the glyph isn't sufficiently descriptive. > Better glyph immediately eliminates the more problematic half of my concern. > You could quite easily do the "little numpad icon" yourself, just like > whatever developer created the one you remember. > > ___ > > 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/sbdegutis%40gmail.com > > This email sent to sbdegu...@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: Showing numpad key equivs in menu items
Steve Mills said: Such software has already established the precedent that it needs lots and lots of keyboard shortcuts. (Finale is well over 10 years old, IIRC.) Steve isn't condemning users to a keyboard shortcut nightmare, he's continuing a well-established though specialized UI pattern. On this point I 100% agree with Steve's right to continue the tradition without molestation. Finally, somebody that understands. Thanks for explaining it all. Don't confuse disagreement with lack of understanding. I understood what you were asking perfectly. I didn't say you absolutely shouldn't do it. You might recall that I even made a good faith suggestion for a technique that might accomplish it. But I also offered a reasoned rationale for why carrying that forward *might* not be the best use of your efforts. You reacted with snide hostility to a polite and sincere attempt to help you make your software as good as it could be. Think about that for a bit. (And that goes double for Steven who claimed that making such suggestions was the mark of a "fanboy.") In that case, I think Steve needs to quit whining that Apple engineers aren't doing his job for him, and implement his own menu drawing for his specialized case. It's not that Apple isn't doing my job for me, it's that they're not doing their own job. Carbon had this ability. They didn't re-add it in Cocoa. That's what I'm complaining about. Apple killed Carbon and said "use Cocoa! It's amazing! Convert all your apps now!" That would be a whole lot easier if Cocoa offered everything that Carbon did. You need to consider the possibility that Apple decided that not everything Carbon was able to do was legitimate to carry forward. That some of it might have even been fundamentally detrimental to user experience. It's among the most common reasons for behavior to be deprecated. Yes, if Apple comes up with better glyphs for numpad keys (and some of the others while they're at it), then that's all the better. Somewhere I recall seeing a little numpad icon beside the actual key character. Even that would be more obvious than a rounded rect around the character. You may be surprised to hear that I agree. Remember, I made two arguments. Not everyone has the keys and the glyph isn't sufficiently descriptive. Better glyph immediately eliminates the more problematic half of my concern. You could quite easily do the "little numpad icon" yourself, just like whatever developer created the one you remember. ___ 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: Does initWithHTML:dataUsingEncoding:documentAttributes: run an event loop?
Thanks for this suggestion. Actually, once identified, I fixed the bug fairly quickly by postponing the task (dispatched a block on the main thread for that). The bug was caused by two successive events arriving in a short timeframe so that the stack looked like that: 0 my callback 1 __CFSocketPerformV0 9 initWithHTML:dataUsingEncoding:documentAttributes: 10 my function 1 11 my function 2 12 my callback 13 __CFSocketPerformV0 --- 23 NSApplicationMain 24 main 25 Start and my callback never was designed to be called a second time before the first call was finished. Dispatching a block to handle my function 1 fixed the issue. However, information about initWithHTML:dataUsingEncoding:documentAttributes: running an event loop could be worth mentioning in the docs… Jean On 8 mai 2013, at 00:52, Ken Thomases wrote: > On May 7, 2013, at 5:37 PM, Jean Suisse wrote: > >> By any chance, could a call to [[NSAttributedString alloc] >> initWithHTML:dataUsingEncoding:documentAttributes:] lead to the event loop >> being run before the call returns? > > Yes, it can. Under the hood, NSAttributedString is using WebKit for HTML > rendering. In part that means that, when invoked from a background thread, > it has to shunt the work to the main thread. But it also means the main > thread may have to run the run loop during the call. It's a nuisance, but > it's necessary since HTML can have references to external resources that need > to be loaded. > > Consider the other method, -[NSAttributedString > initWithHTML:options:documentAttributes:] and its options dictionary, which > can have keys like NSTimeoutDocumentOption and > NSWebResourceLoadDelegateDocumentOption. Those imply a pretty involved > process under the hood. I'm fairly certain that this method is used for the > implementation of the method you're using. > > You may be able to use those options to minimize the use of the run loop, but > probably not eliminate it. > > Regards, > Ken > --- Jean Suisse Institut de Chimie Moléculaire de l’Université de Bourgogne (ICMUB) — UMR 6302 ___ 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: Does initWithHTML:dataUsingEncoding:documentAttributes: run an event loop?
On May 7, 2013, at 5:37 PM, Jean Suisse wrote: > By any chance, could a call to [[NSAttributedString alloc] > initWithHTML:dataUsingEncoding:documentAttributes:] lead to the event loop > being run before the call returns? Yes, it can. Under the hood, NSAttributedString is using WebKit for HTML rendering. In part that means that, when invoked from a background thread, it has to shunt the work to the main thread. But it also means the main thread may have to run the run loop during the call. It's a nuisance, but it's necessary since HTML can have references to external resources that need to be loaded. Consider the other method, -[NSAttributedString initWithHTML:options:documentAttributes:] and its options dictionary, which can have keys like NSTimeoutDocumentOption and NSWebResourceLoadDelegateDocumentOption. Those imply a pretty involved process under the hood. I'm fairly certain that this method is used for the implementation of the method you're using. You may be able to use those options to minimize the use of the run loop, but probably not eliminate it. Regards, Ken ___ 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: Does initWithHTML:dataUsingEncoding:documentAttributes: run an event loop?
Thank you for this quick response. I suspected so. Unfortunately, I just spent five hours straight tracking a random bug – not even remotely related to strings – that seemed to occur when a single thread successively triggered two events handled by a callback tied to an input source on the event loop (took me some time to get that). Of course the callback isn't thread safe… and never was designed to be since tied to the runloop. Until now... Jean On 8 mai 2013, at 00:40, Mike Abdullah wrote: > > On 7 May 2013, at 23:37, Jean Suisse wrote: > >> Dear all, >> >> I am wondering: >> By any chance, could a call to [[NSAttributedString alloc] >> initWithHTML:dataUsingEncoding:documentAttributes:] lead to the event loop >> being run before the call returns? > > I believe so, yes. It's currently implemented using WebKit, which would > generally require spinning the runloop while any asynchronous work is > performed. > --- Jean Suisse Institut de Chimie Moléculaire de l’Université de Bourgogne (ICMUB) — UMR 6302 ___ 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: Does initWithHTML:dataUsingEncoding:documentAttributes: run an event loop?
On 7 May 2013, at 23:37, Jean Suisse wrote: > Dear all, > > I am wondering: > By any chance, could a call to [[NSAttributedString alloc] > initWithHTML:dataUsingEncoding:documentAttributes:] lead to the event loop > being run before the call returns? I believe so, yes. It's currently implemented using WebKit, which would generally require spinning the runloop while any asynchronous work is performed. ___ 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
Does initWithHTML:dataUsingEncoding:documentAttributes: run an event loop?
Dear all, I am wondering: By any chance, could a call to [[NSAttributedString alloc] initWithHTML:dataUsingEncoding:documentAttributes:] lead to the event loop being run before the call returns? Jean --- Jean Suisse Institut de Chimie Moléculaire de l’Université de Bourgogne (ICMUB) — UMR 6302 ___ 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: Saving NSDictionary, Enumeration error
On May 7, 2013, at 2:32 PM, Tamas Nagy wrote:
> -(NSDictionary)saveData {
> NSMutableDictionary *dict = [[[NSMutableDictionary alloc] init] autorelease]
> [dict setObject:...]
> return NSDictionary dictionaryWithDictionary: [[dict copy] autorelease]];
This does indeed create a new immutable dictionary object to return. (Although
the last line is doing too much work; -dictionaryWithDictionary: does the same
thing as -copy.)
However, are you sure the value objects in the dictionary are immutable too?
Copying is not deep — when you copy a container, the objects stored in the
container are merely retained, not copied too. So if you use that dictionary
returned from -saveData on another thread, you're probably using the objects
stored in it in multithreaded ways.
I don't have your original message handy anymore, but IIRC the backtrace was a
few levels deep in nested enumerations, which makes me think that the mutation
exception is happening to a nested dictionary, not the outer one.
—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/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Main Window Disappears when Loaded from Separate NIB File
Steven, Thanks! That did it. Tom Wetmore On May 7, 2013, at 5:57 PM, Steven Degutis wrote: > ARC is on. Retain the window controller. > > On Tue, May 7, 2013 at 4:52 PM, Thomas Wetmore wrote: >> I hope someone can put me straight. I created a vanilla Cocoa App. I deleted >> the window from the MainMenu.xib and created a MainWindow.xib with >> essentially an identical window (no views). >> >> I created a MainWindowController with one overriding method, init, see >> below. In the app delegate's applicationDidFinishLaunching method I create >> the main window controller and attempt to show the main window. If I >> breakpoint just after the [mainController showWindow: nil] method I can see >> the proper user interface with the main menu and main window. However, when >> I let the program run the window immediately disappears. As none of my code >> runs after that point I'm at a bit of a loss discovering what makes the >> window go away. >> >> What am I doing (or not doing) that causes the main window to close or >> become invisible? The code is below. ___ 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: Main Window Disappears when Loaded from Separate NIB File
ARC is on. Retain the window controller.
On Tue, May 7, 2013 at 4:52 PM, Thomas Wetmore wrote:
> I hope someone can put me straight. I created a vanilla Cocoa App. I deleted
> the window from the MainMenu.xib and created a MainWindow.xib with
> essentially an identical window (no views).
>
> I created a MainWindowController with one overriding method, init, see below.
> In the app delegate's applicationDidFinishLaunching method I create the main
> window controller and attempt to show the main window. If I breakpoint just
> after the [mainController showWindow: nil] method I can see the proper user
> interface with the main menu and main window. However, when I let the program
> run the window immediately disappears. As none of my code runs after that
> point I'm at a bit of a loss discovering what makes the window go away.
>
> What am I doing (or not doing) that causes the main window to close or become
> invisible? The code is below.
>
> Thanks,
>
> Tom Wetmore
>
> AppDelegate.h:
> --
> @interface AppDelegate : NSObject
> @end
>
> AppDelegate.m:
> --
> #import "AppDelegate.h"
> #import "MainWindowController.h"
>
> @implementation AppDelegate
>
> - (void) applicationDidFinishLaunching: (NSNotification*) aNotification {
> MainWindowController* mainController = [[MainWindowController alloc]
> init];
> [mainController window]; // force controller to load nib.
> [mainController showWindow: nil]; // show window -- which promptly
> disappears
> }
>
> @end
>
>
> MainWindowController.h:
> ---
> @interface MainWindowController : NSWindowController
> @end
>
> MainWindowController.m:
> ---
> #import "MainWindowController.h"
>
> @implementation MainWindowController
>
> - (id) init { return [super initWithWindowNibName: @"MainWindow"]; }
>
> @end
>
>
> ___
>
> 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/sbdegutis%40gmail.com
>
> This email sent to sbdegu...@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
Main Window Disappears when Loaded from Separate NIB File
I hope someone can put me straight. I created a vanilla Cocoa App. I deleted
the window from the MainMenu.xib and created a MainWindow.xib with essentially
an identical window (no views).
I created a MainWindowController with one overriding method, init, see below.
In the app delegate's applicationDidFinishLaunching method I create the main
window controller and attempt to show the main window. If I breakpoint just
after the [mainController showWindow: nil] method I can see the proper user
interface with the main menu and main window. However, when I let the program
run the window immediately disappears. As none of my code runs after that point
I'm at a bit of a loss discovering what makes the window go away.
What am I doing (or not doing) that causes the main window to close or become
invisible? The code is below.
Thanks,
Tom Wetmore
AppDelegate.h:
--
@interface AppDelegate : NSObject
@end
AppDelegate.m:
--
#import "AppDelegate.h"
#import "MainWindowController.h"
@implementation AppDelegate
- (void) applicationDidFinishLaunching: (NSNotification*) aNotification {
MainWindowController* mainController = [[MainWindowController alloc] init];
[mainController window]; // force controller to load nib.
[mainController showWindow: nil]; // show window -- which promptly
disappears
}
@end
MainWindowController.h:
---
@interface MainWindowController : NSWindowController
@end
MainWindowController.m:
---
#import "MainWindowController.h"
@implementation MainWindowController
- (id) init { return [super initWithWindowNibName: @"MainWindow"]; }
@end
___
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: Saving NSDictionary, Enumeration error
On May 7, 2013, at 3:32 PM, Tamas Nagy wrote: > so does not this made the dictionary already read-only? And what happens when dict is modified by another thread during the call to dict copy? You can't solve the problem by layering copy operation on top of copy operation. You have to synchronize access appropriately. Now, make the copy is a good idea, so that you only have to synchronize at that point, and after are free to modify the original while reading the copy. -- Scott Ribe scott_r...@elevated-dev.com http://www.elevated-dev.com/ (303) 722-0567 voice ___ 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: Saving NSDictionary, Enumeration error
Okay, maybe I misunderstood something, but since I collect the data to an
NSMutableDictionary, then turn it to a non-mutable NSDictionary, like this:
-(NSDictionary)saveData {
NSMutableDictionary *dict = [[[NSMutableDictionary alloc] init] autorelease]
[dict setObject:...]
return NSDictionary dictionaryWithDictionary: [[dict copy] autorelease]];
so does not this made the dictionary already read-only?
On May 7, 2013, at 8:06 PM, Jens Alfke wrote:
>
> On May 7, 2013, at 7:04 AM, Tamas Nagy wrote:
>
>> The data collecting and save happening on the main thread, but the objects
>> providing the data may run on an other - rendering - thread. Maybe its a
>> problem with an object while collecting the save data, and I forgot about
>> copy the value?
>
> Copying the value isn't enough! Foundation collections are not thread-safe —
> you shouldn't access a dictionary (or array or set or string) on one thread
> while modifying it on another. The only safe way to share these objects is
> read-only. (There's a whole document in Apple's doc-set about the
> thread-safety of various Cocoa classes. In general, never assume a class is
> thread-safe unless the docs explicitly say so.)
>
> In this specific crash, the presence of "__NSFastEnumerationMutationHandler"
> in the exception backtrace shows that the enumerator detected that the
> dictionary had been modified during the enumeration, which is illegal (even
> on a single thread.)
>
> —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/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Showing numpad key equivs in menu items
On May 7, 2013, at 14:25:52, Quincey Morris wrote: > 1. The software Steve is dealing with (Finale, I believe he has stated > earlier) has special needs. I've used music notation software for > note-by-note entry in the past, and it's a horrendous chore without some > dedicated keys to assist. You can use a MIDI (piano) keyboard for dedicating > keys to pitch entry, but you still need to use keys on the computer keyboard > for duration (quarter notes, eighth notes, dotted notes, etc) entry. This > used to be what the numeric keypad was dedicated to in Finale, and I guess it > still is. > > It's no use saying that Steve needs to consider whether users *have* a > numeric keypad. For users of music notation software that do a lot of note > entry, it more or less necessary to have the MIDI keyboard (or to suffer a > lot of pain), and it's not unreasonable to predict that such users might also > acquire a numeric keypad, if their Mac doesn't already have one. > > Such software has already established the precedent that it needs lots and > lots of keyboard shortcuts. (Finale is well over 10 years old, IIRC.) Steve > isn't condemning users to a keyboard shortcut nightmare, he's continuing a > well-established though specialized UI pattern. On this point I 100% agree > with Steve's right to continue the tradition without molestation. Finally, somebody that understands. Thanks for explaining it all. > 2. Cocoa doesn't do for shortcut display in menus what Carbon did, and Steve > thinks it should. On this point I 100% disagree with his position, or at > least his moral outrage. It might be that Cocoa doesn't implement what he's > asking for simply because no one asked before, in which case the > functionality may appear in the future. On the other hand, if Apple is > reluctant to sanction *generally* that apps should make a distinction between > numeric keys and numeric keypad keys, I think it's well within Apple's rights > to limit the scope of its own frameworks to match such guidelines. In that > case, I think Steve needs to quit whining that Apple engineers aren't doing > his job for him, and implement his own menu drawing for his specialized case. It's not that Apple isn't doing my job for me, it's that they're not doing their own job. Carbon had this ability. They didn't re-add it in Cocoa. That's what I'm complaining about. Apple killed Carbon and said "use Cocoa! It's amazing! Convert all your apps now!" That would be a whole lot easier if Cocoa offered everything that Carbon did. > 3. It's a question whether boxed numerals displayed in a menu are a > *discoverable* design for presenting numeric keypad shortcuts to the user. On > this issue, I tend to agree with the opinions expressed by Greg and Kyle that > there's really no discoverable approach that will educate users directly from > the menu appearance. (If this were on non-Mac computers, then a > representation like "Num 1" might be an acceptable solution, because non-Mac > numeric keypads have a "Num Lock" key, which gives the user a clue. But that > doesn't help with a Mac numeric keypad.) > > Under the circumstances, I think there's no good solution except directing > users to the documentation or help or tutorial which makes the connection > between the menu appearance and the corresponding keys. (Finale and similar > apps used to come with a quick-reference card that showed this sort of > information. I have no idea if it still does.) > > However, I don't see a problem in having a discussion on this issue. Someone > may come up with a clever idea that even Steve likes. Yes, if Apple comes up with better glyphs for numpad keys (and some of the others while they're at it), then that's all the better. Somewhere I recall seeing a little numpad icon beside the actual key character. Even that would be more obvious than a rounded rect around the character. -- Steve Mills office: 952-818-3871 home: 952-401-6255 cell: 612-803-6157 ___ 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 10, Issue 276
On May 7, 2013, at 11:12 , gweston wrote: > You're relying on a learned behavior that's difficult or impossible to invoke > for an increasing chunk of your potential market. Is that really something > you want to vehemently defend instead of thinking maybe it's *less* > problematic to ask existing users - who may already be unable to use the > keystroke anyway, regardless of how many years your program has been offering > the option - to learn something different? > > Or maybe you just prefer to insult those who can't use your program to its > fullest effect and those who want to help you change that fact. In this thread, there are three separate issues being conflated. I've quoted Greg, as an example of where this conflation leads, but I'm not picking on his response specifically. In fact, it's perfectly rational -- just a bit out of context, IMO. The issues are: 1. The software Steve is dealing with (Finale, I believe he has stated earlier) has special needs. I've used music notation software for note-by-note entry in the past, and it's a horrendous chore without some dedicated keys to assist. You can use a MIDI (piano) keyboard for dedicating keys to pitch entry, but you still need to use keys on the computer keyboard for duration (quarter notes, eighth notes, dotted notes, etc) entry. This used to be what the numeric keypad was dedicated to in Finale, and I guess it still is. It's no use saying that Steve needs to consider whether users *have* a numeric keypad. For users of music notation software that do a lot of note entry, it more or less necessary to have the MIDI keyboard (or to suffer a lot of pain), and it's not unreasonable to predict that such users might also acquire a numeric keypad, if their Mac doesn't already have one. Such software has already established the precedent that it needs lots and lots of keyboard shortcuts. (Finale is well over 10 years old, IIRC.) Steve isn't condemning users to a keyboard shortcut nightmare, he's continuing a well-established though specialized UI pattern. On this point I 100% agree with Steve's right to continue the tradition without molestation. 2. Cocoa doesn't do for shortcut display in menus what Carbon did, and Steve thinks it should. On this point I 100% disagree with his position, or at least his moral outrage. It might be that Cocoa doesn't implement what he's asking for simply because no one asked before, in which case the functionality may appear in the future. On the other hand, if Apple is reluctant to sanction *generally* that apps should make a distinction between numeric keys and numeric keypad keys, I think it's well within Apple's rights to limit the scope of its own frameworks to match such guidelines. In that case, I think Steve needs to quit whining that Apple engineers aren't doing his job for him, and implement his own menu drawing for his specialized case. 3. It's a question whether boxed numerals displayed in a menu are a *discoverable* design for presenting numeric keypad shortcuts to the user. On this issue, I tend to agree with the opinions expressed by Greg and Kyle that there's really no discoverable approach that will educate users directly from the menu appearance. (If this were on non-Mac computers, then a representation like "Num 1" might be an acceptable solution, because non-Mac numeric keypads have a "Num Lock" key, which gives the user a clue. But that doesn't help with a Mac numeric keypad.) Under the circumstances, I think there's no good solution except directing users to the documentation or help or tutorial which makes the connection between the menu appearance and the corresponding keys. (Finale and similar apps used to come with a quick-reference card that showed this sort of information. I have no idea if it still does.) However, I don't see a problem in having a discussion on this issue. Someone may come up with a clever idea that even Steve likes. ___ 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: Wanted: new owner for Mac apps
Update: The original repo has been deleted. Take a look at one of these forks, in order of most-recently-forked (and therefore most up-to-date): https://github.com/biohazardffm/grs https://github.com/nivekkagicom/grs https://github.com/cpowers/grs https://github.com/pariahware/grs https://github.com/jinie/grs https://github.com/ddelmonte/grs https://github.com/shaz/grs https://github.com/iainx/grs Goodness knows how long any of these people will keep their forks before they each decide to delete their own fork. If none of them exist by the time you read this, well then sorry. At least you'll have learned sooner than later that permanence is an illusion. -Steven On Tue, May 7, 2013 at 8:54 AM, Steven Degutis wrote: > These ones: https://github.com/sdegutis/grs > > They're a lovely little set of Mac apps. Most of them are on the App > Store, and with absolutely no marketing they've been making about $42 > per month. I'm sure with marketing they'll do much better. > > This repo also includes AppGrid, which had a huge cult following for > the 20 people I've given away free licenses to. They all highly prefer > it over Divvy/SizeUp/etc. But again, haven't done marketing. > > If anyone's interested in taking any or all these apps, just let me > know. I'll take them off the store and you can put them up. > > For the curious, I'm giving them away because > > -Steven ___ 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 10, Issue 276
Message: 1 Date: Mon, 06 May 2013 22:20:13 -0500 From: Steve Mills To: Cocoa dev Subject: Re: Showing numpad key equivs in menu items Message-ID: <79380da0-718d-4d1f-980b-03ea7e7de...@makemusic.com> Content-Type: text/plain; charset=iso-8859-1 On May 6, 2013, at 16:58:10, gweston wrote: In light of the great opportunity for user confusion - because a little rectangle around the number is hardly a "clear" indicator - and the reality that many users do not have a number pad, I think the solution I'd recommend is to rethink the choice of key equivalents so as to obviate the problem. So a rounded rect around a number is not a clear indictor that it's a different character? People have been able to clearly see the difference between í, ì, and i for hundreds of years, so that's a pretty lame excuse. I've never been confused seeing these numpad glyphs in good ol' Carbon menus. That said, if you insist on going down this path, it might work to include NSNumericPadKeyMask in the key equivalent mask for the item. This only affects the key used to trigger it, not the appearance of the glyph in the menu item. But seriously: Think about how much you want to annoy notebook users first. OK, we'll annoy them by taking away key equivs they've been used to using in our app for the past umpteen years. Why is it that people on these lists prefer giving their opinions instead of technical knowledge? Because we're trying to be helpful and sometimes the best answer to "How do I fight the OS?" is "Maybe you should revisit the perceived need to do so." You *were* asking for help, right? You're absolutely correct that a user would note that there's a difference between a 1 and a 1 in a roundrect showing as the menu equivalent. No argument there at all. The confusion lies in sussing out what the implications of that different glyph are. To extend your example, it's not so much about distinguishing diacritical marks as knowing how they affect pronunciation. I've been a Mac user since 1985, and routinely use and write for several different platforms. I can't say it would occur to me that putting a number in a roundrect means "use the numeric keypad." I *may* have seen it once or twice in the last few decades, but it's not a common idiom. You're relying on a learned behavior that's difficult or impossible to invoke for an increasing chunk of your potential market. Is that really something you want to vehemently defend instead of thinking maybe it's *less* problematic to ask existing users - who may already be unable to use the keystroke anyway, regardless of how many years your program has been offering the option - to learn something different? Or maybe you just prefer to insult those who can't use your program to its fullest effect and those who want to help you change that fact. ___ 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: Saving NSDictionary, Enumeration error
On May 7, 2013, at 7:04 AM, Tamas Nagy wrote: > The data collecting and save happening on the main thread, but the objects > providing the data may run on an other - rendering - thread. Maybe its a > problem with an object while collecting the save data, and I forgot about > copy the value? Copying the value isn't enough! Foundation collections are not thread-safe — you shouldn't access a dictionary (or array or set or string) on one thread while modifying it on another. The only safe way to share these objects is read-only. (There's a whole document in Apple's doc-set about the thread-safety of various Cocoa classes. In general, never assume a class is thread-safe unless the docs explicitly say so.) In this specific crash, the presence of "__NSFastEnumerationMutationHandler" in the exception backtrace shows that the enumerator detected that the dictionary had been modified during the enumeration, which is illegal (even on a single thread.) —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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Wanted: new owner for Mac apps
I really have no idea how many people have claimed what. They're open source and MIT, so if you want to take any, just fork it. On Tue, May 7, 2013 at 11:01 AM, Danny W. Pimienta wrote: > Any of the apps left unclaimed? I'm not at a computer at the moment but would > like to take one. > > Sent from my iPhone > > On May 7, 2013, at 9:54 AM, Steven Degutis wrote: > >> These ones: https://github.com/sdegutis/grs >> >> They're a lovely little set of Mac apps. Most of them are on the App >> Store, and with absolutely no marketing they've been making about $42 >> per month. I'm sure with marketing they'll do much better. >> >> This repo also includes AppGrid, which had a huge cult following for >> the 20 people I've given away free licenses to. They all highly prefer >> it over Divvy/SizeUp/etc. But again, haven't done marketing. >> >> If anyone's interested in taking any or all these apps, just let me >> know. I'll take them off the store and you can put them up. >> >> For the curious, I'm giving them away because >> >> -Steven >> ___ >> >> 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/danny%40tapswipepinch.com >> >> This email sent to da...@tapswipepinch.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: Wanted: new owner for Mac apps
Okay, the apps are removed from the App Store. Have at it. On Tue, May 7, 2013 at 10:42 AM, Steven Degutis wrote: > Also, sorry about the unfinished sentence at the end, it happened because > > On Tue, May 7, 2013 at 8:54 AM, Steven Degutis wrote: >> These ones: https://github.com/sdegutis/grs >> >> They're a lovely little set of Mac apps. Most of them are on the App >> Store, and with absolutely no marketing they've been making about $42 >> per month. I'm sure with marketing they'll do much better. >> >> This repo also includes AppGrid, which had a huge cult following for >> the 20 people I've given away free licenses to. They all highly prefer >> it over Divvy/SizeUp/etc. But again, haven't done marketing. >> >> If anyone's interested in taking any or all these apps, just let me >> know. I'll take them off the store and you can put them up. >> >> For the curious, I'm giving them away because >> >> -Steven ___ 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: Wanted: new owner for Mac apps
Also, sorry about the unfinished sentence at the end, it happened because On Tue, May 7, 2013 at 8:54 AM, Steven Degutis wrote: > These ones: https://github.com/sdegutis/grs > > They're a lovely little set of Mac apps. Most of them are on the App > Store, and with absolutely no marketing they've been making about $42 > per month. I'm sure with marketing they'll do much better. > > This repo also includes AppGrid, which had a huge cult following for > the 20 people I've given away free licenses to. They all highly prefer > it over Divvy/SizeUp/etc. But again, haven't done marketing. > > If anyone's interested in taking any or all these apps, just let me > know. I'll take them off the store and you can put them up. > > For the curious, I'm giving them away because > > -Steven ___ 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: Wanted: new owner for Mac apps
I'll spare your partner the effort. This is the exhaustive list: - http://www.macworld.com/article/1142376/docks2.html - http://www.addictivetips.com/mac-os/get-email-alerts-mac-menu-bar-shortcuts-for-multiple-gmail-accounts/ - https://twitter.com/unclebobmartin/status/309712348044730368 - https://twitter.com/trptcolin/status/309324069134794755 - Plus the App Store reviews that I put in the readme file -Steven On Tue, May 7, 2013 at 10:09 AM, Scott Andrew wrote: > Hmmm. Wonder how long they'll last. Can you do me a bit of research. See if > you can find reviews on these. The read me in the link has their names. See > what people think of em. > > Sent from my iPhone > > On May 7, 2013, at 6:54 AM, Steven Degutis wrote: > >> These ones: https://github.com/sdegutis/grs >> >> They're a lovely little set of Mac apps. Most of them are on the App >> Store, and with absolutely no marketing they've been making about $42 >> per month. I'm sure with marketing they'll do much better. >> >> This repo also includes AppGrid, which had a huge cult following for >> the 20 people I've given away free licenses to. They all highly prefer >> it over Divvy/SizeUp/etc. But again, haven't done marketing. >> >> If anyone's interested in taking any or all these apps, just let me >> know. I'll take them off the store and you can put them up. >> >> For the curious, I'm giving them away because >> >> -Steven >> ___ >> >> 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/scottandrew%40roadrunner.com >> >> This email sent to scottand...@roadrunner.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: Wanted: new owner for Mac apps
Few updates: 1. I'm leaving the repo up for a little while so people can fork it. Anyone who wants to learn how a 5-year Cocoa dev does things, can just browse the source code, and maybe learn a thing or two. 2. I was mistaken on their income, it's more like $20 a month (with no marketing), if that. Sorry for the misinformation. 3. Several people have claimed an app or two, and they plan to put it in the App Store. So if you're one of them, just check to make sure it's not in the App Store first. If there's nothing there with the same name, then you're good to go. 4. Found some stray reviews from a few months ago. Put them in the README for easy finding. 5. Trying to figure out how to take apps down from the Mac App Store, once they're down I'll ping the final pong to this list. -Steven On Tue, May 7, 2013 at 9:32 AM, Steven Degutis wrote: > Also, I've just updated the README to include all sorts of pertinent > information. Please consult it for important details on each app. > > On Tue, May 7, 2013 at 9:08 AM, Steven Degutis wrote: >> Alternatively, anyone and everyone is welcome to fork these apps, or >> do whatever you want with them. I'm releasing all of that repo under >> the MIT license. Give them away for free, sell them, whatever, I don't >> care. >> >> On Tue, May 7, 2013 at 8:54 AM, Steven Degutis wrote: >>> These ones: https://github.com/sdegutis/grs >>> >>> They're a lovely little set of Mac apps. Most of them are on the App >>> Store, and with absolutely no marketing they've been making about $42 >>> per month. I'm sure with marketing they'll do much better. >>> >>> This repo also includes AppGrid, which had a huge cult following for >>> the 20 people I've given away free licenses to. They all highly prefer >>> it over Divvy/SizeUp/etc. But again, haven't done marketing. >>> >>> If anyone's interested in taking any or all these apps, just let me >>> know. I'll take them off the store and you can put them up. >>> >>> For the curious, I'm giving them away because >>> >>> -Steven ___ 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: Wanted: new owner for Mac apps
Hmmm. Wonder how long they'll last. Can you do me a bit of research. See if you can find reviews on these. The read me in the link has their names. See what people think of em. Sent from my iPhone On May 7, 2013, at 6:54 AM, Steven Degutis wrote: > These ones: https://github.com/sdegutis/grs > > They're a lovely little set of Mac apps. Most of them are on the App > Store, and with absolutely no marketing they've been making about $42 > per month. I'm sure with marketing they'll do much better. > > This repo also includes AppGrid, which had a huge cult following for > the 20 people I've given away free licenses to. They all highly prefer > it over Divvy/SizeUp/etc. But again, haven't done marketing. > > If anyone's interested in taking any or all these apps, just let me > know. I'll take them off the store and you can put them up. > > For the curious, I'm giving them away because > > -Steven > ___ > > 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/scottandrew%40roadrunner.com > > This email sent to scottand...@roadrunner.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: Wanted: new owner for Mac apps
Ok. On Tue, May 7, 2013 at 9:38 AM, Tom von Schwerdtner wrote: > On Tue, May 7, 2013 at 9:54 AM, Steven Degutis wrote: >> >> These ones: https://github.com/sdegutis/grs >> >> (...) >> >> For the curious, I'm giving them away because >> > > I think something got cut off here...? > > -Tom ___ 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: Wanted: new owner for Mac apps
On Tue, May 7, 2013 at 9:54 AM, Steven Degutis wrote: > > These ones: https://github.com/sdegutis/grs > > (...) > > For the curious, I'm giving them away because > I think something got cut off here...? -Tom ___ 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: Wanted: new owner for Mac apps
Also, I've just updated the README to include all sorts of pertinent information. Please consult it for important details on each app. On Tue, May 7, 2013 at 9:08 AM, Steven Degutis wrote: > Alternatively, anyone and everyone is welcome to fork these apps, or > do whatever you want with them. I'm releasing all of that repo under > the MIT license. Give them away for free, sell them, whatever, I don't > care. > > On Tue, May 7, 2013 at 8:54 AM, Steven Degutis wrote: >> These ones: https://github.com/sdegutis/grs >> >> They're a lovely little set of Mac apps. Most of them are on the App >> Store, and with absolutely no marketing they've been making about $42 >> per month. I'm sure with marketing they'll do much better. >> >> This repo also includes AppGrid, which had a huge cult following for >> the 20 people I've given away free licenses to. They all highly prefer >> it over Divvy/SizeUp/etc. But again, haven't done marketing. >> >> If anyone's interested in taking any or all these apps, just let me >> know. I'll take them off the store and you can put them up. >> >> For the curious, I'm giving them away because >> >> -Steven ___ 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: Wanted: new owner for Mac apps
Alternatively, anyone and everyone is welcome to fork these apps, or do whatever you want with them. I'm releasing all of that repo under the MIT license. Give them away for free, sell them, whatever, I don't care. On Tue, May 7, 2013 at 8:54 AM, Steven Degutis wrote: > These ones: https://github.com/sdegutis/grs > > They're a lovely little set of Mac apps. Most of them are on the App > Store, and with absolutely no marketing they've been making about $42 > per month. I'm sure with marketing they'll do much better. > > This repo also includes AppGrid, which had a huge cult following for > the 20 people I've given away free licenses to. They all highly prefer > it over Divvy/SizeUp/etc. But again, haven't done marketing. > > If anyone's interested in taking any or all these apps, just let me > know. I'll take them off the store and you can put them up. > > For the curious, I'm giving them away because > > -Steven ___ 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: Saving NSDictionary, Enumeration error
The data collecting and save happening on the main thread, but the objects providing the data may run on an other - rendering - thread. Maybe its a problem with an object while collecting the save data, and I forgot about copy the value? So, in other words, I should always do this: [tempdict setObject:[[something copy] autorelease] forKey:…] but I forgot it somewhere and I doing [tempdict setObject:something forKey:…]. Could this be a problem? On May 7, 2013, at 3:45 PM, Igor Elland wrote: > Cab you provide a bit more detail? Is everything happening on to main thread? > > On May 7, 2013, at 14:39, Tamas Nagy wrote: > >> Hi, >> >> one of my users recently got an error when trying to save. My application is >> not document based, and I'm collecting the data to NSDictionaries, then save >> it with writeToFile: method. I never can reproduce the issue, so hard to >> find what is the problem. >> >> I'm collection the data with methods like: >> >> NSMutableDictionary *tempdict = [[[NSMutableDictionary alloc] init] >> autorelease]; >> >> [tempdict setObject:... forKey:...]; >> [tempdict setObject:... forKey:...]; >> [tempdict setObject:... forKey:...]; >> . >> . >> . >> return [NSDictionary dictionaryWithDictionary:tempdict]; >> >> and putting those NSDictionaries to realSaveDict, then save: >> [realSaveDict writeToFile:[sPanel filename] atomically:YES] >> >> Any ideas guys what's going wrong? >> >> Thanks, >> >> Tamas >> >> May 3, 2013 2:44:54 PM: *** Collection <__NSDictionaryM: 0x1c37a300> was >> mutated while being enumerated. >> May 3, 2013 2:44:54 PM: ( >> 0 CoreFoundation 0x98912e9b __raiseError + 219 >> 1 libobjc.A.dylib 0x970b352e objc_exception_throw + >> 230 >> 2 CoreFoundation 0x98912a9a >> __NSFastEnumerationMutationHandler + 282 >> 3 CoreFoundation 0x9884afc9 >> -[__NSFastEnumerationEnumerator nextObject] + 457 >> 4 CoreFoundation 0x98884f4c -[NSDictionary >> countByEnumeratingWithState:objects:count:] + 396 >> 5 CoreFoundation 0x98884c68 -[NSDictionary >> __apply:context:] + 104 >> 6 CoreFoundation 0x9880904a >> CFDictionaryApplyFunction + 106 >> 7 CoreFoundation 0x98809dbe >> __CFPropertyListIsValidAux + 366 >> 8 CoreFoundation 0x9882aac1 >> __CFPropertyListIsDictPlistAux + 257 >> 9 CoreFoundation 0x98884cd5 -[NSDictionary >> __apply:context:] + 213 >> 10 CoreFoundation 0x9880904a >> CFDictionaryApplyFunction + 106 >> 11 CoreFoundation 0x98809dbe >> __CFPropertyListIsValidAux + 366 >> 12 CoreFoundation 0x9882aac1 >> __CFPropertyListIsDictPlistAux + 257 >> 13 CoreFoundation 0x98884cd5 -[NSDictionary >> __apply:context:] + 213 >> 14 CoreFoundation 0x9880904a >> CFDictionaryApplyFunction + 106 >> 15 CoreFoundation 0x98809dbe >> __CFPropertyListIsValidAux + 366 >> 16 CoreFoundation 0x9882aac1 >> __CFPropertyListIsDictPlistAux + 257 >> 17 CoreFoundation 0x98884cd5 -[NSDictionary >> __apply:context:] + 213 >> 18 CoreFoundation 0x9880904a >> CFDictionaryApplyFunction + 106 >> 19 CoreFoundation 0x98809dbe >> __CFPropertyListIsValidAux + 366 >> 20 CoreFoundation 0x9882aac1 >> __CFPropertyListIsDictPlistAux + 257 >> 21 CoreFoundation 0x98884cd5 -[NSDictionary >> __apply:context:] + 213 >> 22 CoreFoundation 0x9880904a >> CFDictionaryApplyFunction + 106 >> 23 CoreFoundation 0x98809dbe >> __CFPropertyListIsValidAux + 366 >> 24 CoreFoundation 0x9883c445 CFPropertyListIsValid + >> 117 >> 25 CoreFoundation 0x9883c2dd >> _CFPropertyListCreateXMLData + 77 >> 26 CoreFoundation 0x9883c280 >> CFPropertyListCreateXMLData + 32 >> 27 Foundation 0x98ca14ae >> -[NSDictionary(NSDictionary) writeToURL:atomically:] + 242 >> >> ___ >> >> 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/igor.elland%40me.com >> >> This email sent to igor.ell...@me.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
Wanted: new owner for Mac apps
These ones: https://github.com/sdegutis/grs They're a lovely little set of Mac apps. Most of them are on the App Store, and with absolutely no marketing they've been making about $42 per month. I'm sure with marketing they'll do much better. This repo also includes AppGrid, which had a huge cult following for the 20 people I've given away free licenses to. They all highly prefer it over Divvy/SizeUp/etc. But again, haven't done marketing. If anyone's interested in taking any or all these apps, just let me know. I'll take them off the store and you can put them up. For the curious, I'm giving them away because -Steven ___ 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: Saving NSDictionary, Enumeration error
Cab you provide a bit more detail? Is everything happening on to main thread? On May 7, 2013, at 14:39, Tamas Nagy wrote: > Hi, > > one of my users recently got an error when trying to save. My application is > not document based, and I'm collecting the data to NSDictionaries, then save > it with writeToFile: method. I never can reproduce the issue, so hard to find > what is the problem. > > I'm collection the data with methods like: > >NSMutableDictionary *tempdict = [[[NSMutableDictionary alloc] init] > autorelease]; > >[tempdict setObject:... forKey:...]; >[tempdict setObject:... forKey:...]; >[tempdict setObject:... forKey:...]; >. >. >. >return [NSDictionary dictionaryWithDictionary:tempdict]; > > and putting those NSDictionaries to realSaveDict, then save: > [realSaveDict writeToFile:[sPanel filename] atomically:YES] > > Any ideas guys what's going wrong? > > Thanks, > > Tamas > > May 3, 2013 2:44:54 PM: *** Collection <__NSDictionaryM: 0x1c37a300> was > mutated while being enumerated. > May 3, 2013 2:44:54 PM: ( >0 CoreFoundation 0x98912e9b __raiseError + 219 >1 libobjc.A.dylib 0x970b352e objc_exception_throw + > 230 >2 CoreFoundation 0x98912a9a > __NSFastEnumerationMutationHandler + 282 >3 CoreFoundation 0x9884afc9 > -[__NSFastEnumerationEnumerator nextObject] + 457 >4 CoreFoundation 0x98884f4c -[NSDictionary > countByEnumeratingWithState:objects:count:] + 396 >5 CoreFoundation 0x98884c68 -[NSDictionary > __apply:context:] + 104 >6 CoreFoundation 0x9880904a > CFDictionaryApplyFunction + 106 >7 CoreFoundation 0x98809dbe > __CFPropertyListIsValidAux + 366 >8 CoreFoundation 0x9882aac1 > __CFPropertyListIsDictPlistAux + 257 >9 CoreFoundation 0x98884cd5 -[NSDictionary > __apply:context:] + 213 >10 CoreFoundation 0x9880904a > CFDictionaryApplyFunction + 106 >11 CoreFoundation 0x98809dbe > __CFPropertyListIsValidAux + 366 >12 CoreFoundation 0x9882aac1 > __CFPropertyListIsDictPlistAux + 257 >13 CoreFoundation 0x98884cd5 -[NSDictionary > __apply:context:] + 213 >14 CoreFoundation 0x9880904a > CFDictionaryApplyFunction + 106 >15 CoreFoundation 0x98809dbe > __CFPropertyListIsValidAux + 366 >16 CoreFoundation 0x9882aac1 > __CFPropertyListIsDictPlistAux + 257 >17 CoreFoundation 0x98884cd5 -[NSDictionary > __apply:context:] + 213 >18 CoreFoundation 0x9880904a > CFDictionaryApplyFunction + 106 >19 CoreFoundation 0x98809dbe > __CFPropertyListIsValidAux + 366 >20 CoreFoundation 0x9882aac1 > __CFPropertyListIsDictPlistAux + 257 >21 CoreFoundation 0x98884cd5 -[NSDictionary > __apply:context:] + 213 >22 CoreFoundation 0x9880904a > CFDictionaryApplyFunction + 106 >23 CoreFoundation 0x98809dbe > __CFPropertyListIsValidAux + 366 >24 CoreFoundation 0x9883c445 CFPropertyListIsValid + > 117 >25 CoreFoundation 0x9883c2dd > _CFPropertyListCreateXMLData + 77 >26 CoreFoundation 0x9883c280 > CFPropertyListCreateXMLData + 32 >27 Foundation 0x98ca14ae > -[NSDictionary(NSDictionary) writeToURL:atomically:] + 242 > > ___ > > 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/igor.elland%40me.com > > This email sent to igor.ell...@me.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: Showing numpad key equivs in menu items
On May 7, 2013, at 02:04:09, Kyle Sluder wrote: > This is a terrible argument, and you know it not to be true. If you showed > those three glyphs to a non-Western person, would they be likely to discern a > difference? Depending on the arguments I pass, even my _computer_ won’t > distinguish between them. Then you have a pretty dumb computer. > That's because at some point you learned their meaning. There's nothing > intuitive about putting a number in a round rect to indicate anything is > different about that number, much less _what_ specifically is different. For > the record, I believe I’ve only encountered this convention in Adobe apps. And at some point you learned that a crooked angled line with a dash at the top-right meant "option key", even though there have been very few (if any) keyboards manufactured with that symbol printed on the option key. Same with ^ and the control key. That doesn't mean it's wrong to use those symbols. > If this were a more practiced convention on OS X, then I'd be quite more > disposed towards your argument. But so-called “real” Macs have been shipping > without numpads for quite some time, and developers in general have no reason > to assume users are familiar with numpad-variant shortcut indicators. And most "real" users buy extended keyboards. I've never seen someone who works with spreadsheets NOT have a keyboard with a numpad, or people in the film or music industries who need all the keys they can get. > I agree with you wholeheartedly that this right here is a bug. If Apple > decides to fix it (not likely, I’d guess) then they might pick a more > meaningful convention than enclosing the numerals in round rects. If they do, that's just great, but for the past however many years, many users are familiar with the current scheme. > Moreover, we don't know your constraints. We don't share your motivations. We > are not mechanical Turks and do not live to answer within parameters. Exactly, you don't know our constraints or our users. This is a technical list, and I expect technical answers, not opinions that waste everyone's time. -- Steve Mills office: 952-818-3871 home: 952-401-6255 cell: 612-803-6157 ___ 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
Saving NSDictionary, Enumeration error
Hi, one of my users recently got an error when trying to save. My application is not document based, and I'm collecting the data to NSDictionaries, then save it with writeToFile: method. I never can reproduce the issue, so hard to find what is the problem. I'm collection the data with methods like: NSMutableDictionary *tempdict = [[[NSMutableDictionary alloc] init] autorelease]; [tempdict setObject:... forKey:...]; [tempdict setObject:... forKey:...]; [tempdict setObject:... forKey:...]; . . . return [NSDictionary dictionaryWithDictionary:tempdict]; and putting those NSDictionaries to realSaveDict, then save: [realSaveDict writeToFile:[sPanel filename] atomically:YES] Any ideas guys what's going wrong? Thanks, Tamas May 3, 2013 2:44:54 PM: *** Collection <__NSDictionaryM: 0x1c37a300> was mutated while being enumerated. May 3, 2013 2:44:54 PM: ( 0 CoreFoundation 0x98912e9b __raiseError + 219 1 libobjc.A.dylib 0x970b352e objc_exception_throw + 230 2 CoreFoundation 0x98912a9a __NSFastEnumerationMutationHandler + 282 3 CoreFoundation 0x9884afc9 -[__NSFastEnumerationEnumerator nextObject] + 457 4 CoreFoundation 0x98884f4c -[NSDictionary countByEnumeratingWithState:objects:count:] + 396 5 CoreFoundation 0x98884c68 -[NSDictionary __apply:context:] + 104 6 CoreFoundation 0x9880904a CFDictionaryApplyFunction + 106 7 CoreFoundation 0x98809dbe __CFPropertyListIsValidAux + 366 8 CoreFoundation 0x9882aac1 __CFPropertyListIsDictPlistAux + 257 9 CoreFoundation 0x98884cd5 -[NSDictionary __apply:context:] + 213 10 CoreFoundation 0x9880904a CFDictionaryApplyFunction + 106 11 CoreFoundation 0x98809dbe __CFPropertyListIsValidAux + 366 12 CoreFoundation 0x9882aac1 __CFPropertyListIsDictPlistAux + 257 13 CoreFoundation 0x98884cd5 -[NSDictionary __apply:context:] + 213 14 CoreFoundation 0x9880904a CFDictionaryApplyFunction + 106 15 CoreFoundation 0x98809dbe __CFPropertyListIsValidAux + 366 16 CoreFoundation 0x9882aac1 __CFPropertyListIsDictPlistAux + 257 17 CoreFoundation 0x98884cd5 -[NSDictionary __apply:context:] + 213 18 CoreFoundation 0x9880904a CFDictionaryApplyFunction + 106 19 CoreFoundation 0x98809dbe __CFPropertyListIsValidAux + 366 20 CoreFoundation 0x9882aac1 __CFPropertyListIsDictPlistAux + 257 21 CoreFoundation 0x98884cd5 -[NSDictionary __apply:context:] + 213 22 CoreFoundation 0x9880904a CFDictionaryApplyFunction + 106 23 CoreFoundation 0x98809dbe __CFPropertyListIsValidAux + 366 24 CoreFoundation 0x9883c445 CFPropertyListIsValid + 117 25 CoreFoundation 0x9883c2dd _CFPropertyListCreateXMLData + 77 26 CoreFoundation 0x9883c280 CFPropertyListCreateXMLData + 32 27 Foundation 0x98ca14ae -[NSDictionary(NSDictionary) writeToURL:atomically:] + 242 ___ 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: Need advice: Object ownership and threading issue, causing a rare crash.
On May 6, 2013, at 5:26 PM, Motti Shneor wrote: > Hello Ken, and so-many-thanks for the information. You're welcome. More below… > On 4 במאי 2013, at 07:24, Ken Thomases wrote: > >> Honestly, I doubt that -dealloc is reentered. I suspect you've misdiagnosed >> what is happening or, perhaps, there's some other severe problem such as >> heap corruption that's leading to that. It *definitely* won't happen merely >> because two threads are racing in -release for the same object (assuming >> they are both entitled to release the object because they each have an >> ownership stake). > > Well, the crash-log provides a call-stack which quite clearly shows the > "dealloc" re-enrered. Now I'm really puzzled, because if NSThread protected > me against premature deallocation on its own, How on earth could I reach the > "dealloc" before the thread was done? Let me clarify. I doubt that -dealloc is reentered *for a given instance*. It's very possible that one instance of your class held (perhaps through a chain of other objects) the last strong reference to another instance of your class. So, during its -dealloc, it released that reference, causing the other instance to also deallocate. That would be consistent with the stack trace you describe. There would be two frames of -[YourClass dealloc] listed, but they would be for different instances. Now, that shouldn't cause a crash in and of itself. What does your -dealloc do? Also, have you taken the easy steps to verify your memory management? Use the static analyzer (Build and Analyze) and clean up any problems it identifies (or understand them to the point where you're sure they're false positives). Run your app under the Zombies instrument. Regards, Ken ___ 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: Showing numpad key equivs in menu items
On May 6, 2013, at 8:20 PM, Steve Mills wrote: > On May 6, 2013, at 16:58:10, gweston wrote: > >> In light of the great opportunity for user confusion - because a little >> rectangle around the number is hardly a "clear" indicator - and the reality >> that many users do not have a number pad, I think the solution I'd recommend >> is to rethink the choice of key equivalents so as to obviate the problem. > > So a rounded rect around a number is not a clear indictor that it's a > different character? Not really, no. I would imagine this would be particularly unclear for many East Asian users, who seem to enjoy putting western numerals in circles or other shapes for reasons to which I am not privy. > People have been able to clearly see the difference between í, ì, and i for > hundreds of years This is a terrible argument, and you know it not to be true. If you showed those three glyphs to a non-Western person, would they be likely to discern a difference? Depending on the arguments I pass, even my _computer_ won’t distinguish between them. By the way, you forgot to include “dotless i" in your example of clearly-differentiable glyphs. But that’s probably because you don't speak Turkish and thus wouldn't recognize a difference between it and a dotted i. But you might complain if hitting the wrong one didn't activate the menu item you expected. > , so that's a pretty lame excuse. I've never been confused seeing these > numpad glyphs in good ol' Carbon menus. That's because at some point you learned their meaning. There's nothing intuitive about putting a number in a round rect to indicate anything is different about that number, much less _what_ specifically is different. For the record, I believe I’ve only encountered this convention in Adobe apps. If this were a more practiced convention on OS X, then I'd be quite more disposed towards your argument. But so-called “real” Macs have been shipping without numpads for quite some time, and developers in general have no reason to assume users are familiar with numpad-variant shortcut indicators. > >> That said, if you insist on going down this path, it might work to include >> NSNumericPadKeyMask in the key equivalent mask for the item. > > This only affects the key used to trigger it, not the appearance of the glyph > in the menu item. I agree with you wholeheartedly that this right here is a bug. If Apple decides to fix it (not likely, I’d guess) then they might pick a more meaningful convention than enclosing the numerals in round rects. > >> But seriously: Think about how much you want to annoy notebook users first. > > OK, we'll annoy them by taking away key equivs they've been used to using in > our app for the past umpteen years. On the one hand, it sucks to break habit. On the other hand, the vast majority of Apple computers sold nowadays do not have numpads. This includes desktops. Maybe you ought to consider adopting shortcuts friendlier to such systems? Perhaps you can silently maintain the old ones for backwards compatibility using an app-local NSEvent monitor. > > Why is it that people on these lists prefer giving their opinions instead of > technical knowledge? There was a specific technical suggestion offered to you, to which you replied and which is included inline in this email. You seem to be agonizing because it did not result in the effect you desired. As for why the replies to this list do not consist solely of technical suggestions tailor-made to the requestor’s rubric: how many times have you agonized over a solution only to realize you're tackling the wrong problem? Moreover, we don't know your constraints. We don't share your motivations. We are not mechanical Turks and do not live to answer within parameters. --Kyle Sluder ___ 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
