Re: Yosemite NSCollectionView appropriate for spreadsheet-like view?

[Robert Clair]

Model your spread sheet on a (hypothetical 2-D)TableView. Maintain a pool of 
cells starting with enough to cover the view at the default size plus a bit of 
margin. As cells scroll off the view return them to the pool;  as you need new 
ones get them from the pool. If the pool is empty you allocate a new one. It’s 
a bit complicated - you have to keep track of the scrolling in two directions 
and have to account for anything else that changes which cells are visible. But 
I’ve done it and it works. Unfortunately it was for a commercial client and I 
no longer have the code so I can’t share it.

…Robert

> 
> Message: 1
> Date: Tue, 03 May 2016 11:53:16 -0700
> From: Jens Alfke >
> To: thatsanicehatyouh...@me.com 
> Cc: cocoa-dev@lists.apple.com 
> Subject: Re: Yosemite NSCollectionView appropriate for
>   spreadsheet-like view?
> Message-ID:  >
> Content-Type: text/plain; charset=utf-8
> 
> 
>> On May 1, 2016, at 9:06 AM, thatsanicehatyouh...@me.com 
>>  wrote:
>> 
>> As I've been thinking about this problem it occurred to me that the new(ish) 
>> NSCollectionView might be a viable replacement in this case. Before I go 
>> down the rabbit hole, is it reasonable to use to create a spreadsheet-like 
>> view?
> 
> No, because it eagerly creates a view for every item in the collection. So if 
> you have a spreadsheet with 100,000 cells, it’s going to create 100,000 
> NSViews when the window opens.
> 
> NSMatrix may work better because it uses only a single view, but IIRC it 
> still preallocates an NSCell for every item. Also I think it’s been 
> deprecated.
> 
> I suspect you’ll need a custom view that uses cells or some other 
> lightweight-view design pattern to avoid consuming resources for items that 
> aren’t currently visible. (Of course, someone else may have already 
> implemented that custom view, either as open source or commercially.)
> 
> —Jens
___

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

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

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

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

Re: Cocoa-dev Digest, Vol 10, Issue 307

[Robert Clair]

NSData *source  = // whatever
NSRange  myRange = // whatever

NSData *subrangeOfSource = [source subdataWithRange: myRange];


On May 18, 2013, at 3:00 PM, cocoa-dev-requ...@lists.apple.com wrote:

 Send Cocoa-dev mailing list submissions to
   cocoa-dev@lists.apple.com
 
 To subscribe or unsubscribe via the World Wide Web, visit
   https://lists.apple.com/mailman/listinfo/cocoa-dev
 or, via email, send a message with subject or body 'help' to
   cocoa-dev-requ...@lists.apple.com
 
 You can reach the person managing the list at
   cocoa-dev-ow...@lists.apple.com
 
 When replying, please edit your Subject line so it is more specific
 than Re: Contents of Cocoa-dev digest...
 
 
 Today's Topics:
 
   1. Re: Trigger nextkeyview based on NSTextField input length
  (Jaime Magiera)
   2. UIView embedded in UIScrollView hides scroll indicators ?
  (Koen van der Drift)
   3. Re: UIView embedded in UIScrollView hides scroll indicators ?
  (Marcelo Alves)
   4. Re: UIView embedded in UIScrollView hides scroll indicators ?
  (Koen van der Drift)
   5. Re: UIView embedded in UIScrollView hides scroll indicators ?
  (David Duncan)
 
 
 --
 
 Message: 1
 Date: Sat, 18 May 2013 00:53:24 -0400
 From: Jaime Magiera ja...@sensoryresearch.net
 To: CocoaDev dev cocoa-dev@lists.apple.com
 Subject: Re: Trigger nextkeyview based on NSTextField input length
 Message-ID: ec829b09-95d2-4531-88bf-afa0ddf19...@sensoryresearch.net
 Content-Type: text/plain; charset=us-ascii
 
 On May 17, 2013, at 11:03 PM, Kyle Sluder k...@ksluder.com wrote:
 
 So rather than the four-field approach, why not use _one_ text field with an 
 NSFormatter subclass that adds and removes the dashes in the license code? 
 Then you get all the text handling behavior users expect for free.
 
 
 Very wise. Thanks Kyle. 
 
 Jaime Magiera
 
 Sensory Research, Inc.
 http://www.sensoryresearch.net
 
 
 
 --
 
 Message: 2
 Date: Sat, 18 May 2013 13:43:02 -0400
 From: Koen van der Drift koenvanderdr...@gmail.com
 To: Cocoa Dev cocoa-dev@lists.apple.com
 Subject: UIView embedded in UIScrollView hides scroll indicators ?
 Message-ID:
   CAF8z=hdb4mga6wiea3stj_6yp_c-01jr18cv6c1235ncxfe...@mail.gmail.com
 Content-Type: text/plain; charset=UTF-8
 
 In IB I created an UIView embedded in an UIScrollView. They both fill up
 the screen and are 320 px wide.  Scrolling works just fine, but the scroll
 indicators are invisible. I triple checked the checkboxes in IB, and both
 Scrolling Enabled and Shows Vertical Scrollers are on.  To be super
 sure I added this to my VC:
 
