Re: issues using encodeWithCoder: with NSAttributedString for iOS

2012-02-27 Thread Evadne Wu 
A very naïve suggestion is that if you are targeting OS X you might be
able to use HTML or RTF.  Save that and convert the stored into to an
attributed string at run time.

One idea of font descriptors is that a particular font may not exist
on a particular computer, but similar ones might be available.  When
the end result is created as an attributed string that info is already
lost.

On Feb 27, 2012, at 14:33, Heath Borders  wrote:

> I don’t know of an easy workaround. Back in the day I would have suggested
> creating a category on CGColor that adds the required archiving methods,
> but doing this will get you rejected from the App Store. You may need to
> write a function that walks through a mutable attributed string and finds
> all color objects and replaces them with something serializable, and
> another function that reverses this.
>
>
> How do you create a category for a Foundation type that isn't an
> Objective-C class? And why would that get you rejected?
>
> Sent from my iPad
>
> On Feb 27, 2012, at 12:21 AM, Jens Alfke  wrote:
>
>
> On Feb 26, 2012, at 9:44 PM, Michael Swan wrote:
>
> the thing that doesn't make any sense is that if NSAttributedString
> conforms to the NSCoding protocol it must be able to fully pack itself up
> when encodeWithCoder: is called on it which means that it should already be
> taking care of encoding the CGColor in whatever way necessary.
>
>
> Archiving doesn’t work that way. Every object asks its instance variables
> to archive themselves; it’s not in charge of how they do it.
> NSAttributedString is, basically, an array of dictionaries, each of which
> can have arbitrary values in it. NSAttributedString itself doesn’t know or
> care what those keys or values are. (Note that NSAttributedString is
> implemented in the Foundation framework, which is lower level than UIKit.)
>
> What you’re running into is that CGColor isn’t archivable — it doesn’t
> implement the protocol methods like -encodeWithCoder:. So the attributed
> string is asking the attribute dictionary to archive itself, and the
> dictionary asks its keys and values to archive themselves, and the CGColor
> object fails.
>
> I don’t know of an easy workaround. Back in the day I would have suggested
> creating a category on CGColor that adds the required archiving methods,
> but doing this will get you rejected from the App Store. You may need to
> write a function that walks through a mutable attributed string and finds
> all color objects and replaces them with something serializable, and
> another function that reverses this.
>
> —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/heath.borders%40gmail.com
>
> This email sent to heath.bord...@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/ev%40monoceroi.com
>
> This email sent to e...@monoceroi.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

Bug in 10.6 NSPasteboard API? (was: 10.6 NSPasteboard API mixes up types?)

2012-02-27 Thread Peter 
I am still very much puzzled by the issue I described below, so I still hope to 
find a taker for it.

While the OS 10.5 API cleanly separated pasteboard types, the 10.6 API converts 
NSURL data to strings and adds it to any existing string data - i.e. when 
pasting the data into e.g. a text view in 10.6 I get

file://localhost/Users/peterjhartmann/Desktop/Eigene%20Bilder/jan.jpg
file://localhost/Users/peterjhartmann/Desktop/Eigene%20Bilder/Nob.jpg
jan
Nob

instead of 

jan
Nob

which is the result using the 10.5 API. As described, this happens no matter 
wether I use writeObjects: or setString: and no matter wether I write the URLs 
before or after the strings.

I consider this to be a bug. Am I wrong? If so, what am I doing wrong?

Does anybody use the 10.6 pasteboard API? Judging from my web searches it seems 
that almost nobody does.

One member contacted my privately stating ...

> Not sure if you've fixed this or had any other replies, but in reading it 
> through, I notice you're not declaring the pasteboard type ([pb 
> declareTypes:...]) within this block.  Does this explain the symptoms?

but declareTypes belongs to the old API. Mixing this with the new API is 
discouraged on p. 33 of Apple's PasteboardGuide106.pdf.

I'd be very happy about any pointers into the right direction.

My original post is here:

Am 19.02.2012 um 21:24 schrieb Peter:

