Identifying monitor configurations
I'd like for my app to be able to restore the location of its windows based on the display configuration. For example, if you have a MacBook Pro and a Cinema Display to its left, and you put a window on one of those displays, I want to remember that window's geometry for that config. If you then remove the external monitor, the window will move (if necessary) to the remaining display. If the user moves it again, I want to remember that position for that display config. If the user then reattaches the external monitor, I want to be able to recall the old geometry and restore the window to that location. If they add a different external display, that's a new configuration. One way to do this is to iterate the displays using CGGetActiveDisplayList(), use CGDisplayVendorNumber() for each, sort them, build a string, and use that as a key into a dictionary of geometries. Maybe add the screen geometry to the string, in case vendor IDs overlap or are unknown. But I want to check to see if there's not already a better solution in place, or just a better idea. Thanks! -- Rick ___ 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: NSButton in NSToolbarItem does not use "small size"
Sorry for digging this up again. As I'm no experienced developer I'm somewhat lost how to address the situation. Is there a way to compare an NSToolbarItem with a NSButton created in IB to a one created programmatically? If so, this might shine some light as to what is really going on. While trying to figure out what happens I wrapped NSToolbarItem in a Proxy object to get all it's calls but it seems that I cannot get a hold of any resizing that is sent to the button's cell Any help would be appreciated. --Michael On 25.02.2013, at 00:05, Kyle Sluder wrote: > Perhaps I'm not understanding your post, but > > On Sun, Feb 24, 2013, at 02:53 PM, Keary Suska wrote: >> On Feb 24, 2013, at 1:11 PM, Michael Starke wrote: >> I suspect the issue is that NSButton does not have built-in semantics for >> control size. > > NSButton does indeed have built-in semantics for controlSize. > >> In fact, none of the cells in question are documented to >> respond to -setControlSize is the way you are seeing, but apparently some >> do. > > All NSCell instances respond to -setControlSize:. > >> If you consider that a button of any control size can actually be of >> any size, how would the cell know how to resize itself, other than to >> just change its font? And if it has an image, how would that work? > > As per the documentation, setting the controlSize of a cell does not > change its font. After the cell gets -setControlSize:, someone is > responsible for calling -sizeToFit: on the view containing that cell. > > --Kyle Sluder ___m i c h a e l s t a r k e geschäftsführer HicknHack Software GmbH www.hicknhack-software.com ___k o n t a k t +49 (170) 3686136 cont...@hicknhack.com ___H i c k n H a c k S o f t w a r e G m b H geschäftsführer - maik lathan | andreas reischuck | michael starke bayreuther straße 32 01187 dresden amtsgericht dresden HRB 30351 sitz - dresden ___ 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: Programmatic Core Data Migration
On Feb 25, 2013, at 6:28 PM, Michael Swan wrote: > Tom, > I've never built a data model programmatically but I'm guessing it works like > building a nib in code where it happens on each launch. This means that when > you move to version 2 of your data model you will have to build model 1 and 2 > on each launch. If this is still just for you to use at the moment you can > drop older versions once you know you have moved all of you stores up to the > newest version. The data model from any release versions will need to stick > around forever (or at least a good long time). [slapping head] I see. *I* don't need the old versions because once my model is migrated the program will never have to deal with an older version of the model again. As long as the program has never been released, it will never have to deal with older object models. But once its released, the older model from version 1 is going to be a permanent fixture in order for users of version 1 to be able to migrate to a newer object model. > Out of curiosity, what is the reasoning behind building the model in code > rather than with the data model editor? The data editor is pretty stable from > what I have seen and is super easy to use. If it is because of a visual > impairment perhaps you could write your own app that allows you to specify > the model's structure in text and converts it to a model file that can be > saved as though Xcode had built it. That would eliminate the overhead of > building the model at every launch and be easier to do with VoiceOver. I should have used the data model editor. But the truth is that when I started this thing I was a rank beginner. I don't know when you get to drop that title but I'm guessing I probably still deserve it. I'm coming from a background in C and I was (and am) much more comfortable working in code. I was trying to learn objective C at the same time I was trying to learn to use XCode and IB and I didn't understand what was going on. The Core Data Utility Tutorial in the docs that demonstrated the use of core data without the interface looked straight forward and I thought I understood it. On the other hand, the data model editor looked like the kind of black box that would save a lot of time but which I would regret using if I ever wanted to do anything unusual. I was wrong, of course. Things are fine as they are but if I had it to do over, I'd use the editor. Thanks for all the help. That was a great response and I really appreciate the time. Tom S. ___ 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: NSButton in NSToolbarItem does not use "small size"
On Feb 26, 2013, at 8:28 AM, Michael Starke wrote: > Sorry for digging this up again. > > As I'm no experienced developer I'm somewhat lost how to address the > situation. > Is there a way to compare an NSToolbarItem with a NSButton created in IB to a > one created programmatically? > > If so, this might shine some light as to what is really going on. > While trying to figure out what happens I wrapped NSToolbarItem in a Proxy > object to get all it's calls but it seems that I cannot get a hold of any > resizing that is sent to the button's cell Working with the NSToolbarItem is not likely useful. Did you try my suggestion of subclassing NSButtonCell? You can certainly configure the button in IB then inspect its configuration for settings. Basically just size and font, I imagine. Then as long as you can capture the setControlSize: call either to the button or cell, you can resize the button appropriately. HTH, Keary Suska Esoteritech, Inc. "Demystifying technology for your home or business" ___ 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
Issue of NSStatusBar
Hi,
I was facing issue of NSStatusBar getting closed by the [window close].
In our application, we have used [NSStatusBar SystemStatusBar] to display menu.
In a particular scenario, I need to close all the windows of my application
except About and Login, so I wrote following function:
- (void)closeIrrelevantWindows
{
NSSArray *allWindows = [NSApp windows];
for(NSWindow *aWindow in allWindows)
{
if([awindow isVisible] && ![aWindow aboutWin] && ![aWindow loginWindow])
[aWindow close];
}
}
This call some times closes my NSStatusItem as well. Can anybody tell me whats
wrong with the above code?
I checked NSStatusItem and NSStatusBar class reference both are derived from
NSObject.
Thanks.
___
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: Issue of NSStatusBar
On Feb 26, 2013, at 9:16 AM, Anil Saini wrote:
> Hi,
>
> I was facing issue of NSStatusBar getting closed by the [window close].
>
> In our application, we have used [NSStatusBar SystemStatusBar] to display
> menu. In a particular scenario, I need to close all the windows of my
> application except About and Login, so I wrote following function:
> - (void)closeIrrelevantWindows
> {
> NSSArray *allWindows = [NSApp windows];
>
> for(NSWindow *aWindow in allWindows)
> {
> if([awindow isVisible] && ![aWindow aboutWin] && ![aWindow loginWindow])
>[aWindow close];
> }
> }
>
> This call some times closes my NSStatusItem as well. Can anybody tell me
> whats wrong with the above code?
> I checked NSStatusItem and NSStatusBar class reference both are derived from
> NSObject.
In order to display anything, it needs to be placed in a window. Your code
above is correct in that it doesn't send -close to any status bar items, but it
*does* send -close to the invisible window that constrains them. That's why
they disappear.
You'll probably want to do some more careful checking of the windows prior to
sending them -close. Perhaps check the class of their window controller or
their delegate.
--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
archiving report
My investigations regarding archiving on OS X: 1. NSArchiver stores all strings in Utf-8. This is inefficient for strings which contain mainly non-european characters (e.g. Chinese or Thai) as one character will use 3 bytes (Utf-16 would use only 2). Corollary: It cannot store strings which contain illegal Unicode chars. 2. NSKeyedArchiver seems to be ok. But it does create unnecessary data. E.g. in the case of an array containing identical objects, like: NSArray *a = @[ @"a", @"a", , @"a"]; With 1 000 000 items it creates 10,000,395 bytes - my version creates only 1 000 332 bytes and the output is still readable by NSKeyedUnarchiver. 3, NSKeyedUnarchiver has several bugs. The string $null is converted to nil. Very harmful if this string is part of a collection (like array, set or dictionary). If the key in: encodeXXX:forKey: starts with an "$" NSKeyedArchiver correctly mangles this by prefixing another "$". But NSKeyedUnarchiver does not find these mangled keys and returns nil or 0. I have not reported these bugs, as I am convinced that Apple has no interest in fixing these problems. Gerriet. ___ 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: archiving report
On Feb 26, 2013, at 12:47 PM, Gerriet M. Denkmann wrote: > My investigations regarding archiving on OS X: > > 1. NSArchiver stores all strings in Utf-8. > This is inefficient for strings which contain mainly non-european > characters (e.g. Chinese or Thai) as one character will use 3 bytes (Utf-16 > would use only 2). > Corollary: It cannot store strings which contain illegal Unicode chars. And then in UTF-16, strings which contain mostly ASCII/European characters are wasting 2x space. Six of one, half dozen of the other. This is a very old debate and I'm grateful that Apple chose UTF-8 for storage, as UTF-16 makes things much more complicated. > 2. NSKeyedArchiver seems to be ok. > But it does create unnecessary data. E.g. in the case of an array > containing identical objects, like: > NSArray *a = @[ @"a", @"a", , @"a"]; > With 1 000 000 items it creates 10,000,395 bytes - my version creates > only 1 000 332 bytes > and the output is still readable by NSKeyedUnarchiver. Are you sure this is happening? NSKeyedArchiver is documented as doing deduplication of objects. If this is true, it's definitely a bug and there is no reason Apple wouldn't want it fixed. > 3, NSKeyedUnarchiver has several bugs. > The string $null is converted to nil. > Very harmful if this string is part of a collection (like array, set or > dictionary). It should have already been mangled by NSKeyedArchiver. > If the key in: encodeXXX:forKey: starts with an "$" NSKeyedArchiver > correctly mangles this by prefixing > another "$". But NSKeyedUnarchiver does not find these mangled keys and > returns nil or 0. You can, as a workaround, consider keys prefixed by $ as reserved, however this is certainly a bug. The fact that no one has reported it/gotten it fixed in so much time shows that it's probably not a major issue, though. > I have not reported these bugs, as I am convinced that Apple has no interest > in fixing these problems. This is the exact attitude that causes Apple to be perceived as not having interest. Please file the bugs - the engineers reading this list can't give high priority to things that developers don't report, as much as they'd probably like to. -- Gwynne Raskind ___ 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: archiving report
On Feb 26, 2013, at 9:47 AM, "Gerriet M. Denkmann" wrote: > My investigations regarding archiving on OS X: > > 1. NSArchiver stores all strings in Utf-8. >This is inefficient for strings which contain mainly non-european > characters (e.g. Chinese or Thai) as one character will use 3 bytes (Utf-16 > would use only 2). >Corollary: It cannot store strings which contain illegal Unicode chars. NSString isn't designed to handle illegal Unicode characters either, so this is not unexpected. > > 2. NSKeyedArchiver seems to be ok. OK in what way? I would hope it writes UTF-8 as well, rather than NSString's internal UCS-2 representation. It's a shame we can't specify an encoding hint to NSString. >But it does create unnecessary data. E.g. in the case of an array > containing identical objects, like: >NSArray *a = @[ @"a", @"a", , @"a"]; >With 1 000 000 items it creates 10,000,395 bytes - my version creates only > 1 000 332 bytes >and the output is still readable by NSKeyedUnarchiver. What are these 57 bytes you saved? Is it worth saving 57 bytes for the burden of maintaining your own compatibility with NSKeyedArchiver? > > 3, NSKeyedUnarchiver has several bugs. >The string $null is converted to nil. >Very harmful if this string is part of a collection (like array, set or > dictionary). > >If the key in: encodeXXX:forKey: starts with an "$" NSKeyedArchiver > correctly mangles this by prefixing >another "$". But NSKeyedUnarchiver does not find these mangled keys and > returns nil or 0. I am frustrated that this bug has been known for years and never been fixed. > > I have not reported these bugs, as I am convinced that Apple has no interest > in fixing these problems. This is not a helpful attitude to take. --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: archiving report
On Feb 26, 2013, at 10:04 AM, Kyle Sluder wrote: > On Feb 26, 2013, at 9:47 AM, "Gerriet M. Denkmann" > wrote: > >> But it does create unnecessary data. E.g. in the case of an array >> containing identical objects, like: >> NSArray *a = @[ @"a", @"a", , @"a"]; >> With 1 000 000 items it creates 10,000,395 bytes - my version creates only >> 1 000 332 bytes >> and the output is still readable by NSKeyedUnarchiver. > > What are these 57 bytes you saved? Is it worth saving 57 bytes for the burden > of maintaining your own compatibility with NSKeyedArchiver? Apparently I can't read thousands separators. I'll file a bug against my brain's lexer. --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: archiving report
On Wed, 27 Feb 2013 00:47:35 +0700, Gerriet M. Denkmann said: >2. NSKeyedArchiver seems to be ok. One problem I know of with NSKeyedArchiver: It has methods like encodeInt32:forKey: but no unsigned variants . (Good thing I filed the bug, I'm sure Apple will get right on it, eh Gwynne? :) Sorry, couldn't resist.) You have to watch out for sign extension. This may surprise some people: uint32_t input = 0x; // 4294967295 NSMutableData* data = [NSMutableData data]; NSKeyedArchiver* archiver = [[NSKeyedArchiver alloc] initForWritingWithMutableData:data]; [archiver encodeInt32:(int32_t)input forKey:@"test"]; [archiver finishEncoding]; NSKeyedUnarchiver* unarchiver = [[NSKeyedUnarchiver alloc] initForReadingWithData:data]; int64_t output = [unarchiver decodeInt64ForKey:@"test"]; [unarchiver finishDecoding]; The value of output is _not_ 4294967295, it is -1. This behaves correctly, but I bet lots of code out there casts uint32 to int32 like above. If you want to encode a uint32 you need to use encodeInt64: I guess, which is not obvious. The lack of encodeUInt64 is worst of all. Cheers, -- Sean McBride, B. Eng s...@rogue-research.com Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada ___ 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
[Solved] NSButton in NSToolbarItem does not use "small size"
Well then. After experimenting with different cells and buttons, I came up with the following findings: If one uses a NSPopupButton in a NSToolBarItem the internal call (_handleSendControlSize:toCellOfView:) dispatches a setControlSize to the cell of the NSPopupButton. On the other hand, if one uses a NSButton, the NSButtonCell does not get the setControl call. Weirdly, if I change the Cell of a NSButton to a NSPopupButtonCell, it gets called with setControlSize: and resizes accordingly The solution to my problem was that NSToolBarItem seems to decide based on the cell class, whether to forward the call to the cell or just the containing view. I then subclassed NSButton and added a setControlSIze that just forwards everything to the NSButtonCell and everything is fancy as the NSToolbarItem calls _handleSendControlSize:toView: with get's to my NSButton subclass. Problem solved. I do however not know, why in IB the NSButton does get resized. A neater solution would have been to persuade NSToolBarItem to just call the cell of a NSButton as it does with the NSPopupButton --Michael On 26.02.2013, at 17:32, Michael Starke wrote: > No, I did not, I'll try subclassing NSButtonCell and see what I can dig up. > > Thanks. > > --Michael > > On 26.02.2013, at 17:04, Keary Suska wrote: > >> On Feb 26, 2013, at 8:28 AM, Michael Starke wrote: >> >>> Sorry for digging this up again. >>> >>> As I'm no experienced developer I'm somewhat lost how to address the >>> situation. >>> Is there a way to compare an NSToolbarItem with a NSButton created in IB to >>> a one created programmatically? >>> >>> If so, this might shine some light as to what is really going on. >>> While trying to figure out what happens I wrapped NSToolbarItem in a Proxy >>> object to get all it's calls but it seems that I cannot get a hold of any >>> resizing that is sent to the button's cell >> >> Working with the NSToolbarItem is not likely useful. Did you try my >> suggestion of subclassing NSButtonCell? You can certainly configure the >> button in IB then inspect its configuration for settings. Basically just >> size and font, I imagine. Then as long as you can capture the >> setControlSize: call either to the button or cell, you can resize the button >> appropriately. >> >> HTH, >> >> Keary Suska >> Esoteritech, Inc. >> "Demystifying technology for your home or business" >> > > > ___m i c h a e l s t a r k e > geschäftsführer > HicknHack Software GmbH > www.hicknhack-software.com > > ___k o n t a k t > +49 (170) 3686136 > cont...@hicknhack.com > > ___H i c k n H a c k S o f t w a r e G m b H > geschäftsführer - maik lathan | andreas reischuck | michael starke > bayreuther straße 32 > 01187 dresden > amtsgericht dresden HRB 30351 > sitz - dresden > ___m i c h a e l s t a r k e geschäftsführer HicknHack Software GmbH www.hicknhack-software.com ___k o n t a k t +49 (170) 3686136 cont...@hicknhack.com ___H i c k n H a c k S o f t w a r e G m b H geschäftsführer - maik lathan | andreas reischuck | michael starke bayreuther straße 32 01187 dresden amtsgericht dresden HRB 30351 sitz - dresden ___ 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: archiving report
On 27 Feb 2013, at 01:00, Gwynne Raskind wrote: > On Feb 26, 2013, at 12:47 PM, Gerriet M. Denkmann > wrote: >> My investigations regarding archiving on OS X: >> >> 1. NSArchiver stores all strings in Utf-8. >> This is inefficient for strings which contain mainly non-european >> characters (e.g. Chinese or Thai) as one character will use 3 bytes (Utf-16 >> would use only 2). >> Corollary: It cannot store strings which contain illegal Unicode chars. > > And then in UTF-16, strings which contain mostly ASCII/European characters > are wasting 2x space. Six of one, half dozen of the other. This is a very old > debate and I'm grateful that Apple chose UTF-8 for storage, as UTF-16 makes > things much more complicated. Or one could (as NSKeyedArchiver seems to do) choose the shortest representation, >> 2. NSKeyedArchiver seems to be ok. >> But it does create unnecessary data. E.g. in the case of an array >> containing identical objects, like: >> NSArray *a = @[ @"a", @"a", , @"a"]; >> With 1 000 000 items it creates 10,000,395 bytes - my version creates >> only 1 000 332 bytes >> and the output is still readable by NSKeyedUnarchiver. > > Are you sure this is happening? NSKeyedArchiver is documented as doing > deduplication of objects. If this is true, it's definitely a bug and there is > no reason Apple wouldn't want it fixed. Just try it yourself: #define NBR 100 NSMutableArray *m = [ NSMutableArray array ]; for ( NSUInteger i = 0; i < NBR; i++ ) [ m addObject: @"a" ]; NSData *dataKeyed = [ NSKeyedArchiver archivedDataWithRootObject: m ]; NSLog(@"%s NSKeyedArchiver created %10lu bytes ", __FUNCTION__, [dataKeyed length]); Then change NBR to 101 and compare. > >> 3, NSKeyedUnarchiver has several bugs. >> The string $null is converted to nil. >> Very harmful if this string is part of a collection (like array, set or >> dictionary). > > It should have already been mangled by NSKeyedArchiver. Strings (other than keys) do NOT get mangled by NSKeyedArchiver. > >> If the key in: encodeXXX:forKey: starts with an "$" NSKeyedArchiver >> correctly mangles this by prefixing >> another "$". But NSKeyedUnarchiver does not find these mangled keys and >> returns nil or 0. > > You can, as a workaround, consider keys prefixed by $ as reserved, however > this is certainly a bug. The fact that no one has reported it/gotten it fixed > in so much time shows that it's probably not a major issue, though. > >> I have not reported these bugs, as I am convinced that Apple has no interest >> in fixing these problems. > > This is the exact attitude that causes Apple to be perceived as not having > interest. Please file the bugs - the engineers reading this list can't give > high priority to things that developers don't report, as much as they'd > probably like to. I have filed the $null bug. Got back as duplicate with a very low id-number. Meaning: this bug is known to Apple since several years. Still no fix. Gerriet. ___ 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: archiving report
On 27 Feb 2013, at 01:04, Kyle Sluder wrote: > On Feb 26, 2013, at 9:47 AM, "Gerriet M. Denkmann" > wrote: > >> My investigations regarding archiving on OS X: >> >> 1. NSArchiver stores all strings in Utf-8. >> This is inefficient for strings which contain mainly non-european >> characters (e.g. Chinese or Thai) as one character will use 3 bytes (Utf-16 >> would use only 2). >> Corollary: It cannot store strings which contain illegal Unicode chars. > > NSString isn't designed to handle illegal Unicode characters either, so this > is not unexpected. You can create and archive (with NSKeyedArchiver) illegal strings. unichar u = kUCHighSurrogateRangeStart; NSString *s = [ NSString stringWithCharacters: &u length: 1]; > >> >> 2. NSKeyedArchiver seems to be ok. > > OK in what way? I would hope it writes UTF-8 as well, rather than NSString's > internal UCS-2 representation. It uses whatever is shorter: Utf-8 or Utf-16. > > >> >> I have not reported these bugs, as I am convinced that Apple has no interest >> in fixing these problems. > > This is not a helpful attitude to take. When Apple helps me by fixing bugs, I will helping Apple by reporting them. Apple knows since years that NSKeyedUnarchiver is broken and does nothing. Gerriet. ___ 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: archiving report
On Tue, Feb 26, 2013, at 11:06 AM, Gerriet M. Denkmann wrote: > You can create and archive (with NSKeyedArchiver) illegal strings. > unichar u = kUCHighSurrogateRangeStart; > NSString *s = [ NSString stringWithCharacters: &u length: 1]; You might be able to do it now, but you certainly can't rely on it in the future. > > > > > >> > >> I have not reported these bugs, as I am convinced that Apple has no > >> interest in fixing these problems. > > > > This is not a helpful attitude to take. > > When Apple helps me by fixing bugs, I will helping Apple by reporting > them. So as you encounter further bugs, what are you going to do? Sit there and seethe? I understand the frustration caused by Apple's embarrassing penchant for not fixing bugs, and not even recognizing the receipt of bugs, and for replying with terrible requests for information you've already received. But refusing to report future bugs is only going to harm yourself. --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
NSTrackingInVisibleRect not working when view is resized
I have an NSControl subclass that has installed an NSTrackingAread for (NSTrackingInVisibleRect | NSTrackingMouseMoved | NSTrackingMouseEnteredAndExited | NSTrackingCursorUpdate | NSTrackingActiveInKeyWindow). This control can resize itself while tracking the mouse in its mouseDown method. If, after mouse-up, the mouse ends up outside the *original* frame, but is still inside the current frame, I'm getting a mouseExited. So it's like the NSTrackingArea code is caching an old frame or something like that instead of getting it directly from the view. Or is this some "undocumented behavior" I'm seeing? -- 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: archiving report
If we spend the time to enter bugs that don't get fixed, it ends up being a waste of our time. We have no control over if Apple choses to fix our bugs or not. Do we waste time working around a bug, then waste time reporting it? I've got capitalization on an NSString failing at the moment with no change in the string and have to write a method that works. If I have no faith that Apple will fix my bug, then what is my justification to narrow down the bug and report it when I will be staying late in the office as it is already? Taking the time to report the bug if we don't know if it will be fixed doesn't help our products ship any faster. Sad reality, but it's true. Sent from my iPad On Feb 26, 2013, at 2:17 PM, Kyle Sluder wrote: > On Tue, Feb 26, 2013, at 11:06 AM, Gerriet M. Denkmann wrote: >> You can create and archive (with NSKeyedArchiver) illegal strings. >> unichar u = kUCHighSurrogateRangeStart; >> NSString *s = [ NSString stringWithCharacters: &u length: 1]; > > You might be able to do it now, but you certainly can't rely on it in > the future. > >>> >>> I have not reported these bugs, as I am convinced that Apple has no interest in fixing these problems. >>> >>> This is not a helpful attitude to take. >> >> When Apple helps me by fixing bugs, I will helping Apple by reporting >> them. > > So as you encounter further bugs, what are you going to do? Sit there > and seethe? > > I understand the frustration caused by Apple's embarrassing penchant for > not fixing bugs, and not even recognizing the receipt of bugs, and for > replying with terrible requests for information you've already received. > But refusing to report future bugs is only going to harm yourself. > > --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/zav%40mac.com > > This email sent to z...@mac.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: archiving report
Sometimes I feel the same way; that said I've had over a dozen reported bugs fixed by Apple on iOS over the last 4-5 years. On OS X, very few. So I know they do care about it, but I also find sometimes that I get a better result if I report the bug via RADAR and THEN also post about it on the Dev Forum with the RADAR ID. Not always, but more often than not that has worked. On Tue, Feb 26, 2013 at 2:13 PM, Alex Zavatone wrote: > If we spend the time to enter bugs that don't get fixed, it ends up being > a waste of our time. > > We have no control over if Apple choses to fix our bugs or not. Do we > waste time working around a bug, then waste time reporting it? > > I've got capitalization on an NSString failing at the moment with no > change in the string and have to write a method that works. If I have no > faith that Apple will fix my bug, then what is my justification to narrow > down the bug and report it when I will be staying late in the office as it > is already? Taking the time to report the bug if we don't know if it will > be fixed doesn't help our products ship any faster. Sad reality, but it's > true. > > Sent from my iPad > > On Feb 26, 2013, at 2:17 PM, Kyle Sluder wrote: > > > On Tue, Feb 26, 2013, at 11:06 AM, Gerriet M. Denkmann wrote: > >> You can create and archive (with NSKeyedArchiver) illegal strings. > >> unichar u = kUCHighSurrogateRangeStart; > >> NSString *s = [ NSString stringWithCharacters: &u length: 1]; > > > > You might be able to do it now, but you certainly can't rely on it in > > the future. > > > >>> > >>> > > I have not reported these bugs, as I am convinced that Apple has no > interest in fixing these problems. > >>> > >>> This is not a helpful attitude to take. > >> > >> When Apple helps me by fixing bugs, I will helping Apple by reporting > >> them. > > > > So as you encounter further bugs, what are you going to do? Sit there > > and seethe? > > > > I understand the frustration caused by Apple's embarrassing penchant for > > not fixing bugs, and not even recognizing the receipt of bugs, and for > > replying with terrible requests for information you've already received. > > But refusing to report future bugs is only going to harm yourself. > > > > --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/zav%40mac.com > > > > This email sent to z...@mac.com > > ___ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/cocoa-dev/alex%40webis.net > > This email sent to a...@webis.net > -- *Alex Kac - **President and Founder* *Web Information Solutions, Inc.* ___ 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: NSTrackingInVisibleRect not working when view is resized
I will repeat my request from your last NSTrackingArea query: I'm not certain of the answer to this question, but what does your -updateTrackingAreas look like? If you follow Apple's erroneous example and recreate your tracking are every time this method is called, you *will* drop -mouseExited: events on the floor. A correct override of -updateTrackingAreas only creates and installs the tracking area if it has not already been created and installed. --Kyle Sluder On Tue, Feb 26, 2013, at 12:46 PM, Steve Mills wrote: > I have an NSControl subclass that has installed an NSTrackingAread for > (NSTrackingInVisibleRect | NSTrackingMouseMoved | > NSTrackingMouseEnteredAndExited | NSTrackingCursorUpdate | > NSTrackingActiveInKeyWindow). This control can resize itself while > tracking the mouse in its mouseDown method. If, after mouse-up, the mouse > ends up outside the *original* frame, but is still inside the current > frame, I'm getting a mouseExited. So it's like the NSTrackingArea code is > caching an old frame or something like that instead of getting it > directly from the view. Or is this some "undocumented behavior" I'm > seeing? > > -- > 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/kyle%40ksluder.com > > This email sent to k...@ksluder.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSTrackingInVisibleRect not working when view is resized
On Tue, Feb 26, 2013, at 01:32 PM, Kyle Sluder wrote: > I will repeat my request from your last NSTrackingArea query: > (This isn't meant to be snark, BTW. It just makes debugging a lot easier.) --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: archiving report
On Feb 26, 2013, at 12:06 PM, "Gerriet M. Denkmann" wrote: > > When Apple helps me by fixing bugs, I will helping Apple by reporting them. > Apple knows since years that NSKeyedUnarchiver is broken and does nothing. Regardless of what they ultimately fix, filing bug reports is the best way to communicate issues. Preston ___ 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: NSTrackingInVisibleRect not working when view is resized
On Feb 26, 2013, at 15:32:48, Kyle Sluder wrote: > I'm not certain of the answer to this question, but what does your > -updateTrackingAreas look like? If you follow Apple's erroneous example > and recreate your tracking are every time this method is called, you > *will* drop -mouseExited: events on the floor. A correct override of > -updateTrackingAreas only creates and installs the tracking area if it > has not already been created and installed. I don't *have* an updateTrackingAreas method because I'm using NSTrackingInVisibleRect, which is documented to always use the visibleRect of the view. -- 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: NSTrackingInVisibleRect not working when view is resized
On Tue, Feb 26, 2013, at 01:45 PM, Steve Mills wrote: > I don't *have* an updateTrackingAreas method because I'm using > NSTrackingInVisibleRect, which is documented to always use the > visibleRect of the view. So when are you installing the tracking area? -updateTrackingAreas seems like the appropriate time for the view to install its own tracking area. --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
NSScrollView and autolayout
Does NSScrollView own its documentView, and controls the value that documentView returns for setTranslatesAutoresizingMaskIntoConstraints:? I've created an NSView subclass that I'm using for a documentView within an NSScrollView. I'm calling [self setTranslatesAutoresizingMaskIntoConstraints:NO] during initialization. Is that a problem? The UI works fine, but the layout for my documentView is ambiguous. I believe that I'm setting its constraints properly. Would it be better to [scrollView.documentView addSubview:myContainerView]? Then, add the following constraints to the scrollView.documentView: @"V:|[myContainerView]|" and @"H:|[myContainerView]|" This way, I think that it would be fine to call [self setTranslatesAutoresizingMaskIntoConstraints:NO] during initialization for myContainerView. If this is true, then I think that I may need to call setFrameSize: on scrollView.documentView when my myContainerView frame size changes, is that correct? Or, is there some way to get my documentView to resize based on its subviews (i.e. myContainerView)? With NSSplitView, I think it's fine to add subviews that use auto layout. Any help would be appreciated. Thanks, Chuck ___ 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: archiving report
Nice tip and it's great to hear of your issues getting fixed. I feel what is important about this is that we keep an open copy of the issues we find (I know this was mentioned here before) and use open radar so that we can profit from each other's experience/grief when we run into bugs and report bugs in the OSes. http://openradar.appspot.com On the fixed bug front, I was just informed that my iTunes podcast "delete all your downloaded podcasts" bug was just fixed in the .02 release of the new iTunes. Hate to get hit by them in the first place, but nice to see fixes. Sent from my iPad On Feb 26, 2013, at 4:21 PM, Alex Kac wrote: > Sometimes I feel the same way; that said I've had over a dozen reported bugs > fixed by Apple on iOS over the last 4-5 years. On OS X, very few. So I know > they do care about it, but I also find sometimes that I get a better result > if I report the bug via RADAR and THEN also post about it on the Dev Forum > with the RADAR ID. Not always, but more often than not that has worked. > > > > On Tue, Feb 26, 2013 at 2:13 PM, Alex Zavatone wrote: > If we spend the time to enter bugs that don't get fixed, it ends up being a > waste of our time. > > We have no control over if Apple choses to fix our bugs or not. Do we waste > time working around a bug, then waste time reporting it? > > I've got capitalization on an NSString failing at the moment with no change > in the string and have to write a method that works. If I have no faith that > Apple will fix my bug, then what is my justification to narrow down the bug > and report it when I will be staying late in the office as it is already? > Taking the time to report the bug if we don't know if it will be fixed > doesn't help our products ship any faster. Sad reality, but it's true. > > Sent from my iPad > > On Feb 26, 2013, at 2:17 PM, Kyle Sluder wrote: > > > On Tue, Feb 26, 2013, at 11:06 AM, Gerriet M. Denkmann wrote: > >> You can create and archive (with NSKeyedArchiver) illegal strings. > >> unichar u = kUCHighSurrogateRangeStart; > >> NSString *s = [ NSString stringWithCharacters: &u length: 1]; > > > > You might be able to do it now, but you certainly can't rely on it in > > the future. > > > >>> > >>> > > I have not reported these bugs, as I am convinced that Apple has no > interest in fixing these problems. > >>> > >>> This is not a helpful attitude to take. > >> > >> When Apple helps me by fixing bugs, I will helping Apple by reporting > >> them. > > > > So as you encounter further bugs, what are you going to do? Sit there > > and seethe? > > > > I understand the frustration caused by Apple's embarrassing penchant for > > not fixing bugs, and not even recognizing the receipt of bugs, and for > > replying with terrible requests for information you've already received. > > But refusing to report future bugs is only going to harm yourself. > > > > --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/zav%40mac.com > > > > This email sent to z...@mac.com > > ___ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/cocoa-dev/alex%40webis.net > > This email sent to a...@webis.net > > > > -- > Alex Kac - President and Founder > > Web Information Solutions, Inc. ___ 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: NSTrackingInVisibleRect not working when view is resized
On Feb 26, 2013, at 16:12:02, Kyle Sluder wrote: > So when are you installing the tracking area? -updateTrackingAreas seems > like the appropriate time for the view to install its own tracking area. In my initWithFrame method, just like one of Apple's examples: http://developer.apple.com/library/Mac/#documentation/Cocoa/Conceptual/EventOverview/TrackingAreaObjects/TrackingAreaObjects.html -- 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: NSScrollView and autolayout
On Tue, Feb 26, 2013, at 02:32 PM, Chuck Soper wrote: > Does NSScrollView own its documentView, and controls the value that > documentView returns for setTranslatesAutoresizingMaskIntoConstraints:? It's actually NSClipView that controls this, but yes. > > I've created an NSView subclass that I'm using for a documentView within > an NSScrollView. I'm calling [self > setTranslatesAutoresizingMaskIntoConstraints:NO] during initialization. > Is > that a problem? The UI works fine, but the layout for my documentView is > ambiguous. I believe that I'm setting its constraints properly. The general philosophy behind -translatesAutoresizingMaskIntoConstraints is that it's the container's job to control that property. That allows containers which position their subviews to incrementally adopt auto layout. > Would it be better to [scrollView.documentView > addSubview:myContainerView]? Then, add the following constraints to the > scrollView.documentView: > @"V:|[myContainerView]|" and @"H:|[myContainerView]|" > This way, I think that it would be fine to call [self > setTranslatesAutoresizingMaskIntoConstraints:NO] during initialization > for > myContainerView. > If this is true, then I think that I may need to call setFrameSize: on > scrollView.documentView when my myContainerView frame size changes, is > that correct? Or, is there some way to get my documentView to resize > based > on its subviews (i.e. myContainerView)? Sadly, this won't work. The problem here is that the constraints installed by -translatesAutoresizingMaskIntoConstraints are fixed constraints, and if myContainerView's constraints solve to a different value that the frame of the scroll view's document view, you will get an unsatisfiable constraints exception. In order to get auto layout to work with scroll views, we actually override -updateConstraints in our document view, and call [self setTranslatesAutoresizingMaskIntoConstraints:NO] before calling super. Then we set up constraints that keep us correctly sized and positioned relative to our enclosing clip view. This is a terrible hack that I really hope is fixed in a future version of OS X with a constraint-aware implementation of NSScrollView that works like UIScrollView on iOS 6. > > With NSSplitView, I think it's fine to add subviews that use auto layout. Yes, on 10.8. 10.7 is trickier. --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: NSButton in NSToolbarItem does not use "small size"
On 27/02/2013, at 2:28 AM, Michael Starke wrote: > As I'm no experienced developer I'm somewhat lost how to address the > situation. > Is there a way to compare an NSToolbarItem with a NSButton created in IB to a > one created programmatically? Well, I have to ask the obvious question: why are you doing this programmatically? Avoiding IB is often a signature failing of the "no experienced developer". I've created even quite non-standard toolbar items and have never had to avoid IB to do so. --Graham ___ 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: archiving report
Alex Zavatone writes: If we spend the time to enter bugs that don't get fixed, it ends up being a waste of our time. We have no control over if Apple choses to fix our bugs or not. Do we waste time working around a bug, then waste time reporting it? I've got capitalization on an NSString failing at the moment with no change in the string and have to write a method that works. If I have no faith that Apple will fix my bug, then what is my justification to narrow down the bug and report it when I will be staying late in the office as it is already? Taking the time to report the bug if we don't know if it will be fixed doesn't help our products ship any faster. Sad reality, but it's true. In this neck of the woods, we call that a self-fulfilling prophecy. We don't have "control" over whether Apple fixes bugs or not, but we do have influence. All work, including bug fixes, is going to get prioritized in order to attempt to maximize the effective use of finite resources. We influence that prioritization by filing bugs. If you believe your bug is such an edge case that only one person in a decade runs across it, then you're probably right: It won't get fixed because it won't bubble up in the queue high enough to displace more impactful tasks. On the other hand, if 100 people a year are running into a bug and only 1 of them reports it because everyone else "knows" it will be a waste of time...well, the other 99/year have no one to blame but themselves. ___ 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: archiving report
On 27/02/2013, at 5:56 AM, Gerriet M. Denkmann wrote: > I have filed the $null bug. Got back as duplicate with a very low id-number. > Meaning: this bug is known to Apple since several years. Still no fix. Frustrating for sure, but in this particular case, I wonder whether there even is a fix that would remain forward and backward compatible. It sounds like the design was signed off either without considering that case, or considering it and assuming it was of vanishingly low probability. I would hesitate to suggest it, but if you are routinely storing NSNull (or @"$null") in arrays, it might point to a flaw in your own design. I find using NSSet is often a much better choice than an NSArray because it only stores unique instances, and this frequently avoids the need to store NSNulls. Converting that to an array if ordering is important can often be done on the fly. --Graham ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSScrollView and autolayout
Excellent, informative response. Thanks. Do you know if your documentView returns YES for hasAmbiguousLayout? My user interface appears to work fine. The only problem is that [scrollView.documentView hasAmbiguousLayout] returns YES. Given that my UI appears to work as expected, can I just ignore the fact that [scrollView.documentView hasAmbiguousLayout] returns YES? more comments below... On 2/26/13 2:52 PM, "Kyle Sluder" wrote: >On Tue, Feb 26, 2013, at 02:32 PM, Chuck Soper wrote: >> Does NSScrollView own its documentView, and controls the value that >> documentView returns for setTranslatesAutoresizingMaskIntoConstraints:? > >It's actually NSClipView that controls this, but yes. > >> >> I've created an NSView subclass that I'm using for a documentView within >> an NSScrollView. I'm calling [self >> setTranslatesAutoresizingMaskIntoConstraints:NO] during initialization. >> Is >> that a problem? The UI works fine, but the layout for my documentView is >> ambiguous. I believe that I'm setting its constraints properly. > >The general philosophy behind -translatesAutoresizingMaskIntoConstraints >is that it's the container's job to control that property. That allows >containers which position their subviews to incrementally adopt auto >layout. > >> Would it be better to [scrollView.documentView >> addSubview:myContainerView]? Then, add the following constraints to the >> scrollView.documentView: >> @"V:|[myContainerView]|" and @"H:|[myContainerView]|" >> This way, I think that it would be fine to call [self >> setTranslatesAutoresizingMaskIntoConstraints:NO] during initialization >> for >> myContainerView. >> If this is true, then I think that I may need to call setFrameSize: on >> scrollView.documentView when my myContainerView frame size changes, is >> that correct? Or, is there some way to get my documentView to resize >> based >> on its subviews (i.e. myContainerView)? > >Sadly, this won't work. The problem here is that the constraints >installed by -translatesAutoresizingMaskIntoConstraints are fixed >constraints, and if myContainerView's constraints solve to a different >value that the frame of the scroll view's document view, you will get an >unsatisfiable constraints exception. Ah, I understand now. I've seen that exception. Good point. I'm already overriding -updateConstraints in my custom documentView. I maintain an array of constraints similar to the AutoLayout SplitView sample code (WWDC 2011). It seems like I might be able to do the following in my documentView's updateConstraints override: 1. Remove all existing constraints (and empty my constraints array). 2. Set the frame for my documentView. 3. Create and add new constraints (loading my constraints array). This might avoid the unsatisfiable constraints exception. If this approach works, then I'd also have to be careful about subviews within my documentView. They override intrinsicContentSize. I call invalidateIntrinsicContentSize to update their size. In this case, I might not be able to avoid the unsatisfiable constraints exception unless I completely rebuilt my constraints every time a subview's size changes - not very efficient. >In order to get auto layout to work with scroll views, we actually >override -updateConstraints in our document view, and call [self >setTranslatesAutoresizingMaskIntoConstraints:NO] before calling super. >Then we set up constraints that keep us correctly sized and positioned >relative to our enclosing clip view. I'm overriding updateConstraints in my document view as well. I just added this call: [self setTranslatesAutoresizingMaskIntoConstraints:NO] before calling super, as you recommended. I believe that the constraints for my documentView and its subviews are correct. Everything seems to work except that the documentView returns YES for hasAmbiguousLayout. Can you say anything more about how to set up constraints that keep your document view correctly sized and positioned relative to the enclosing clip view? I'm not following that. >This is a terrible hack that I really hope is fixed in a future version >of OS X with a constraint-aware implementation of NSScrollView that >works like UIScrollView on iOS 6. I totally agree. Hey, maybe for 10.8.3! As far as I can tell the issue or a work-around isn't documented. >> >> With NSSplitView, I think it's fine to add subviews that use auto >>layout. > >Yes, on 10.8. 10.7 is trickier. > >--Kyle Sluder Thanks! Chuck ___ 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: NSButton in NSToolbarItem does not use "small size"
On 27.02.2013, at 01:06, Graham Cox wrote: > > On 27/02/2013, at 2:28 AM, Michael Starke > wrote: > >> As I'm no experienced developer I'm somewhat lost how to address the >> situation. >> Is there a way to compare an NSToolbarItem with a NSButton created in IB to >> a one created programmatically? > > > Well, I have to ask the obvious question: why are you doing this > programmatically? Avoiding IB is often a signature failing of the "no > experienced developer". > > I've created even quite non-standard toolbar items and have never had to > avoid IB to do so. Valid point. Maybe it's the wrong way to do so. It seemed right to work this way in the delegate. I get to use my internal string constants for the identifiers, I can directly set actions without having to connect them in IB and do not have to keep the IB file and my code in sync since this comes free with using the constants. Localizations is equally easy done in code this way. Icons for the Items are easily maintainable in one spot. But you're right, maybe I should give the IB focused way another chance. > --Graham > > ___m i c h a e l s t a r k e geschäftsführer HicknHack Software GmbH www.hicknhack-software.com ___k o n t a k t +49 (170) 3686136 cont...@hicknhack.com ___H i c k n H a c k S o f t w a r e G m b H geschäftsführer - maik lathan | andreas reischuck | michael starke bayreuther straße 32 01187 dresden amtsgericht dresden HRB 30351 sitz - dresden ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
How to move UIImageView in order to always keep image's head forward?
I have posted this question in StackOverflow, I am hurry to the solution, so I post question here again. Assume I have an UIImageView in ViewController's view, and this UIImageView contains an image. For example, that is a car image, and car's head directs to the north in default. Then, I want to do some rotation and movement for that char(actually for UIImageView). I use CGAffineTransformRotate function to rotate it CGAffineTransform newTransform = CGAffineTransformRotate(_ImageView.transform, angle); Then assign values to tx and ty of newTransform respectively. That's it. But values to tx and ty is in UIImageView's coordinate system and that system won't be rotated even UIImageView rotated. My question is: Is there any easy way to get the value of tx and ty so that we could keep UIImageView move straightforward? Even the direction of image's head has been changed. -- Jingwei Xu ICS Group State Key Laboratory for Novel Software Technology Department of Computer Science and Technology Nanjing University Addr: 163 Xianlin Road, Nanjing 210046, P. R. China ___ 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: archiving report
On 27 Feb 2013, at 07:20, Graham Cox wrote: > > On 27/02/2013, at 5:56 AM, Gerriet M. Denkmann wrote: > >> I have filed the $null bug. Got back as duplicate with a very low id-number. >> Meaning: this bug is known to Apple since several years. Still no fix. > > > Frustrating for sure, but in this particular case, I wonder whether there > even is a fix that would remain forward and backward compatible. Well, there is a fix. I have a version of NSKeyedUnarchiver which works perfectly (getting nil for nil and "$null" for "$null"). So the data format produced by NSKeyedArchiver seems to be ok. No compatibility problems backward or forward. And the result of a better NSKeyedArchiver (which wastes less space) is still readable by the current NSKeyedUnarchiver - again no compatibility problems. > > It sounds like the design was signed off either without considering that case > [...] No. The design of the NSKeyedArchiver data format is perfectly sound (although slightly redundant). NSKeyedUnarchiver just fails to understand it. Kind regards, Gerriet. ___ 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: archiving report
On 27 Feb 2013, at 02:17, Kyle Sluder wrote: > On Tue, Feb 26, 2013, at 11:06 AM, Gerriet M. Denkmann wrote: >> You can create and archive (with NSKeyedArchiver) illegal strings. >> unichar u = kUCHighSurrogateRangeStart; >> NSString *s = [ NSString stringWithCharacters: &u length: 1]; > > You might be able to do it now, but you certainly can't rely on it in > the future. I am not advocating using illegal strings. For one: there is no way of knowing which string operations might work or not. The point is: if NSString can create something, it should be archivable. But I admit that this is a very minor and unimportant bug. The best fix by far would be if NSString does not allow to create nonsense strings at all. Kind regards, Gerriet. ___ 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: Issue of NSStatusBar
I got the solution, just need to check for NSStatusBarWindow className as
follows:
if([awindow isVisible] && ![aWindow aboutWin] && ![aWindow loginWindow] &&
![[aWindow className] isEqual:@"NSStatusBarWindow"])
Thanks.
From: Kyle Sluder
To: Anil Saini
Cc: "cocoa-dev@lists.apple.com"
Sent: Tuesday, 26 February 2013 9:35 PM
Subject: Re: Issue of NSStatusBar
On Feb 26, 2013, at 9:16 AM, Anil Saini wrote:
> Hi,
>
> I was facing issue of NSStatusBar getting closed by the [window close].
>
> In our application, we have used [NSStatusBar SystemStatusBar] to display
> menu. In a particular scenario, I need to close all the windows of my
> application except About and Login, so I wrote following function:
> - (void)closeIrrelevantWindows
> {
> NSSArray *allWindows = [NSApp windows];
>
> for(NSWindow *aWindow in allWindows)
> {
> if([awindow isVisible] && ![aWindow aboutWin] && ![aWindow loginWindow])
> [aWindow close];
> }
> }
>
> This call some times closes my NSStatusItem as well. Can anybody tell me
> whats wrong with the above code?
> I checked NSStatusItem and NSStatusBar class reference both are derived from
> NSObject.
In order to display anything, it needs to be placed in a window. Your code
above is correct in that it doesn't send -close to any status bar items, but it
*does* send -close to the invisible window that constrains them. That's why
they disappear.
You'll probably want to do some more careful checking of the windows prior to
sending them -close. Perhaps check the class of their window controller or
their delegate.
--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: archiving report
On 26 Feb 2013, at 4:20 pm, Graham Cox wrote: > I would hesitate to suggest it, but if you are routinely storing NSNull (or > @"$null") in arrays, it might point to a flaw in your own design. As someone pointed out earlier, this bug makes NSKeyedArchiver unusable for any data model that contains user-entered strings. For round-trip behaviour, *all* NSString values passed through NSKeyedArchiver must be filtered on the way in and on the way out. Sure enough, I just discovered that one of my apps--whose file format is about eight years old and (perhaps unfortunately) based around NSKeyedArchiver--is vulnerable to this bug. Enter the string "$null" into any text field in the doc, save, and that doc will never open again. (Clearly this points to another bug in my own code--an exception is raised due to a nil string being assigned to an NSTextFieldCell--but proves that the magic string "$null" has been turned into nothingness.) b -- Ben Kennedy, chief magician Zygoat Creative Technical Services http://www.zygoat.ca ___ 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
customizing cursor nssearchfield
Hi, This seems it should be easy enough, but could anyone give me pointers on how to do this? Seems I should be subclassing NSTextView and using drawInsertionPointInRect:color:turnedOn: but how would I do this? I don't really want to do major customization maybe just a touch thicker or a touch shorter, but the question is where? Thanks, rc ___ 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