self.scrollView.scrollEnabled = YES;
 
self.scrollView.showsVerticalScrollIndicator = YES;
 
 I tried making the UIView a little less wide (300px), but I still don't see
 the scroll indicators.
 
 What did I miss to make them appear?
 
 Thanks,
 
 - Koen.
 
 
 --
 
 Message: 3
 Date: Sat, 18 May 2013 14:50:19 -0300
 From: Marcelo Alves marcelo.al...@me.com
 To: Cocoa Dev cocoa-dev@lists.apple.com
 Subject: Re: UIView embedded in UIScrollView hides scroll indicators ?
 Message-ID: d96ff59d-bb48-4e31-b8c7-be1a50c0d...@me.com
 Content-Type: text/plain; charset=us-ascii
 
 
 Did you forgot to set the contentSize for the UIScrollView? 
 
 
 On 18/05/2013, at 14:43, Koen van der Drift koenvanderdr...@gmail.com wrote:
 
 In IB I created an UIView embedded in an UIScrollView. They both fill up
 the screen and are 320 px wide.  Scrolling works just fine, but the scroll
 indicators are invisible. I triple checked the checkboxes in IB, and both
 Scrolling Enabled and Shows Vertical Scrollers are on.  To be super
 sure I added this to my VC:
 
   self.scrollView.scrollEnabled = YES;
 
   self.scrollView.showsVerticalScrollIndicator = YES;
 
 I tried making the UIView a little less wide (300px), but I still don't see
 the scroll indicators.
 
 What did I miss to make them appear?
 
 Thanks,
 
 - Koen.
 
 
 
 
 --
 
 Message: 4
 Date: Sat, 18 May 2013 14:28:18 -0400
 From: Koen van der Drift koenvanderdr...@gmail.com
 To: Marcelo Alves marcelo.al...@me.com
 Cc: Cocoa Dev cocoa-dev@lists.apple.com
 Subject: Re: UIView embedded in UIScrollView hides scroll indicators ?
 Message-ID:
   CAF8z=heusyktzny_uye-12cwbrqn4jh7hzepncudtoxaa+2...@mail.gmail.com
 Content-Type: text/plain; charset=UTF-8
 
 Yes, I did, but I may have made a mistake. I have this in viewDidLoad:
 
 self.scrollView.contentSize = CGSizeMake(320, self.myView.frame.size.height
 + self.tabBarController.tabBar.frame.size.height);
 
 I also found that if I add either
 
 self.scrollView.bounds = self.view.bounds;  or  self.scrollView.frame =
 self.view.frame;
 
 I do see the scrollbar, but the content myView is cut off on the right
 side.
 
 
 So, then I decided to ditch my XIB and to create the two views in my VC,
 and presto, it works!
 
 - Koen.
 
 
 On Sat, 

Garbage Collection Docs Puzzle

[Robert Clair]

The garbage collection docs section on the interior pointer issue shows this 
example:

NSData *myData = [someObject getMyData];
[myData retain];
const uint8_t *bytes = [myData bytes];
NSUInteger offset = 0, length = [myData length];
 
while (offset  length) {
  // bytes remains valid until next message sent to myData
}
[myData release];

What's with the retain and release? I understand the issue of keeping myData 
alive until you're finished with the interior pointer, but why [myData 
release]?   Is the release enough to keep myData alive even thought its 
dispatch is short circuited under GC? And the retain is there to balance the 
release in case someone executes under managed memory? Or did somebody mean 
CFRetain and CFRelease? 
It seems that [myData self] or [myData class] or some other harmless (return 
value discarded) non-sequitor might be less confusing. It would point out that 
this is an issue that is being worked around  and not an ordinary part of 
memory management.
...Bob



___

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

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

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

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

Re: Garbage Collection Docs Puzzle

[Robert Clair]

 The issue being worked-around is that of the compiler; during
 optimization, if you stop referencing myData, 
[snip]

Yes. As I said, I understand the issue - my only question was whether the 
short-circuited retain was enough to do it. I didn't know whether the compiler 
did this or the runtime. Thanks for enlightening me.

 perhaps an appropriately-named macro would be more fitting. 
Something on the order of 

_KEEP_ALIVE_( myData )

would be much more fitting and far less confusing to someone reading your code 
or a beginner reading the docs.

 Except -retain is more efficient under GC.

Probably irrelevant. Any realistic thing you would be doing with any realistic 
number of bytes in the NSData object would swamp the difference between a short 
circuited retain dispatch and a dispatch of -self.

...Bob




___

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

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

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

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

Snow Leopard turns CMYK jpegs green

[Robert Clair]

Cocoa has problems with CMYK jpegs. Going from Tiger to Leopard it  
became ambivalent about whether a CMYK pixel value of 0, 0, 0, 0 meant  
black or white. (I remember reading somewhere that there is an  
ambiguity in the jpeg standard.)


You can see this with Preview.  Get yourself a CMYK tiff file and  
convert it to jpeg using *Leopard's* Preview. Note the ugly black  
result. If you open that jpeg in other Apple apps (Mail, etc) it also  
displays as inverted. Adobe somehow can deal with files written either  
way - that jpeg will appear normal if you open it in Photoshop.


My own app writes CMYK jpegs from an NSBitmapImageRep by doing

NSData* outData =  [bitmapRep representationUsingType: NSJPEGFileType  
properties: propDict];


It showed the same issue. Since the app had to work on both Tiger and  
Leopard, I fixed the problem by writing out a tiny all-white jpeg to a  
temp file when the program starts. I then read it back in and set a  
flag based on whether what was read in matches what was written out.  
If it doesn't, I set a flag and then invert all the pixels before  
writing out a a CMYK jpeg. So far so good.


On to Snow Leopard.

Now take the CMYK tiff and convert it to jpeg on Snow Leopard. Notice  
that the result is not only inverted but what isn't totally black is  
now green. If you open this jpeg with Photoshop it is not inverted but  
it is still very green.


My app shows the same thing. Looking at the results I would guess that  
the color transform that is making it green is not reversible.


I will file a bug.

Bob Clair



___

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

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

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

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

bad behavior from unlockFocus on 10.6

[Robert Clair]

I have this piece of code in my drawing program:


 [image lockFocus];

  NSBitmapImageRep* bitmapRep =
  [[NSBitmapImageRep alloc] initWithFocusedViewRect:
  NSMakeRect( 0.0, 0.0, width, height) ];

  [image unlockFocus];

image is an NSImage with a single representation, either an  
NSBitmapImageRep containing a high resolution bitmap or an  
NSPDFImageRep. The pixels from the bitmapRep created here are  
thresholded and used to make a low resolution mask  that is held  
separately for use in picking.


This all worked fine until 10.6. The original NSImage object was left  
unmolested. But now when this code is executed, -unlockFocus  replaces  
the original representation held by the NSImage object with an  
NSCGImageSnapshotRep. There is no documentation that I can find on a  
NSCGImageSnapshotRep, but it's a bitmap.  (I assume it's a screen res  
bitmap object backed by a CGImage). This causes data loss with the  
program. If, for example, a user opens a file with a pdf object in it  
to continue working on it , and then saves the file, all the vector  
information is lost in any pdf objects is lost.