> I am using the following code:
> 
>  NSPasteboard *pb = [NSPasteboard generalPasteboard];
> 
>  if (floor(NSAppKitVersionNumber) <= NSAppKitVersionNumber10_5) {
> //linesArray contains file paths as NSStrings
> //namesArray contains file names as NSStrings
> [pb declareTypes:[NSArray arrayWithObjects:NSFilenamesPboardType, 
> NSStringPboardType, nil] owner:nil];
> [pb setPropertyList:linesArray forType:NSFilenamesPboardType];
> [pb setString:[namesArray componentsJoinedByString:@"\n"] 
> forType:NSStringPboardType];
>  }
>  else { // >= 10.6
> //linesArray contains NSURLs
> //namesArray contains file names as NSStrings
> [pb clearContents];
> [pb setString:[namesArray componentsJoinedByString:@"\n"] 
> forType:NSPasteboardTypeString];
>   //[pb writeObjects:namesArray];
> [pb writeObjects:linesArray]; // write the URLs
> }
> 
> The 10.5 code results in distinct entities for both of the pasteboard types 
> as I expected.
> 
> type: 'public.utf8-plain-text' 
> 'aaa.bbb.ccc'
> 
> The 10.6 code results in the following:
> 
> type: 'public.utf8-plain-text'
> 'aaa.bbb.ccc.file'
> '://localhost/Use'
> 'rs/peterjhartman'
> 'n/Desktop/aaa.fl'
> 'v.file://localho'
> 'st/Users/peterjh'
> 'artmann/Desktop/'
> 'bbb.flv.file://l'
> 'ocalhost/Users/p'
> 'eterjhartmann/De'
> 'sktop/ccc.flv'
> 
> For reasons beyond my comprehension the NSURLs are converted to string data 
> behind my back and added to the existing string data, no matter wether I use 
> writeObjects or setString.
> 
> NSFilenamesPboardType contains identical property list of three file paths 
> for this example in both code branches.
> 
> ' '.0" encoding="UT'
> 'F-8"?>. ' plist PUBLIC "-'
> '//Apple//DTD PLI'
> 'ST 1.0//EN" "htt'
> 'p://www.apple.co'
> 'm/DTDs/PropertyL'
> 'ist-1.0.dtd">. 'list version="1.'
> '0">... 'ring>/Users/pete'
> 'rjhartmann/Deskt'
> 'op/aaa.flv 'ng>../Us'
> 'ers/peterjhartma'
> 'nn/Desktop/bbb.f'
> 'lv.. 'ring>/Users/pete'
> 'rjhartmann/Deskt'
> 'op/ccc.flv 'ng>.. 'tring>..'
> '. 'y>..'
> 
> Interestingly, I see file paths where I would expect file urls on 10.6.
> 
> What am I possibly doing wrong?
> How could I avoid this?
> 
> Thank you for any pointers!
> 
> Peter
> ___
> 
> 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/magnard%40web.de
> 
> This email sent to magn...@web.de
> 


___

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: [Obj-C] if (self) vs. if (self != nil)

2012-02-27 Thread Jean-Daniel Dupas 

Le 27 févr. 2012 à 02:40, Graham Cox a écrit :

> 
> On 27/02/2012, at 12:13 PM, William Squires wrote:
> 
>> I prefer the "if (self = [super init])" combined form, myself.
> 
> 
> One potentially annoying thing about this form is that, if you compile with 
> plenty of warnings on, such as the possible unintended assignment warning (if 
> not, why not?) then this flags a warning.

clang knows about this special usage, and does not warn if you don't ask it to 
be to much pedantic.

Using the 2 following flags, it will warns about assignment used as condition, 
but not for if (self = [super init])

-Wparentheses -Wno-idiomatic-parentheses


-- Jean-Daniel





___

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: [Obj-C] if (self) vs. if (self != nil)

2012-02-27 Thread Citizen 
On 27 Feb 2012, at 03:51, Preston Sumner wrote:

> On Feb 26, 2012, at 7:38 PM, Graham Cox wrote:
> 
>> 
>> On 27/02/2012, at 1:27 PM, Karl Goiser wrote:
>> 
>>> use double parentheses
>> 
>> 
>> Yes, but that's not what the poster was suggesting. I pointed out why that 
>> form is bad.
>> 
>> This is a solution, but so is Apple's recommended form.
>> 
>> --Graham
> 
> Out of curiosity, where does Apple recommend a particular form? Examples in 
> the online documentation are inconsistent in this regard.
> 
> Preston

The code snippet "Objective-C init Method" in Xcode takes this form.

i.e. 

- (id)init
{
self = [super init];
if (self) {
<#initializations#>
}
return self;
}

Dave
--
David Kennedy (http://www.zenopolis.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: Application Suite Preferences

2012-02-27 Thread Bill Cheeseman 

On Feb 27, 2012, at 2:06 AM, Seth Willits wrote:

> At any rate, I'm interested in hearing the thoughts of anyone who really 
> knows how these suite preferences should be used.


My UI Actions product  does it exactly the 
way you describe, in every particular. I wrote the first version in 2004, 
before bindings were available, and there has been no reason to rewrite it to 
try to use bindings. It works just fine.

-- 

Bill Cheeseman - b...@cheeseman.name

___

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

Was: issues using encodeWithCoder: with NSAttributedString for iOS

2012-02-27 Thread Gregory Weston 
Jens Alfke wrote:

> I don’t know of an easy workaround. Back in the day I would have suggested 
> creating a category on CGColor that adds the required archiving methods, but 
> doing this will get you rejected from the App Store.

Wait, what? Where's that documented? I haven't tried submitting something to 
the Mac App Store yet, but I've never been shy about using categories and 
that'd be a killer. Also, FWIW, I've had iOS apps that use categories (heavily) 
approved.


Greg
___

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: Was: issues using encodeWithCoder: with NSAttributedString for iOS

2012-02-27 Thread Uli Kusterer 
On 27.02.2012, at 12:11, Gregory Weston wrote:
> Jens Alfke wrote:
> 
>> I don’t know of an easy workaround. Back in the day I would have suggested 
>> creating a category on CGColor that adds the required archiving methods, but 
>> doing this will get you rejected from the App Store.
> 
> Wait, what? Where's that documented? I haven't tried submitting something to 
> the Mac App Store yet, but I've never been shy about using categories and 
> that'd be a killer. Also, FWIW, I've had iOS apps that use categories 
> (heavily) approved.


 My guess is that since CGColor is a CoreFoundation class, it'd probably 
involve some hackery to make that category work ... ?

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."


___

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

advice for new project with resizing views

2012-02-27 Thread Rick C. 
Hi,

I need to work on a project where the main window is a view that accepts drops, 
and after the drop is complete the window will expand/resize to reveal a table 
view where I will show the needed data.  An example would be this old appzapper 
app that's the first that comes to mind.  I have not done this before and just 
looking for some advice on where I might start, tutorials, sample projects, 
etc.  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

Re: Recommended way to present a font preference

2012-02-27 Thread Ross Carter 
On Feb 26, 2012, at 8:13 PM, John Brownie wrote:

> I'm rewriting an existing Carbon application with Cocoa, and am working on 
> the preferences. One preference that the user should be able to set is a 
> default font and size for text display. In the Carbon app, there is a pop-up 
> button with a font menu, and a combo box for the size. This doesn't seem to 
> be the way to do it in Cocoa, as getting a font menu pop-up is not a standard 
> thing as it was in Carbon.
> 
> So, what is the preferred way to present such a preference option?

IMHO your best option is to use 1 or 2 selectable, non-editable text fields to 
display the font name and size, and a standard button to bring up a font panel 
for choosing the font and size. The Xcode button-within-a-text-field thing is 
just goofy to me.
___

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: Was: issues using encodeWithCoder: with NSAttributedString for iOS

2012-02-27 Thread Jens Alfke 

On Feb 27, 2012, at 3:11 AM, Gregory Weston wrote:

>> I don’t know of an easy workaround. Back in the day I would have suggested 
>> creating a category on CGColor that adds the required archiving methods, but 
>> doing this will get you rejected from the App Store.
> 
> Wait, what? Where's that documented? I haven't tried submitting something to 
> the Mac App Store yet, but I've never been shy about using categories and 
> that'd be a killer. Also, FWIW, I've had iOS apps that use categories 
> (heavily) approved.

OK, never mind then. I haven’t gone through either App Store myself, and I 
must’ve misremembered about what you’re allowed or not allowed to do.

—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

sudden errors

2012-02-27 Thread H. Miersch 
hi.
my project used to build OK, until today. now xcode keeps throwing errors like 
this at me:

Unknown type name 'ViewManager'

yes, i import ViewManager.h, and no, i didn't change any declarations. is this 
a bug in Xcode? 

like i said, until sometime today this used to build ok. what am i doing wrong?


___

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: sudden errors

2012-02-27 Thread H. Miersch 

On 27. Feb 2012, at 23:01, H. Miersch wrote:

> hi.
> my project used to build OK, until today. now xcode keeps throwing errors 
> like this at me:
> 
>   Unknown type name 'ViewManager'
> 
> yes, i import ViewManager.h, and no, i didn't change any declarations. is 
> this a bug in Xcode? 
> 
> like i said, until sometime today this used to build ok. what am i doing 
> wrong?

PS. cleaning and re-building the project doesn't help, and neither does 
quitting and re-starting xcode :-(
___

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: sudden errors

2012-02-27 Thread Keary Suska 
On Feb 27, 2012, at 4:53 PM, H. Miersch wrote:

> 
> On 27. Feb 2012, at 23:01, H. Miersch wrote:
> 
>> hi.
>> my project used to build OK, until today. now xcode keeps throwing errors 
>> like this at me:
>> 
>>  Unknown type name 'ViewManager'
>> 
>> yes, i import ViewManager.h, and no, i didn't change any declarations. is 
>> this a bug in Xcode? 
>> 
>> like i said, until sometime today this used to build ok. what am i doing 
>> wrong?
> 
> PS. cleaning and re-building the project doesn't help, and neither does 
> quitting and re-starting xcode :-(

Are you saying that you have not made any changes whatsoever to the project in 
any way, nor did you change the version of Xcode you were using, but you get a 
slew of errors when you clean/compile?

Otherwise, in most cases, it is programmer error. Are the error messages you 
quote the *only* errors and warnings you are getting? Often, this type of error 
is actually cascading from other errors from an included file. I would 
eliminate all other warnings/errors first. It would also help to see the 
contents of both the ViewManager.h and one of the .m files that imports it and 
reports the error.

Best,

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

Accelerate/vDSP.h question

2012-02-27 Thread dct 
Have the vDSP functions vDSP_vabs and vDSP_vabsD recently changed?  They seem 
to be no longer working  other than to simply return an unchanged version of an 
input.

Here is a simple, Cocoa test routine I used to prove the point:
unsigned intii;
double  aa[10], bb[10]; 
for( ii=0; ii<10; ii++ ) { aa[ii]=1.1, bb[ii]=0; }
aa[1]=aa[3]=aa[6]=-2.2; 
vDSP_vabsD( aa, 1, bb, 1, 10 );
ii = 0;
with breakpoints set at the "aa[1] ..." and "ii=0" lines.

The aa array is as expected at the 1st breakpoint; unfortunately, at the 2nd 
breakpoint, the bb array matches aa rather than an absolute value version of aa.

Don Thompson

___

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: Application Suite Preferences

2012-02-27 Thread Seth Willits 
On Feb 27, 2012, at 2:24 AM, Bill Cheeseman wrote:

>> At any rate, I'm interested in hearing the thoughts of anyone who really 
>> knows how these suite preferences should be used.
> 
> My UI Actions product  does it exactly the 
> way you describe, in every particular. I wrote the first version in 2004, 
> before bindings were available, and there has been no reason to rewrite it to 
> try to use bindings. It works just fine.

Thanks. That at least provides some validation.

So I've been experimenting a variety of solutions, and I'm currently sitting 
with this and thinking about it:
https://gist.github.com/49d57bd0a61bb5e40d2d


Basically, I use a method implementation swizzle to make [NSUserDefaults 
standardUserDefaults] return an instance of my AGUserDefaults subclass. That 
allows me to override addSuite: removeSuite: and setObject:forKey: to do some 
things.

First, when a suite is added, the UD registers as an observer for distributed 
notifications using that suite name. Whenever a change is made to the suite via 
setObject:forKey:inSuite:, the notification is posted so other suite members 
will know the suite changed. 

That alone works for factored-out suite preferences. That is, apps A (com.me.a) 
and B (com.me.b) use a "com.me.sharedSuite" domain for shared prefs.

In one of my particular cases however, I really just have a background tool 
which I want to be able to easily read the main application's preferences. The 
background tool is always running however, so it needs to track changes to the 
main applications preferences *live*, not just at launch. Since the background 
tool does not have preferences of its own, a shared suite domain separate from 
the main application domain doesn't make sense. 

So to enable the application's domain to be a "suite" domain to the background 
tool, I have some special handling of the "suite" with the same name as the 
running application's identifier. This special handling includes overriding 
setObject:forKey: and removeObjectForKey: to post a suite change notification 
so that the background tool can watch changes to the main application's domain.

Since AGUserDefaults automatically forces itself to be used instead of 
NSUserDefaults (when calling [NSUserDefaults standardUserDefaults], if I 
include AGUserDefaults in shared framework, then all of my apps would start 
posting distributed notifications for suite changes when the main app's domain 
is changed. To prevent that, the posting of suite changes for the app's domain 
only happens if the application domain is registered as a suite itself via 
addSuite:. (This also allows it to receive changes notifications if the 
background tool decided to change a main app preference.)


Lastly, it's experimental and commented out in the code at the link above, but 
in the override for setObject:forKey: I added a little bit of logic which makes 
binding to a suite work implicitly. What happens is if NSUserDefaults' 
setObject:forKey: method is called and the key does not exist in the 
application domain, then it checks all of the suites. If a suite contains that 
key, then the object value is stored in the suite domain rather than the 
application domain. This lets you hook up bindings with 
NSUserDefaultsController to a suite; The one thing I haven't yet solved to 
complete bindings support, is that I need to add code which in the notification 
for a suite change, will inspect the current in-memory suite values, load the 
new values from the disk, find the ones that change, and post KVO notifications 
for them so the bindings controller will pick up on it and display the new 
values. That's actually a little more involved since I would need to maintain 
my own in-memory dictionary for each domain since there's no way to grab the 
in-memory values for a particular domain, only the on-disk ones.


Anyway, bindings experiment stuff aside, overall I think this works well. It 
basically "just happens" and seems to work fine. 


--
Seth Willits


___

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

Round corners of borderless NSWindow without set it transparent

2012-02-27 Thread Andrea3000 
I'm trying to round edges of a borderless NSWindow without having to mark it as 
transparent with setOpaque:NO.

My testbed is made only of a borderless NSWindow, its Content View and a 
regular NSView.
The NSView is subclassed to override drawRect method in order to round corners 
of the view.

Then, if I set my NSWindow non-opaque I correctly get rounded corners but the 
window becomes very slow expecially during resize. 
Therefore I'm looking for a way to mimic QuickTime X window which is (or seems 
at least) a borderless window and still has rounded corners.

I've found some tutorials online that subclass NSThemeFrame in order to draw 
the content view with rounded corners and then use the method of NSWindow: 
-setBottomCornerRounded:YES.
Unfortunately this solution works only on a regular NSWindow.

I've discovered that the Content View of a borderless NSWindow is of class 
NSNextStepFrame and not NSThemeFrame but I'm not able to go any further.
Also, -setBottomCornerRounded:YES doesn't seem to have any effect on a 
borderless window.

Have you got any hint on how can I achive what I want?

Thank you very much
Regards

Andrea
___

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 support larger NSView hierarchy?

2012-02-27 Thread Keith Knauber 
In my implementation, I know enough about my very large NSView hierarchy that 
allows me to clip and draw the
visible hierarchy very quickly.
If there was a faster way to getRectsBeingDrawn for an entire view hierarchy in 
an offscreen window,
and then reset NSWindow dirty rects needing display manually, then my divide 
and conquer strategy could
smoothly support 1000's of views in several offscreen windows that feed into 
one onscreen window NSScrollView.
My questions:
Is there a way to quickly reset needsDisplay for all views in an offscreen 
windows' hierarchy after the
viewWillDraw phase is complete, without incurring the huge overhead of actually 
drawing the hierarchy?
Most of the time my app only needs to display < 100 NSControls... However, I 
need to provide the user the option
of displaying a lot more in an NSScrollView.

Can someone at Apple explain what setNeedsDisplay:NO actually does, if anything?
( setNeedsDisplay:NO doesn't clear needsDisplay when you recurse the entire 
view hierarchy calling setNeedsDisplay:NO,
unless there's something I'm missing)
If it did, then getting the dirty rects would still be slow, but at least be 
cut in half.

The goal is to have a very responsive UI, while freeing up as much CPU as 
possible for other apps on my machine that do OpenGL drawing.
// The problem: large NSView hierarchies are very slow at doing just about 
anything, including tracking dirty rects.
//   - Cocoa takes 7ms for a hierarchy of 256 views to redraw 16 dirty views
// This equates to ~ 20% CPU usage when redrawing 30 times per second.
// unavoidable 1.5 ms spent in drawRect: (images/strings/NSFillRect)
// unavoidable 1.2 ms spent in viewWillDraw
// avoidable!  4.3 ms spent clipping, lockFocus, supporting wacky features
//   - there is no way to avoid the overhead.  things tried:
// - isOpaque.  this helps a lot, but not enough
// - layer-backed.  this helps very little, and incurs huge overhead in 
CVDisplayLink thread
// - useOptimizedDrawing.  this helps a little.

I'm faced with several choices.
  1) convert NSView hierarchy to my own hierarchy of NSCells (started going 
down this path... layout and mouse handling becomes way too cumbersome)
  2) override Cocoa private API (trying really hard to avoid this)
  3) override only public API, and use a divide and conquer strategy.  Draw 