I understand that a pdf has to be rasterized for this to work. But  
since I didn't draw anything on the NSImage, I really expect this code  
to discard the temporary rasterized version when it is done and leave  
my original object unchanged.


The quick fix is easy, just save the original representation and then  
restore it. But, is this a bug or is there some point to this?


Bob Clair


___

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

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

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

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

Re: bad behavior from unlockFocus on 10.6

[Robert Clair]

Hi Ken -



 This all worked fine until 10.6. The original NSImage object was  
left unmolested.


Nope. :-)  Clearly you're seeing behavior change somewhere, but this  
attribution is not correct.


-[NSImage lockFocus] is a commonly misunderstood method.  It is and  
always has been lossy.


Not to be disputatious, but nope on your nope, for a couple of reasons:

1) If that were the case, the code wouldn't have worked for the last 5  
years.


2) The even better reason is that I just made a fresh build on a 10.5  
machine and stepped through it. The NSImage has the same single  
NSPDFImageRep after the -unlockFocus as it before the -lockFocus


By accident I may have been relying on unintended behavior but it  
definitely worked before and changed with 10.6


Bob



___

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

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

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

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

download security hanging app - It's a more general Problem + Solution

[Robert Clair]

It seems to be a more general bug with runModalForWindow:  If anything  
grabs the focus while the app is starting (i.e. something that would  
require you click on the dock icon to get the app back - which the  
warning does) the modal window never becomes visible.


I can see the same thing by starting the app from the debugger and  
clicking on a different app before the debugged app is completely up.


The work around was to move the runModalForWindow: to

- (void)applicationDidBecomeActive:(NSNotification *)aNotification

with a static guard variable so that the reg window is launched only  
the first time the app becomes active in a session.


( applicationDidBecomeActive: isn't called until you click  to get the  
app back.)


...Bob

___

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

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

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

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

download security hanging app

[Robert Clair]

I have an app that puts up a registration window if it is not
registered when it starts. (The usual 30 day buy later / by now /
enter license kind of thing.) The app is distributed by downloading a
dmg.

I put the window up with:

[NSApp runModalForWindow: licensePanel];

which is called from

- (void)applicationDidFinishLaunching:(NSNotification *)notification

The problem is (not sure when this started, it's just been reported)
that when it is started the first time after downloading, the x
is an Application which was downloaded from the internet warning
screws things up. After clicking on open the warning dismisses, but
the license window never becomes visible. Since it isn't visible, it
can't be dismissed and things are hung.

If you kill the app and start it again it runs fine.

Anybody have any ideas ?

TIA

Bob
___

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

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

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

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

Re: Remove overlap on NSBezierPath

[Robert Clair]

What the mathematicians balk at isn't the pathological cases; rather,
getting exact results.



But the real problem is that these two are related. I spent several  
years fixing the Boolean operations for a major CAD company's solid  
modeler (the long-gone ComputerVision) which is essentially the same  
problem made much more difficult by doing it in three dimensions.


The basic algorithm is conceptually simple:

1.) find all the intersections

2.) break into pieces at the intersections

3.) decide which pieces you need on the basis of some in/out tests and  
which set operation you are doing.


4.) assemble the final result

The hitch is that #3 is a bunch of yes/no decisions that you must make  
on the basis of imprecise floating point operations in #1. And all the  
results of #3 have to be consistent or #4 won't work properly. This is  
trivial in the easy cases (curves intersecting at reasonable angles,  
no tiny pieces) but *VERY* hard to get right for the arbitrary case  
(tangencies, near-tangencies, overlaps, pieces of curve that come out  
smaller than whatever numerical tolerance you are using for your  
floating point approximations, etc.). Essentially you have to have  
some checks on the final result and be prepared to fail gracefully.


RObert Clair
___

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

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

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

This email sent to [EMAIL PROTECTED]