smaller NSView hierarchies myself using getRectsBeingDrawn
   I've had some success so far with a combo of overriding a ton of public 
API to create a set of classes that
   draws my NSView hierarchy in ~3 ms instead of ~20ms.  However, I've had 
to override so much public API that I'm worried
   this won't be supported going forward.  So far it works well in both 
Snow Leopard and Lion, which is encouraging.


Below is a summary of my current solution, without posting my entire solution 
just yet.
It uses only public API.
 In a nutshell, similar to the way that NSWindow only has one NSTextView field 
editor at a time, my onscreen hierarchy only has one
 NSControl onscreen at a time (the one that the user is interacting with).
 I would not have to override so much public API if I could just get the rects 
needing display from NSWindow or NSView,
 and then tell the offscreen hierarchy that it no longer needs to be drawn (I 
tried [NSView setNeedsDisplay:NO]; of course... doesn't solve the problem)

@implementation NSControl (SkipOffscreenDraw)
- (BOOL) wantsDefaultClipping { return !sDisplayingOffscreenWindow; }
- (BOOL) canDraw
- (NSRect) convertRect:(NSRect)aRect toView:(NSView *)aView
- (NSRect) convertRect:(NSRect)aRect fromView:(NSView *)aView
- (NSRect) visibleRect
- (BOOL)isHiddenOrHasHiddenAncestor

#pragma mark -
@implementation NSOffscreenWindow
- (BOOL)canBecomeKeyWindow { return NO; }
- (BOOL)canBecomeMainWindow { return NO; }
- (BOOL)areCursorRectsEnabled { return NO; }
- (BOOL)autorecalculatesKeyViewLoop { return NO; }
- (BOOL)isVisible { return NO; }
- (void)update { return; }
- (BOOL) viewsNeedDisplay
- (NSScreen *)screen { return [NSScreen mainScreen]; }
- (void) setGraphicsContextWithView: (NSView *)iView
-(void)displayIfNeeded
- (void)setOnScreenPseudoRootView:(PseudoRootView *)iView { 
onScreenPseudoRootView = iView; }
- (void)cursorUpdate:(NSEvent *)event
- (BOOL) acceptsFirstResponder { return NO; }
- (void)invalidateCursorRectsForView:(NSView *)aView

  // an NSWindow subclass with every possible feature disabled, 
because it never draws and it's only used to track dirty rectangles.
  // Please enlighten me on a better way to achieve this.
 offscreenWindow = [[NSOffscreenWindow alloc] initWithContentRect:[self 
bounds] styleMask:NSBorderlessWindowMask backing:NSBackingStoreBuffered 
defer:YES];
 [offscreenWindow setFrameOrigin:NSMakePoint(-1, -1)]; // , 
[self bounds].size.width, [self bounds].size.height)];
 NSRect fr = [self bounds];
 [offscreenWindow setOnScreenPseudoRootVi

Re: How to support larger NSView hierarchy?

2012-02-27 Thread Graham Cox 
Jeez.

Perhaps it would be better to explain your goals, rather than fragments of an 
implementation that appears to be, on the face of it, pointless.

In a scroll view, views that are fully clipped out by the clip view, and those 
which do not intersect the dirty rects, are simply not drawn. At all. No 
drawing is faster than any other mechanism for doing drawing.

Have you simply tried adding all the controls to the document view and testing 
to see if, in fact, drawing is too slow?

Another approach to get more speed with many subviews is to use Core Animation. 
You still have all the views there for hit-testing and event handling, but 
layers are used to draw them, which should be composited more quickly than 
classic view drawing.


-getRectsBeingDrawn: isn't slow itself, but what you're doing with those rects 
probably is. Drawing tens of thousands of objects efficiently is possible 
(though if those objects are actual NSViews, all bets may be off). Basically, 
once you're over a thousand or so, you'll need to do some sort of spatial 
hashing to efficiently determine which of a set of objects needs to be drawn. 
If you are iterating a list linearly, you'll get killed by that at around the 
thousand or so mark.

--Graham




On 28/02/2012, at 11:50 AM, Keith Knauber wrote:

> In my implementation, I know enough about my very large NSView hierarchy that 
> allows me to clip and draw the
> visible hierarchy very quickly.
> If there was a faster way to getRectsBeingDrawn for an entire view hierarchy 
> in an offscreen window,
> and then reset NSWindow dirty rects needing display manually, then my divide 
> and conquer strategy could
> smoothly support 1000's of views in several offscreen windows that feed into 
> one onscreen window NSScrollView.
> My questions:
> Is there a way to quickly reset needsDisplay for all views in an offscreen 
> windows' hierarchy after the
> viewWillDraw phase is complete, without incurring the huge overhead of 
> actually drawing the hierarchy?
> Most of the time my app only needs to display < 100 NSControls... However, I 
> need to provide the user the option
> of displaying a lot more in an NSScrollView.
[]


___

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: Round corners of borderless NSWindow without set it transparent

2012-02-27 Thread Seth Willits 
On Feb 27, 2012, at 5:45 AM, Andrea3000 wrote:

> Then, if I set my NSWindow non-opaque I correctly get rounded corners but the 
> window becomes very slow expecially during resize. 

Mmm…. that doesn't sound right. You shouldn't notice anything being slow.



> Therefore I'm looking for a way to mimic QuickTime X window which is (or 
> seems at least) a borderless window and still has rounded corners.

QuickTime Player uses a custom NSFrameView. It's not a typical borderless 
window, it does private internal stuff to draw the titlebar as it pleases.



> I've found some tutorials online that subclass NSThemeFrame in order to draw 
> the content view with rounded corners and then use the method of NSWindow: 
> -setBottomCornerRounded:YES.
> Unfortunately this solution works only on a regular NSWindow.

And uses private APIs so it wouldn't work for MAS and is generally a no no.





So I posited a theory and it seems to hold true. 

This is a standard titled window, with a custom-drawn title bar using a custom 
view I simply added to the window:
http://sethwillits.com/temp/upshot/upshot_o0V3gSE1.jpg


This is *not* production code, but it proves a point. If you tweaked the 
standard window buttons to have a different look (which I belive is 
possible), then you could get closer to the QT look (which has dark shadows 
under the buttons, not light ones).



{
NSRect bounds = [[[_window contentView] superview] bounds];
BlackTitlebarView * view = [[BlackTitlebarView alloc] 
initWithFrame:bounds];
[view setAutoresizingMask:(NSViewWidthSizable | NSViewHeightSizable)];
[[[_window contentView] superview] addSubview:view 
positioned:NSWindowBelow relativeTo:_window contentView] superview] 
subviews] objectAtIndex:0]];
}



@implementation BlackTitlebarView

- (void)drawRect:(NSRect)dirtyRect
{
NSRect windowFrame   = [NSWindow frameRectForContentRect:[[[self 
window] contentView] bounds] styleMask:[[self window] styleMask]];
NSRect contentBounds = [[[self window] contentView] bounds];

NSRect titlebarRect = NSMakeRect(0, 0, self.bounds.size.width, 
windowFrame.size.height - contentBounds.size.height);
titlebarRect.origin.y = self.bounds.size.height - 
titlebarRect.size.height;

NSRect topHalf, bottomHalf;
NSDivideRect(titlebarRect, &topHalf, &bottomHalf, 
floor(titlebarRect.size.height / 2.0), NSMaxYEdge);

NSBezierPath * path = [NSBezierPath 
bezierPathWithRoundedRect:self.bounds xRadius:4.0 yRadius:4.0];
[[NSBezierPath bezierPathWithRect:titlebarRect] addClip];


NSGradient * gradient = [[[NSGradient alloc] 
initWithStartingColor:[NSColor colorWithCalibratedWhite:0.51 alpha:1.0]

   endingColor:[NSColor 
colorWithCalibratedWhite:0.21 alpha:1.0]] autorelease];


[path addClip];

[[NSColor colorWithCalibratedWhite:0.13 alpha:1.0] set];
[path fill];
[gradient drawInRect:topHalf angle:270.0];

[NSGraphicsContext saveGraphicsState];
NSAffineTransform * xfm = [NSAffineTransform transform];
[xfm translateXBy:0.0 yBy:-1.0];
[xfm concat];
[[NSColor colorWithCalibratedWhite:1.0 alpha:0.5] set];
[path setLineWidth:1.0];
[path stroke];
[NSGraphicsContext restoreGraphicsState];

[[NSColor blackColor] set];
[path setLineWidth:1.5];
[path stroke];

[[NSColor blackColor] set];
NSRectFill(NSMakeRect(0, 0, self.bounds.size.width, 1.0));
}

@end




--
Seth Willits



___

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: How to support larger NSView hierarchy?

2012-02-27 Thread Quincey Morris 
On Feb 27, 2012, at 20:46 , Graham Cox wrote:

> Jeez.

Indeed. Especially as it's usually taken as a given that large numbers of 
NSViews aren't going to perform well. Trying to make the scenario work might be 
quixotic at best.

However, two thoughts did spring to mind:

1. It might be easier (and faster) to just hide the subviews as they scroll out 
of the visibleRect, and show them as they scroll in. I'd *imagine* that lots of 
hidden views wouldn't be a big problem for drawing.

2. If the views are arranged linearly, which seems like one possible 
interpretation of the OP's scenario description, then it might be possible to 
use the new view-based NSTableView, since that configuration basically caches a 
small number of actual "cell" views even if the total number of cells is huge.


___

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