date:20080331


You should use
-[NSBitmapImageRep   
initWithBitmapDataPlanes:pixelsWide:pixelsHigh:bitsPerSample:samplesPerPixel:hasAlpha:isPlanar:colorSpaceName:bitmapFormat:bytesPerRow:bitsPerPixel 
:]

to initialize your bitmap.

A bitmap representation initialized using -initForIncrementalLoad  
expects that you call -incrementalLoadFromData:complete:




Le 31 mars 08 à 15:54, Eddie Hebert a écrit :
I have a need to store and draw an image that I create iteratively  
over each pixel.

I am trying to use NSBitmapImageRep with setColor: x: y:, to do so.

Within the constructor of my "rendering engine" class, I instantiate  
a NSBitmapImageRep, thusly:


_imageRep = [[NSBitmapImageRep alloc] initForIncrementalLoad];
[_imageRep setSize:NSMakeSize(aWidth, aHeight)];
[_imageRep setPixelsWide:aWidth];
[_imageRep setPixelsHigh:aHeight];
[_imageRep setColorSpaceName:@"NSDeviceRGBColorSpace"];
[_imageRep setAlpha:NO];

Then in the main loop of my engine I call, [_imageRep setColor:color  
atX:col y:row]


When I do so I get the error:

Mon Mar 31 09:41:41 ***.local Ray Tracer[15727] :  
CGImageSourceCopyPropertiesAtIndex image source parameter is nil\n
Mon Mar 31 09:41:41 ***.local Ray Tracer[15727] :  
CGImageSourceCreateImageAtIndex image source parameter is nil\n
Mon Mar 31 09:41:41 ***.local Ray Tracer[15727] :  
CGImageSourceCopyPropertiesAtIndex image source parameter is nil\n
Mon Mar 31 09:41:41 ***.local Ray Tracer[15727] :  
CGImageSourceCreateImageAtIndex image source parameter is nil\n


And when I call [_imageRep colorAtX:col y:row], I get back  
NSDeviceRGBColorSpace 1 1 1 1, which is not the NSColor that I sent  
it.


Is there some parameter/property of NSBitmapImageRep that I am not  
setting that is causing these errors?

Or does this have something to do with not locking properly?

Thanks in advance,
Ed Hebert Jr.
___

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/devlists%40shadowlab.org

This email sent to [EMAIL PROTECTED]



___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: Spaces Implementation

2008-03-31 Thread Mike Abdullah

Spaces is a feature of the OS, not a standard application. There is no  
public API for re-creating it.


Mike.

On 31 Mar 2008, at 14:31, Apparao Mulpuri wrote:


Hi List,

  I am interested to develop a sample application, which will work
like Spaces functionality.

 Any pointers on how it was implemented?

Thanks & Regards,
- Apparao.
___

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/cocoadev%40mikeabdullah.net

This email sent to [EMAIL PROTECTED]


___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: Writing x, y to NSBitmapImageRep

2008-03-31 Thread Eddie Hebert

It appears to be properly storing the values, through inspection from  
NSLog and colorAt.
The next step is drawing, I am trying to show incremental updates of  
the progress of the render engine,
within the drawRect method of an NSImageView I am calling (at an  
interval based on NSTimer)


[[self image] drawRepresentation:rayTracer.imageRep inRect:rect];

I have set up the image by using

[self setImage:[[NSImage alloc] initWithSize:rect.size]];
[[self image] setCacheMode:NSImageCacheNever];

Is this an issue now of not using [NSGraphicsContext saveState], etc.?

merci beaucop

On Mar 31, 2008, at 10:02 AM, Jean-Daniel Dupas wrote:


You should use
-[NSBitmapImageRep   
initWithBitmapDataPlanes:pixelsWide:pixelsHigh:bitsPerSample:samplesPerPixel:hasAlpha:isPlanar:colorSpaceName:bitmapFormat:bytesPerRow:bitsPerPixel 
:]

to initialize your bitmap.

A bitmap representation initialized using -initForIncrementalLoad  
expects that you call -incrementalLoadFromData:complete:




Le 31 mars 08 à 15:54, Eddie Hebert a écrit :
I have a need to store and draw an image that I create iteratively  
over each pixel.

I am trying to use NSBitmapImageRep with setColor: x: y:, to do so.

Within the constructor of my "rendering engine" class, I  
instantiate a NSBitmapImageRep, thusly:


_imageRep = [[NSBitmapImageRep alloc] initForIncrementalLoad];
[_imageRep setSize:NSMakeSize(aWidth, aHeight)];
[_imageRep setPixelsWide:aWidth];
[_imageRep setPixelsHigh:aHeight];
[_imageRep setColorSpaceName:@"NSDeviceRGBColorSpace"];
[_imageRep setAlpha:NO];

Then in the main loop of my engine I call, [_imageRep  
setColor:color atX:col y:row]


When I do so I get the error:

Mon Mar 31 09:41:41 ***.local Ray Tracer[15727] :  
CGImageSourceCopyPropertiesAtIndex image source parameter is nil\n
Mon Mar 31 09:41:41 ***.local Ray Tracer[15727] :  
CGImageSourceCreateImageAtIndex image source parameter is nil\n
Mon Mar 31 09:41:41 ***.local Ray Tracer[15727] :  
CGImageSourceCopyPropertiesAtIndex image source parameter is nil\n
Mon Mar 31 09:41:41 ***.local Ray Tracer[15727] :  
CGImageSourceCreateImageAtIndex image source parameter is nil\n


And when I call [_imageRep colorAtX:col y:row], I get back  
NSDeviceRGBColorSpace 1 1 1 1, which is not the NSColor that I sent  
it.


Is there some parameter/property of NSBitmapImageRep that I am not  
setting that is causing these errors?

Or does this have something to do with not locking properly?

Thanks in advance,
Ed Hebert Jr.
___

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/devlists%40shadowlab.org

This email sent to [EMAIL PROTECTED]




___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: Writing x, y to NSBitmapImageRep



NSBitmapImageRep is a subclass of NSImageRep, and so, it responds to - 
draw, -drawAtPoint: and -drawInRect:.


Maybe trying to directly draw the bitmap representation will avoid  
caching and other NSImage optimization issues.


[rayTracer.imageRep drawInrect:rect];


Le 31 mars 08 à 16:21, Eddie Hebert a écrit :
It appears to be properly storing the values, through inspection  
from NSLog and colorAt.
The next step is drawing, I am trying to show incremental updates of  
the progress of the render engine,
within the drawRect method of an NSImageView I am calling (at an  
interval based on NSTimer)


[[self image] drawRepresentation:rayTracer.imageRep inRect:rect];

I have set up the image by using

[self setImage:[[NSImage alloc] initWithSize:rect.size]];
[[self image] setCacheMode:NSImageCacheNever];

Is this an issue now of not using [NSGraphicsContext saveState], etc.?

merci beaucop

On Mar 31, 2008, at 10:02 AM, Jean-Daniel Dupas wrote:


You should use
-[NSBitmapImageRep   
initWithBitmapDataPlanes:pixelsWide:pixelsHigh:bitsPerSample:samplesPerPixel:hasAlpha:isPlanar:colorSpaceName:bitmapFormat:bytesPerRow:bitsPerPixel 
:]

to initialize your bitmap.

A bitmap representation initialized using -initForIncrementalLoad  
expects that you call -incrementalLoadFromData:complete:




Le 31 mars 08 à 15:54, Eddie Hebert a écrit :
I have a need to store and draw an image that I create iteratively  
over each pixel.

I am trying to use NSBitmapImageRep with setColor: x: y:, to do so.

Within the constructor of my "rendering engine" class, I  
instantiate a NSBitmapImageRep, thusly:


_imageRep = [[NSBitmapImageRep alloc] initForIncrementalLoad];
[_imageRep setSize:NSMakeSize(aWidth, aHeight)];
[_imageRep setPixelsWide:aWidth];
[_imageRep setPixelsHigh:aHeight];
[_imageRep setColorSpaceName:@"NSDeviceRGBColorSpace"];
[_imageRep setAlpha:NO];

Then in the main loop of my engine I call, [_imageRep  
setColor:color atX:col y:row]


When I do so I get the error:

Mon Mar 31 09:41:41 ***.local Ray Tracer[15727] :  
CGImageSourceCopyPropertiesAtIndex image source parameter is nil\n
Mon Mar 31 09:41:41 ***.local Ray Tracer[15727] :  
CGImageSourceCreateImageAtIndex image source parameter is nil\n
Mon Mar 31 09:41:41 ***.local Ray Tracer[15727] :  
CGImageSourceCopyPropertiesAtIndex image source parameter is nil\n
Mon Mar 31 09:41:41 ***.local Ray Tracer[15727] :  
CGImageSourceCreateImageAtIndex image source parameter is nil\n


And when I call [_imageRep colorAtX:col y:row], I get back  
NSDeviceRGBColorSpace 1 1 1 1, which is not the NSColor that I  
sent it.


Is there some parameter/property of NSBitmapImageRep that I am not  
setting that is causing these errors?

Or does this have something to do with not locking properly?

Thanks in advance,
Ed Hebert Jr.
___

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/devlists%40shadowlab.org

This email sent to [EMAIL PROTECTED]






___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: Writing x, y to NSBitmapImageRep

2008-03-31 Thread Eddie Hebert


That worked! Thanks again.

On Mar 31, 2008, at 10:42 AM, Jean-Daniel Dupas wrote:



NSBitmapImageRep is a subclass of NSImageRep, and so, it responds to  
-draw, -drawAtPoint: and -drawInRect:.


Maybe trying to directly draw the bitmap representation will avoid  
caching and other NSImage optimization issues.


[rayTracer.imageRep drawInrect:rect];


Le 31 mars 08 à 16:21, Eddie Hebert a écrit :
It appears to be properly storing the values, through inspection  
from NSLog and colorAt.
The next step is drawing, I am trying to show incremental updates  
of the progress of the render engine,
within the drawRect method of an NSImageView I am calling (at an  
interval based on NSTimer)


[[self image] drawRepresentation:rayTracer.imageRep inRect:rect];

I have set up the image by using

[self setImage:[[NSImage alloc] initWithSize:rect.size]];
[[self image] setCacheMode:NSImageCacheNever];

Is this an issue now of not using [NSGraphicsContext saveState],  
etc.?


merci beaucop

On Mar 31, 2008, at 10:02 AM, Jean-Daniel Dupas wrote:


You should use
-[NSBitmapImageRep   
initWithBitmapDataPlanes:pixelsWide:pixelsHigh:bitsPerSample:samplesPerPixel:hasAlpha:isPlanar:colorSpaceName:bitmapFormat:bytesPerRow:bitsPerPixel 
:]

to initialize your bitmap.

A bitmap representation initialized using -initForIncrementalLoad  
expects that you call -incrementalLoadFromData:complete:




Le 31 mars 08 à 15:54, Eddie Hebert a écrit :
I have a need to store and draw an image that I create  
iteratively over each pixel.

I am trying to use NSBitmapImageRep with setColor: x: y:, to do so.

Within the constructor of my "rendering engine" class, I  
instantiate a NSBitmapImageRep, thusly:


_imageRep = [[NSBitmapImageRep alloc] initForIncrementalLoad];
[_imageRep setSize:NSMakeSize(aWidth, aHeight)];
[_imageRep setPixelsWide:aWidth];
[_imageRep setPixelsHigh:aHeight];
[_imageRep setColorSpaceName:@"NSDeviceRGBColorSpace"];
[_imageRep setAlpha:NO];

Then in the main loop of my engine I call, [_imageRep  
setColor:color atX:col y:row]


When I do so I get the error:

Mon Mar 31 09:41:41 ***.local Ray Tracer[15727] :  
CGImageSourceCopyPropertiesAtIndex image source parameter is nil\n
Mon Mar 31 09:41:41 ***.local Ray Tracer[15727] :  
CGImageSourceCreateImageAtIndex image source parameter is nil\n
Mon Mar 31 09:41:41 ***.local Ray Tracer[15727] :  
CGImageSourceCopyPropertiesAtIndex image source parameter is nil\n
Mon Mar 31 09:41:41 ***.local Ray Tracer[15727] :  
CGImageSourceCreateImageAtIndex image source parameter is nil\n


And when I call [_imageRep colorAtX:col y:row], I get back  
NSDeviceRGBColorSpace 1 1 1 1, which is not the NSColor that I  
sent it.


Is there some parameter/property of NSBitmapImageRep that I am  
not setting that is causing these errors?

Or does this have something to do with not locking properly?

Thanks in advance,
Ed Hebert Jr.
___

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/devlists%40shadowlab.org

This email sent to [EMAIL PROTECTED]







___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: Returning values from objc_msgSend etc

2008-03-31 Thread Sherm Pendley

On Sat, Mar 1, 2008 at 9:00 AM, Greg Parker <[EMAIL PROTECTED]> wrote:

libffi is smart enough to know about all of the ABI rules. If your ffi_types
> correctly describe the method's parameters, then libffi will marshal them
> properly. (If it doesn't, then that's a libffi bug.)
>
> I don't think libffi does any type promotion.
>

Indeed not - the sample below prints different results when run on PPC
(including Rosetta) and i386. On PPC, only the promoted version returns the
correct result. On Intel, both of them do. The question then, becomes -
should libffi be handling this difference transparently?

sherm--

#include 

#define MACOSX
#include 

char getCharFunction() {
return 5;
}

int main (int argc, const char * argv[]) {
ffi_cif cif_nopromote;
ffi_cif cif_promote;

long returnLongValue;
char returnCharValue;

if (ffi_prep_cif( &cif_nopromote,
  FFI_DEFAULT_ABI,
  0,
  &ffi_type_schar,
  NULL
  )
!= FFI_OK ) {
printf("%s", "Error creating ffi cif_nopromote\n");
return 1;
}

if (ffi_prep_cif( &cif_promote,
  FFI_DEFAULT_ABI,
  0,
  &ffi_type_slong,
  NULL
  )
!= FFI_OK ) {
printf("%s", "Error creating ffi cif_promote\n");
return 1;
}

ffi_call(&cif_nopromote,
 (void(*)(void))getCharFunction,
 &returnCharValue,
 NULL
 );
printf("Return value from cif_nopromote is %d.\n", returnCharValue);

ffi_call(&cif_promote,
 (void(*)(void))getCharFunction,
 &returnLongValue,
 NULL
 );
printf("Return value from cif_promote is %d.\n", returnLongValue);

return 0;
}



>
>
> --
> Greg Parker [EMAIL PROTECTED] Runtime Wrangler
>
>
>
___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: Returning values from objc_msgSend etc

2008-03-31 Thread Sherm Pendley

On Sat, Mar 1, 2008 at 9:00 AM, Greg Parker <[EMAIL PROTECTED]> wrote:

libffi is smart enough to know about all of the ABI rules. If your ffi_types
> correctly describe the method's parameters, then libffi will marshal them
> properly. (If it doesn't, then that's a libffi bug.)
>
> I don't think libffi does any type promotion.
>

Indeed not - the sample below prints different results when run on PPC
(including Rosetta) and i386. On PPC, only the promoted version returns the
correct result. On Intel, both of them do. The question then, becomes -
should libffi be handling this difference transparently?

sherm--

#include 

#define MACOSX
#include 

char getCharFunction() {
return 5;
}

int main (int argc, const char * argv[]) {
ffi_cif cif_nopromote;
ffi_cif cif_promote;

long returnLongValue;
char returnCharValue;

if (ffi_prep_cif( &cif_nopromote,
  FFI_DEFAULT_ABI,
  0,
  &ffi_type_schar,
  NULL
  )
!= FFI_OK ) {
printf("%s", "Error creating ffi cif_nopromote\n");
return 1;
}

if (ffi_prep_cif( &cif_promote,
  FFI_DEFAULT_ABI,
  0,
  &ffi_type_slong,
  NULL
  )
!= FFI_OK ) {
printf("%s", "Error creating ffi cif_promote\n");
return 1;
}

ffi_call(&cif_nopromote,
 (void(*)(void))getCharFunction,
 &returnCharValue,
 NULL
 );
printf("Return value from cif_nopromote is %d.\n", returnCharValue);

ffi_call(&cif_promote,
 (void(*)(void))getCharFunction,
 &returnLongValue,
 NULL
 );
printf("Return value from cif_promote is %d.\n", returnLongValue);

return 0;
}



>
>
> --
> Greg Parker [EMAIL PROTECTED] Runtime Wrangler
>
>
>
___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: Returning values from objc_msgSend etc


returnCharValue  is not a valid argument for ffi_call

man ffi_call

void ffi_call(ffi_cif *cif, void (*fn)(void), void *rvalue, void  
**avalue);
 rvalue must point to storage that is sizeof(long) or larger. For  
smaller
 return value sizes, the ffi_arg or ffi_sarg integral type must  
be used to

 hold the return value

Le 31 mars 08 à 17:34, Sherm Pendley a écrit :


On Sat, Mar 1, 2008 at 9:00 AM, Greg Parker <[EMAIL PROTECTED]> wrote:

libffi is smart enough to know about all of the ABI rules. If your  
ffi_types
correctly describe the method's parameters, then libffi will  
marshal them

properly. (If it doesn't, then that's a libffi bug.)

I don't think libffi does any type promotion.



Indeed not - the sample below prints different results when run on PPC
(including Rosetta) and i386. On PPC, only the promoted version  
returns the
correct result. On Intel, both of them do. The question then,  
becomes -

should libffi be handling this difference transparently?

sherm--

#include 

#define MACOSX
#include 

char getCharFunction() {
   return 5;
}

int main (int argc, const char * argv[]) {
   ffi_cif cif_nopromote;
   ffi_cif cif_promote;

   long returnLongValue;
   char returnCharValue;

   if (ffi_prep_cif( &cif_nopromote,
 FFI_DEFAULT_ABI,
 0,
 &ffi_type_schar,
 NULL
 )
   != FFI_OK ) {
   printf("%s", "Error creating ffi cif_nopromote\n");
   return 1;
   }

   if (ffi_prep_cif( &cif_promote,
 FFI_DEFAULT_ABI,
 0,
 &ffi_type_slong,
 NULL
 )
   != FFI_OK ) {
   printf("%s", "Error creating ffi cif_promote\n");
   return 1;
   }

   ffi_call(&cif_nopromote,
(void(*)(void))getCharFunction,
&returnCharValue,
NULL
);
   printf("Return value from cif_nopromote is %d.\n",  
returnCharValue);


   ffi_call(&cif_promote,
(void(*)(void))getCharFunction,
&returnLongValue,
NULL
);
   printf("Return value from cif_promote is %d.\n", returnLongValue);

   return 0;
}






--
Greg Parker [EMAIL PROTECTED] Runtime Wrangler




___

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/devlists%40shadowlab.org

This email sent to [EMAIL PROTECTED]



___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: Spaces Implementation

On Mon, Mar 31, 2008 at 3:06 PM, Mike Abdullah
<[EMAIL PROTECTED]> wrote:

> Spaces is a feature of the OS, not a standard application. There is no
>  public API for re-creating it.

However, there is an effort to reverse-engineer the private API:

http://www.cocoadev.com/index.pl?CoreGraphicsPrivate

Hamish
___

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]

Question on bitmap fonts

2008-03-31 Thread Tobia Conforto

Hello

After 1000 messages to this list and no reply, I'm resubmitting my
question about bitmap fonts, hoping to get any bit of help or any
pointer at all (docs, other mailing lists, etc.)

Basically, I would like to know what are the best practices and
recommended programs for preparing bitmap fonts for use in Cocoa
applications. I'm also reporting what is probably a bug in either OS
X or the available font editors.

If there is a list better suited to this question, please point me to
it.

I'm trying to convert the well known X11 fixed unicode fonts to a
format usable in Cocoa text editors and terminal programs. These
fonts are available under a free license on Markus Kuhn's website: http://www.cl.cam.ac.uk/~mgk25/ucs-fonts.html
and are provided in source BDF format.

I tried using the free editor Fontforge to convert 9x18.bdf into a so-
called (by Fontforge) "Apple bitmap-only .dfont" format. Mostly it
works, but I've run into a problem that Fontforge's programmers can't
solve. See this thread on their list:

http://www.nabble.com/BDF-to-Apple-bitmap-only-dfont,-wrong-line-height-td15155775.html

The problem is that the generated dfont is rendered by OS X with 4px
of additional ascent (or line-height) and we can't figure out where it
comes from. If I convert only the ASCII subset of the original
Unicode font, the line-height is correct. As soon as I add more than
a couple of non-ASCII characters, the 4px bug comes out.

I tried doing the same conversion using a trial version of the
commercial BitFonter 3.0 editor ($500) and I got the same results as
with Fontforge.

I looked into the .dfont file with a hex editor, using this manual as
a reference http://developer.apple.com/textfonts/TTRefMan/ but I
couldn't find anything out of place.

Here is a zip http://gruppo4.com/~tobia/osx-font-problem.zip where
I've put two OS X dfont files I created from 9x18.bdf, using
Fontforge, plus a text file with the font tables I extracted using the
hex editor.
In "test3" I converted the full Latin 1 charset (Unicode points < 256)
and it shows the 4px bug; in "test7" I deleted all glyphs other than
ASCII and a couple of Latin 1 accented letters, and it displays
correctly in all Cocoa apps.

What am I doing wrong? What's different in the two files? Can you
replicate this bug? Is this a bug in OS X, a weird setting in the
original BDF, or a bug shared between Fontforge and BitFonter?

Can you think of any workaround or alternative program I could try?

Tobia
___

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]

Main Thread UI and Detached Thread

I have all my UI running on my app's main thread. I have a worker thread 
that I detach with detachNewThreadSelector:toTarget:withObject: (my 
worker thread).


In my worker thread I do a tight processing loop and one of the things I 
do in the loop is call two methods in the main thread to update the 
display (a text message and progress bar) - via 
performSelectorOnMainThread:withObject:waitUntilDone:modes.


However, when the loop runs in the spawned thread, the display doesn't 
get updated. If I insert a sleep(1) call into the loop, then the display 
 updates.


Why doesn't the main thread process the changes to the UI unless I call 
sleep? I thought the whole idea of using a separate thread was so that 
the main thread could continue to run on its own?


Thanks,

Mike



___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: Main Thread UI and Detached Thread



On Mar 30, 2008, at 11:55 AM, Mike wrote:
In my worker thread I do a tight processing loop and one of the  
things I do in the loop is call two methods in the main thread to  
update the display (a text message and progress bar) - via  
performSelectorOnMainThread:withObject:waitUntilDone:modes.


However, when the loop runs in the spawned thread, the display  
doesn't get updated. If I insert a sleep(1) call into the loop, then  
the display  updates.



How much work do you perform on the main thread? If a lot, it's not  
unexpected that you would se interruptions in display updates. You  
might need to throttle or otherwise limit your callouts to the main  
thread if this proves to be the problem.


You can use Instruments or Shark to get a view of the work being  
performed on the main thread while you run your worker thread.


j o a r


___

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]

core data and sqlite db store problem

2008-03-31 Thread Scott Guyer


Hi,

  I'm just learning core data and have already stumbled on  
something.  I created a CD application using the XCode template.  I've  
created a sqlite3 .db file with data and a matching core data model in  
xcode.  My code fails here...


url = [NSURL fileURLWithPath: [applicationSupportFolder  
stringByAppendingPathComponent: @"my.db"]];
persistentStoreCoordinator = [[NSPersistentStoreCoordinator  
alloc] initWithManagedObjectModel: [self managedObjectModel]];
if (![persistentStoreCoordinator  
addPersistentStoreWithType:NSSQLiteStoreType configuration:nil URL:url  
options:nil error:&error]){

[[NSApplication sharedApplication] presentError:error];
}

with an error saying that the db file cannot be opened because it is  
not in the right format.  "The file might be corrupted, truncated, or  
in a different format than you expect."  That's quite odd to me, since  
I can interact with that db file on the command line using sqlite3  
just fine.  Anyone have any ideas/suggestions?


Much appreciated!

___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: Spaces Implementation

2008-03-31 Thread Andrew Merenbach


Hi,

I do believe, however, that reverse-engineering talk is off-limits for  
this list -- someone correct me if I'm wrong?


Cheers,
Andrew

On Mar 31, 2008, at 8:57 AM, Hamish Allan wrote:


On Mon, Mar 31, 2008 at 3:06 PM, Mike Abdullah
<[EMAIL PROTECTED]> wrote:

Spaces is a feature of the OS, not a standard application. There is  
no

public API for re-creating it.


However, there is an effort to reverse-engineer the private API:

http://www.cocoadev.com/index.pl?CoreGraphicsPrivate

Hamish
___

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/andrew.merenbach%40ucla.edu

This email sent to [EMAIL PROTECTED]


___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: Main Thread UI and Detached Thread

2008-03-31 Thread Hank Heijink (Mailinglists)

Just checking the obvious here - is it possible that your worker  
thread completes its work so fast that the main run loop hasn't  
updated the screen once before it's done? Keep in mind that the main  
thread has to display your window with the progress bar and the text  
and (depending on your implementation) that your worker thread may be  
working (and completing) while that's being done.


On Mar 30, 2008, at 2:55 PM, Mike wrote:
I have all my UI running on my app's main thread. I have a worker  
thread that I detach with  
detachNewThreadSelector:toTarget:withObject: (my worker thread).


In my worker thread I do a tight processing loop and one of the  
things I do in the loop is call two methods in the main thread to  
update the display (a text message and progress bar) - via  
performSelectorOnMainThread:withObject:waitUntilDone:modes.


However, when the loop runs in the spawned thread, the display  
doesn't get updated. If I insert a sleep(1) call into the loop, then  
the display  updates.


Why doesn't the main thread process the changes to the UI unless I  
call sleep? I thought the whole idea of using a separate thread was  
so that the main thread could continue to run on its own?


Thanks,

Mike



___

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/hank.list 
%40runbox.com


This email sent to [EMAIL PROTECTED]



___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: core data and sqlite db store problem

2008-03-31 Thread Jeff LaMarche

Core data stores metadata as well as data in the sqlite3 file and  
follows a very specific naming convention for the regular data tables  
and columns. You'd probably be better off writing a small migration  
utility to import the data you need than to try create a sqlite3  
database in the right format. Also, if you use this mechanism, when  
you distribute your app, none of that data will go with it.


Why don't you move out your sqlite3 file and let it create a new one,  
then go in and look at the tables and structure, and you'll get an  
idea of what I'm talking about.


HTH
Jeff
On Mar 31, 2008, at 12:45 PM, Scott Guyer wrote:


Hi,

 I'm just learning core data and have already stumbled on  
something.  I created a CD application using the XCode template.   
I've created a sqlite3 .db file with data and a matching core data  
model in xcode.  My code fails here...


   url = [NSURL fileURLWithPath: [applicationSupportFolder  
stringByAppendingPathComponent: @"my.db"]];
   persistentStoreCoordinator = [[NSPersistentStoreCoordinator  
alloc] initWithManagedObjectModel: [self managedObjectModel]];
   if (![persistentStoreCoordinator  
addPersistentStoreWithType:NSSQLiteStoreType configuration:nil  
URL:url options:nil error:&error]){

   [[NSApplication sharedApplication] presentError:error];
   }

with an error saying that the db file cannot be opened because it is  
not in the right format.  "The file might be corrupted, truncated,  
or in a different format than you expect."  That's quite odd to me,  
since I can interact with that db file on the command line using  
sqlite3 just fine.  Anyone have any ideas/suggestions?


Much appreciated!

___

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/jeff_lamarche%40mac.com

This email sent to [EMAIL PROTECTED]


___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: Movable by window background AND custom NSView

2008-03-31 Thread patrick machielse


Op 31 mrt 2008, om 09:52 heeft vance het volgende geschreven:

I have a Textured Window with a NSView that has some custom drawing  
done in drawRect.


When I click and drag outside the custom NSView
The window moves
(That is exactly what is needed)

When I click and drag within the custom NSView
The window moves
The custom NSView receives the mouseDragged messages

Since I am overriding mouseDragged (and most other mouse related  
messages in NSResponder) I would expect for the custom NSView to  
only receive the messages and since I am not calling [super  
mouseX]; the message should not get outside the NSView therefore  
the window should not move.


Clearly that is now what happens. The window moves when I click and  
drag within the custom view which is something we dont want to happen.


Does anyone understands what is the flow of mouse events and what to  
do to get around this?


The solution is to subclass NSControl instead of NSView. NSWindow  
seems to check for the type of your 'control' like view when it is  
movable by its background. If the drag event did not occur over an  
NSContol type object it will move itself. It baffled me too at first,  
but there is some logic to it.


patrick
___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: Returning values from objc_msgSend etc

2008-03-31 Thread Greg Parker


On Mar 31, 2008, at 8:34 AM, Sherm Pendley wrote:

On Sat, Mar 1, 2008 at 9:00 AM, Greg Parker <[EMAIL PROTECTED]> wrote:
libffi is smart enough to know about all of the ABI rules. If your  
ffi_types correctly describe the method's parameters, then libffi  
will marshal them properly. (If it doesn't, then that's a libffi  
bug.)


I don't think libffi does any type promotion.


Indeed not - the sample below prints different results when run on  
PPC (including Rosetta) and i386. On PPC, only the promoted version  
returns the correct result. On Intel, both of them do. The question  
then, becomes - should libffi be handling this difference  
transparently?


ffi_call(3) says:
"rvalue must point to storage that is sizeof(long) or larger. For  
smaller return value sizes, the ffi_arg or ffi_sarg integral type must  
be used to hold the return value."




char returnCharValue;

ffi_call(&cif_nopromote,
 (void(*)(void))getCharFunction,
 &returnCharValue,
 NULL
 );
printf("Return value from cif_nopromote is %d.\n",  
returnCharValue);


...which means this isn't allowed. In fact, it's probably smashing  
memory on your stack.



--
Greg Parker [EMAIL PROTECTED] Runtime Wrangler


___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: simple table column bindings

2008-03-31 Thread Gareth Davis


thank you. That works just great now.

Gareth
On 30 Mar 2008, at 23:58, Milen Dzhumerov wrote:

Hi Gareth,

There were a couple of problems.

1) You should be calling [movements addObject:m] instead of  
[movements add:m]
2) You should set the class which the array controller manages in IB  
to Movement (the Classname text field)


After doing this, it all works.

Regards,
Milen

On 30 Mar 2008, at 22:42, Gareth Davis wrote:

hi,

I'm having some trouble with completing a simple proof of concept  
app. The requirement is to process a simple xml document and  
display the results in a two column table.


I've managed to load the xml and parse what I need from it into a  
bunch of "Movement" objects which I attempt to add to a  
NSArrayController. My table actually displays three records but  
only with the null placeholder. Some where along the lines the  
bindings I've specified for the two table columns are broken.


If any of you have 5 minutes a copy of my project is available at:

http://web.mac.com/gareth.davis/Misc/cocoa-dev/SignsDesktop1.tar.gz

(You'll have to forgive the "Foo" class, it seemed like a good name  
for the class a couple of days ago)


The app it's self is pretty simple, clicking the "load" button  
should populate the table with the data using the example.xml  
resource.


Any help would be gratefully received.

Thanks in advance
Gareth Davis

___

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/md207%40doc.ic.ac.uk

This email sent to [EMAIL PROTECTED]




___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: Movable by window background AND custom NSView

2008-03-31 Thread Michael Ash

On Mon, Mar 31, 2008 at 12:59 PM, patrick machielse <[EMAIL PROTECTED]> wrote:
> Op 31 mrt 2008, om 09:52 heeft vance het volgende geschreven:
>
>
>  > I have a Textured Window with a NSView that has some custom drawing
>  > done in drawRect.
>  >
>  > When I click and drag outside the custom NSView
>  >   The window moves
>  >   (That is exactly what is needed)
>  >
>  > When I click and drag within the custom NSView
>  >   The window moves
>  >   The custom NSView receives the mouseDragged messages
>  >
>  > Since I am overriding mouseDragged (and most other mouse related
>  > messages in NSResponder) I would expect for the custom NSView to
>  > only receive the messages and since I am not calling [super
>  > mouseX]; the message should not get outside the NSView therefore
>  > the window should not move.
>  >
>  > Clearly that is now what happens. The window moves when I click and
>  > drag within the custom view which is something we dont want to happen.
>  >
>  > Does anyone understands what is the flow of mouse events and what to
>  > do to get around this?
>
>  The solution is to subclass NSControl instead of NSView.

Actually the solution is to override -mouseDownCanMoveWindow to return
whatever is appropriate for your view.

Mike
___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: Subverting the first responder chain

2008-03-31 Thread John Stiles

No problem. I'd rather have 90% good info and a bit of confusion than no 
response at all :)


I've filed a radar:
rdar://5831739 [Cocoa]Hotkey matching works differently for menu 
items that use the Command key


The root of the problem is really in the docs which you posted earlier. 
They say that NSApplication does early matching of potential key 
equivalents by checking for the presence of modifier flags. But the 
problem with this logic is that "potential key equivalents" has nothing 
to do with "the presence of modifier flags". Anything can be a key 
equivalent.



Allen Smith wrote:

I'm sorry, my memory seems to have gotten muddled since I investigated this
issue. Upon revisiting my old test program, I realized -[super keyDown:]
*will* ultimately trigger menu items, barring weird issues like a superclass
or higher responder that intercepts the key. Apparently I believed that the
message to super didn't work precisely because the next responder in my main
application was accidentally swallowing all keyDowns. I apologize for the
misinformation, but thank you for helping me find a bug.

Allen


-Original Message-
From: John Stiles [mailto:[EMAIL PROTECTED]
Sent: Fri 3/28/2008 2:35 PM
To: Allen Smith
Cc: cocoa dev
Subject: Re: Subverting the first responder chain
 
I did a test and if I call

[[self nextResponder] keyDown:theEvent];

from inside the -keyDown: method, it does in fact trigger the 
appropriate hotkey on the menu. (On the other hand, the documentation 
recommends your technique of handing off to super here:

http://developer.apple.com/documentation/Cocoa/Conceptual/EventOverview/Event

HandlingBasics/chapter_4_section_2.html
which is probably a good idea if you want your view's superclass to take 
a stab at the event, but in this case I have no interest in doing that. 
I want the menu bar to get the event, not any views in the middle.)


So now I "just" keep a hash table of all the application's hotkeys and 
query that at the top of -keyDown:. If the pressed key matches, I punt 
the event to next responder, and everything works again. It's 
disappointing and ugly, but it turned out to be less code than I 
thought. Walking the menus and submenus recursively to build the table 
is pretty simple, and I've already got a good hash table class which I 
was able to put to good use.


Maybe I'll file a bug on this...


Allen Smith wrote:
  

On Mar 27, 2008, at 8:12 PM, John Stiles wrote:



Wow, this sounds like a disaster.

Maybe in my -keyDown: call I can walk the menus in the menu bar and 
call -performKeyEquivalent on all of them. It's probably not fast :| 
I was in the process of writing code that stores the menu bar's key 
equivalents in a hash table and checks the hash table before handling 
-keyDown:, maybe I'll just keep doing that. It's gross but I guess 
all the potential solutions are gross.
  
Also be aware that if any other view in your application becomes first 
responder, it too will swallow up your key equivalents. Short of 
overriding -[NSApp sendEvent:], I don't know of universal fix. Calling 
-[super keyDown:] as another poster suggested doesn't work; by the 
time an event is routed to -keyDown:, the system no longer appears to 
consider it a candidate for menu actions.


Allen



Ken Thomases wrote:
  

On Mar 27, 2008, at 7:52 PM, John Stiles wrote:


I am implementing a custom NSView subclass (actually a simple 
subclass of NSOpenGLView) that implements -keyDown: in order to 
respond to user typing. Typically, this works great.


However, I have a few menu items which respond to atypical hotkeys 
(e.g. one responds to "space", another to "option+X"). In this 
case, I've found that the view gets a -keyDown: event, which it 
dutifully handles, and the menu hotkey is never handled. I'd prefer 
it if the menu action were triggered and no -keyDown: event were 
generated, and that's exactly what happens with more typical menu 
hotkeys like command+letters. But my view doesn't know what is in 
the menubar and so, without adding a lot of ugly special-case code, 
from within the view's -keyDown: handler, it would be difficult to 
know whether I need to send the event to the next responder or 
handle the key myself.


Is there any elegant solution to this problem? The last thing I 
want to do is reimplement hotkey handling on my own, but I can't 
think of any workarounds to this issue that don't involve my view 
taking on a lot of extra knowledge about what's in the menubar, or 
completely hacking the responder chain in some ugly way. It seems 
that I can't forward on to the next responder and then ask "did you 
handle it?"-if the responder chain fails to handle the event, 
apparently it just calls -noResponderFor: on the window and that is 
that-there's no return value of "YES" or "NO" or anything like that.
  
From

Re: Movable by window background AND custom NSView

2008-03-31 Thread vance


That did it. Thank you!

On Mar 31, 2008, at 10:09 AM, Michael Ash wrote:

On Mon, Mar 31, 2008 at 12:59 PM, patrick machielse  
<[EMAIL PROTECTED]> wrote:

Op 31 mrt 2008, om 09:52 heeft vance het volgende geschreven:



I have a Textured Window with a NSView that has some custom drawing
done in drawRect.

When I click and drag outside the custom NSView
 The window moves
 (That is exactly what is needed)

When I click and drag within the custom NSView
 The window moves
 The custom NSView receives the mouseDragged messages

Since I am overriding mouseDragged (and most other mouse related
messages in NSResponder) I would expect for the custom NSView to
only receive the messages and since I am not calling [super
mouseX]; the message should not get outside the NSView therefore
the window should not move.

Clearly that is now what happens. The window moves when I click and
drag within the custom view which is something we dont want to  
happen.


Does anyone understands what is the flow of mouse events and what to
do to get around this?


The solution is to subclass NSControl instead of NSView.


Actually the solution is to override -mouseDownCanMoveWindow to return
whatever is appropriate for your view.

Mike
___

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/cocoa%40grkov.com

This email sent to [EMAIL PROTECTED]


___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: core data and sqlite db store problem

2008-03-31 Thread Scott Guyer


Thanks Jeff,

  That would explain it.  Crikey...whole lotta Zs in the CD created  
SQLite schema.  :)


In XCode, there is an Design -> Data Model -> Import... menu item.  It  
is looking to import an XML file of a particular format.  Any pointers  
to this format?  Could this be a way for me to bootstrap data into my  
CD created SQLite DB file?


Thanks again.


On Mar 31, 2008, at 12:51 PM, Jeff LaMarche wrote:

Core data stores metadata as well as data in the sqlite3 file and  
follows a very specific naming convention for the regular data  
tables and columns. You'd probably be better off writing a small  
migration utility to import the data you need than to try create a  
sqlite3 database in the right format. Also, if you use this  
mechanism, when you distribute your app, none of that data will go  
with it.


Why don't you move out your sqlite3 file and let it create a new  
one, then go in and look at the tables and structure, and you'll get  
an idea of what I'm talking about.


HTH
Jeff
On Mar 31, 2008, at 12:45 PM, Scott Guyer wrote:


Hi,

I'm just learning core data and have already stumbled on  
something.  I created a CD application using the XCode template.   
I've created a sqlite3 .db file with data and a matching core data  
model in xcode.  My code fails here...


  url = [NSURL fileURLWithPath: [applicationSupportFolder  
stringByAppendingPathComponent: @"my.db"]];
  persistentStoreCoordinator = [[NSPersistentStoreCoordinator  
alloc] initWithManagedObjectModel: [self managedObjectModel]];
  if (![persistentStoreCoordinator  
addPersistentStoreWithType:NSSQLiteStoreType configuration:nil  
URL:url options:nil error:&error]){

  [[NSApplication sharedApplication] presentError:error];
  }

with an error saying that the db file cannot be opened because it  
is not in the right format.  "The file might be corrupted,  
truncated, or in a different format than you expect."  That's quite  
odd to me, since I can interact with that db file on the command  
line using sqlite3 just fine.  Anyone have any ideas/suggestions?


Much appreciated!

___

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/jeff_lamarche%40mac.com

This email sent to [EMAIL PROTECTED]




___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: NSNoCellMask differences in Leopard vs. Tiger

2008-03-31 Thread Ben Lachman

So it ends up that while NSNoCellMask works on Tiger it really isn't  
the way to do what I was wanting.  NSPushInCellMask does the same  
thing (darken the un-bezeled icon), makes more sense, and works on  
both Tiger and Leopard.  The problem is that the documentation  
doesn't mention NSPushInCellMask unless you look at the state masks  
leading me to believe that it wasn't a supported value for  
setHighlightsBy:.  Anyway, hope this helps someone at some point.


->Ben
--
Ben Lachman
Acacia Tree Software

http://acaciatreesoftware.com

[EMAIL PROTECTED]
740.590.0009

On Mar 20, 2008, at 5:50 AM, Ben Lachman wrote:
On Tiger one could set up borderless, momentary light "square  
button" with an icon and call setHighLightsBy: with NSNoCellMask  
and you'd get a nice darkening on the non-transparent parts when  
the user pressed the button.  However these same buttons on Leopard  
don't change at all during a user's press.  Is there a way to get a  
similar effect on Leopard without using an alternate image (some of  
my buttons already have alternate images)?



___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: Threads and Core Data, bindings results in view corruption

2008-03-31 Thread David

Thank you very much for the response which is chock full of helpful
information. Its taken me some time to try and digest.I must admit being a
little demoralized. I've always considered threading to go hand and hand
with GUI programming. I'm having trouble envisioning the scenarios where
bindings and core data are intended to be used without threads.

I'm relatively new to Cocoa. From my previous work in win32 and Java this is
the normal scenario, not an unusual one. Can someone point me to some sample
code that illustrates how to have a worker thread updating data which is
displayed in the UI?

In my case I am/was trying to maintain a outline view representing files,
storing each node in core data. Based on these responses I'm not sure what
technologies I should reasonably be using. Is this too fine grained for Core
Data? Should I give up on bindings? Should I give up on NSTreeController?

If I try to maintain multiple MOCs, that means I have to save to get it to
show up in the other moc, right? The save as binary file can take 15 seconds
in my case when I have thousands of nodes. That hangs the UI longer than
adding the nodes to start with. Should I try to use a in memory persistent
store or will that still be slow or cause an excessive memory penalty?

Additional comments below:

On Sun, Mar 30, 2008 at 9:50 PM, Ben Trumbull <[EMAIL PROTECTED]> wrote:
>
> If you want multi-threaded work with the view and controller classes
> in Cocoa, you'll need to perform your background operations, and
> communicate back to the main thread (view & controllers) via the run
> loop.  -performSelectorOnMainThread and its friends in NSThread.h are
> your best bet.
>
> Using a run loop on a background thread and communicating from the
> main thread to it with the new 10.5 -performSelector... methods is
> often conceptually simpler (easier to debug) than many other
> threading patterns.
>
> Sharing a MOC with Cocoa Bindings and a background thread will end in
> tears.  Cocoa Bindings doesn't lock its bound MOC, so you're
> basically SOL.

Can I ask why don't bindings lock the bound MOC or provide the option to? I
had assumed (incorrectly) that bindings would handle threads OR provide some
means to control or configure its threading behavior.

>
> Even if it did work, though, it'd be a bad idea.  Sharing a MOC means
> a background thread would still at times block the main thread and
> SPOB your app.

Why doesn't core data support locking at a finer grain? Or to rephrase, it
would be very helpful if Core Data could lock at a ManagedObject level. I
expected there to be a locking or transaction mode where I can lock it while
I fill in an object. Nothing else should require me to worry about core data
getting corrupted with multiple threads.

>
>
> These 3 points (can't work, doesn't work, shouldn't work) are why the
> Core Data Programming Guide says don't do this.
>
 The Core Data programming guide in the threading section guidelines states:

"3) Pass managed objects or managed object contexts between threads.

This approach is strongly discouraged. You must ensure that you apply locks
as appropriate and necessary."

I have interpreted that to mean that locking the managedObjectContext would
be sufficient. I hadn't realized that bindings would try to obtain locks.

>
>
> The list archives also have these, which you should read:
> 
> 
>
> It's possible to shuttle pending changes between threads by hand using
> KVC.

Are you describing in general or specifically with Core Data? Can you give
more insight on this? Are you saying that I manually track changes from core
data?

If its my own objects, I would expect to manage fine grain locks or
synchronize code which modifies by object tree.

>
>
>
> If you're inserting a large number of new objects, you really should
> just batch the operation together, save, and present the user with
> new objects in the tree view in batches.

>
> On Leopard, in the scenarios under which you can save, you can also
> use -mergeChangesFromContextDidSaveNotification:

But isn't a notification received on the same thread on which it was
posted?

>
>
>
> Finally, in 4 years no one has filed a bug about this.

File a bug about what? Do you consider the threading behavior in bindings
and Core data to be a bug?

>
>
> --
>
> -Ben
>
___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: Main Thread UI and Detached Thread

I'm not doing any work on the main thread while the spawned thread runs. 
In fact, the main thread is just idling doing nothing. And the behavior 
isn't really a responsiveness issue: the rest of the UI still responds 
fine, but my indicators that I update in the UI do *nothing* the entire 
time the spawned thread is running. Nothing. No activity. If I take the 
sleep calls out, then main thread updates the UI instantly upon 
termination of the spawned thread.


j o a r wrote:


On Mar 30, 2008, at 11:55 AM, Mike wrote:
In my worker thread I do a tight processing loop and one of the things 
I do in the loop is call two methods in the main thread to update the 
display (a text message and progress bar) - via 
performSelectorOnMainThread:withObject:waitUntilDone:modes.


However, when the loop runs in the spawned thread, the display doesn't 
get updated. If I insert a sleep(1) call into the loop, then the 
display  updates.



How much work do you perform on the main thread? If a lot, it's not 
unexpected that you would se interruptions in display updates. You might 
need to throttle or otherwise limit your callouts to the main thread if 
this proves to be the problem.


You can use Instruments or Shark to get a view of the work being 
performed on the main thread while you run your worker thread.


j o a r




___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: Main Thread UI and Detached Thread

I suppose it's possible. The spawned thread does a lot of setup then 
iterates some arrays of a bunch of objects in the filesystem that it 
needs to delete. The idea is to update the progress bar one increment 
with each item being deleted. I'm using a MacBook 2.16 Ghz but I doubt 
that the main thread is too slow to be able to do the updates.


Also, I set a message text item with the name of each item being deleted 
in the window as the worker thread runs. I never see it change even for 
an instant. I find it hard to believe that there can't be any visual 
update no matter how quickly the worker thread completes.


Hank Heijink (Mailinglists) wrote:
Just checking the obvious here - is it possible that your worker thread 
completes its work so fast that the main run loop hasn't updated the 
screen once before it's done? Keep in mind that the main thread has to 
display your window with the progress bar and the text and (depending on 
your implementation) that your worker thread may be working (and 
completing) while that's being done.


On Mar 30, 2008, at 2:55 PM, Mike wrote:
I have all my UI running on my app's main thread. I have a worker 
thread that I detach with detachNewThreadSelector:toTarget:withObject: 
(my worker thread).


In my worker thread I do a tight processing loop and one of the things 
I do in the loop is call two methods in the main thread to update the 
display (a text message and progress bar) - via 
performSelectorOnMainThread:withObject:waitUntilDone:modes.


However, when the loop runs in the spawned thread, the display doesn't 
get updated. If I insert a sleep(1) call into the loop, then the 
display  updates.


Why doesn't the main thread process the changes to the UI unless I 
call sleep? I thought the whole idea of using a separate thread was so 
that the main thread could continue to run on its own?


Thanks,

Mike



___

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/hank.list%40runbox.com

This email sent to [EMAIL PROTECTED]





___

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

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

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

This email sent to [EMAIL PROTECTED]

RE: Main Thread UI and Detached Thread

2008-03-31 Thread Andy Klepack

Are you calling performSelectorOnMainThread:withObject:waitUntilDone:modes on 
every iteration of the tight loop? That seems like it could be terribly 
expensive. What if you throttle it back to every X (ten, hundred, thousand, 
etc) iterations? My speculation would be you're overwhelming your receiver.

-Andy
___

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/andy.klepack%40microsoft.com

This email sent to [EMAIL PROTECTED]
___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: Main Thread UI and Detached Thread



On Mar 31, 2008, at 11:02 AM, Mike wrote:
I'm not doing any work on the main thread while the spawned thread  
runs. In fact, the main thread is just idling doing nothing. And the  
behavior isn't really a responsiveness issue: the rest of the UI  
still responds fine, but my indicators that I update in the UI do  
*nothing* the entire time the spawned thread is running. Nothing. No  
activity. If I take the sleep calls out, then main thread updates  
the UI instantly upon termination of the spawned thread.



You said that you're calling the main thread, so I expect it to do  
*something*...


How do you notify the controls in the UI that they need to update to  
reflect new values?

What is the total time required to run the task by your worker thread?

j o a r


___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: Question on bitmap fonts

2008-03-31 Thread Aki Inoue

Tobia,

It appears that this is the intended behavior.

The font contains glyphs that extend beyond the ascender line (the
accented glyphs) and Cocoa automatically adjusts the default line
height accordingly to avoid baseline shifts.

So, basically the system, tools you're using to convert the font, and
the font itself are all working as designed.

Aki

On 2008/03/31, at 9:23, Tobia Conforto wrote:

Hello

After 1000 messages to this list and no reply, I'm resubmitting my
question about bitmap fonts, hoping to get any bit of help or any
pointer at all (docs, other mailing lists, etc.)

If there is a list better suited to this question, please point me
to it.

I tried using the free editor Fontforge to convert 9x18.bdf into a
so-called (by Fontforge) "Apple bitmap-only .dfont" format. Mostly
it works, but I've run into a problem that Fontforge's programmers
can't solve. See this thread on their list:

http://www.nabble.com/BDF-to-Apple-bitmap-only-dfont,-wrong-line-height-td15155775.html

The problem is that the generated dfont is rendered by OS X with 4px
of additional ascent (or line-height) and we can't figure out where
it comes from. If I convert only the ASCII subset of the original
Unicode font, the line-height is correct. As soon as I add more
than a couple of non-ASCII characters, the 4px bug comes out.

I tried doing the same conversion using a trial version of the
commercial BitFonter 3.0 editor ($500) and I got the same results as
with Fontforge.

I looked into the .dfont file with a hex editor, using this manual
as a reference http://developer.apple.com/textfonts/TTRefMan/ but I
couldn't find anything out of place.

Here is a zip http://gruppo4.com/~tobia/osx-font-problem.zip where
I've put two OS X dfont files I created from 9x18.bdf, using
Fontforge, plus a text file with the font tables I extracted using
the hex editor.
In "test3" I converted the full Latin 1 charset (Unicode points <
256) and it shows the 4px bug; in "test7" I deleted all glyphs other
than ASCII and a couple of Latin 1 accented letters, and it displays
correctly in all Cocoa apps.

What am I doing wrong? What's different in the two files? Can you
replicate this bug? Is this a bug in OS X, a weird setting in the
original BDF, or a bug shared between Fontforge and BitFonter?

Can you think of any workaround or alternative program I could try?

Tobia
___

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/aki%40apple.com

This email sent to [EMAIL PROTECTED]

___

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]

Network notifications

2008-03-31 Thread Randall Meadows

My app registers a bonjour service, but basically it's really just  
advertising the web server running on the same machine as my app, with  
a little extra information pertaining to my app.  My app places files  
in a known location in the hierarchy that apache is serving, and I  
need to send out a notification when I make a change that's visible  
via that hierarchy, so that remote apps can pick up the changes.  The  
docs for NSDistributedNotificationCenter say I need to use distributed  
objects to communicate this fact to other computers (not just  
processes on my own).  But to use DO, there needs to be a known  
connection between my app and the remote app, right?  We don't want  
this connection, hence our move to serving these files via the built- 
in web server.  (I have control over this remote app, and can make it  
listen for whatever I want.)


I tend think NSNetService is what I want; it's what I use for the  
registering the service to begin with, but it's unclear to me how I  
can use that for momentary notifications ("this file changed", "this  
file is new"), as opposed to notifying about a long-lived service  
("here's a web server").  And taking a brief look at  
NSNetServiceBrowser, I can see how to easily find the service to begin  
with, but it's not obvious how it would be notified of the changes  
without re-searching for the same service it already knows about.


Is there some sort of NSNotification variant that I've missed for use  
between remote apps (not on the same machine, but on the same LAN)?



Thanks!
randy
___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: Main Thread UI and Detached Thread

2008-03-31 Thread Hank Heijink (Mailinglists)



On Mar 31, 2008, at 2:06 PM, Mike wrote:
I suppose it's possible. The spawned thread does a lot of setup then  
iterates some arrays of a bunch of objects in the filesystem that it  
needs to delete. The idea is to update the progress bar one  
increment with each item being deleted. I'm using a MacBook 2.16 Ghz  
but I doubt that the main thread is too slow to be able to do the  
updates.


The issue wouldn't be the main thread being too slow, but the worker  
thread being too fast, as it were. You'd be surprised how often you  
can be wrong with this kind of stuff. I've wasted hours thinking "It  
surely can't be x" and then actually measuring and finding it was x  
all the time. How big is the bunch of objects your program needs to  
delete? How long does it take to delete one item?


Also, I set a message text item with the name of each item being  
deleted in the window as the worker thread runs. I never see it  
change even for an instant. I find it hard to believe that there  
can't be any visual update no matter how quickly the worker thread  
completes.


If you change the UI values with setNeedsDisplay: calls, they only get  
updated once in every iteration of the main run loop. If there's a lot  
going on on that run loop, you may see just one value change (the last  
one) or none at all if you reset the values when you're done. If  
you're using bindings I'm not sure about the timing, but it's  
definitely not going to be faster than direct calls.


Have you measured how long it takes for your worker thread to complete  
its task? If it's less than a second, I'm not sure if you need a  
progress bar at all. A progress bar combined with changing  text  
doesn't make a lot of sense if that updates faster than your user can  
read anyway, so you might want to tone down the update speed.


Hank


Hank Heijink (Mailinglists) wrote:
Just checking the obvious here - is it possible that your worker  
thread completes its work so fast that the main run loop hasn't  
updated the screen once before it's done? Keep in mind that the  
main thread has to display your window with the progress bar and  
the text and (depending on your implementation) that your worker  
thread may be working (and completing) while that's being done.

On Mar 30, 2008, at 2:55 PM, Mike wrote:
I have all my UI running on my app's main thread. I have a worker  
thread that I detach with  
detachNewThreadSelector:toTarget:withObject: (my worker thread).


In my worker thread I do a tight processing loop and one of the  
things I do in the loop is call two methods in the main thread to  
update the display (a text message and progress bar) - via  
performSelectorOnMainThread:withObject:waitUntilDone:modes.


However, when the loop runs in the spawned thread, the display  
doesn't get updated. If I insert a sleep(1) call into the loop,  
then the display  updates.


Why doesn't the main thread process the changes to the UI unless I  
call sleep? I thought the whole idea of using a separate thread  
was so that the main thread could continue to run on its own?


Thanks,

Mike



___

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/hank.list%40runbox.com

This email sent to [EMAIL PROTECTED]


___

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/hank.list 
%40runbox.com


This email sent to [EMAIL PROTECTED]



___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: Threads and Core Data, bindings results in view corruption

2008-03-31 Thread Jeff LaMarche


David:

I can't speak for Apple (I'll leave that to Ben), but there are a few  
things to keep in mind here:


1) Core Data is still a relatively new technology. Sure, it came out  
with Tiger, but since using it keeps your app from running on earlier  
versions of OS X, a lot of software projects never adopted its use.  
When using traditional objective-C persistence (e.g. NSCoder) a lot of  
these issues don't exist, so until we hit critical mass of developers  
using Core Data in their apps, a lot of these issues will persist  
(especially if we don't file enhancement requests, as Ben pointed out,  
something I am admittedly guilty of)


2) Core Data, although relatively new, borrowed a lot conceptually  
from EOF, which was part of WebObjects, a web application framework. A  
lot of the concurrency issues we're talking about didn't exist in  
WebObjects because the UI was all rendered through HTML. The stateless  
nature of HTTP connections and the types of tasks you do in web apps  
rendered it mostly a non-issue.


3) Often, there are other ways to deal with UI responsiveness other  
than threads. Sure, it's the first thing that jumps to mind (at least  
for me), but two other possibilities that I can think of are timers  
and run loop callbacks like those used in CFNetwork. In fact, that's  
how I got around the problem in my app - I simply buffer and process  
chunks of data in a callback method the way CFFoundation does. Doing  
that, I lose the performance benefits of threads, but I didn't need  
that anyway, and my code is much easier to debug and maintain.


4) You can, as Ben mentioned, use performSelector:onMainThread: to  
actually have the object inserted on the main thread's context. It's a  
bit of a pain, but threads are always at least a little painful.


Just my 2¢... Like you, I'd still like to see Core Data become fully  
thread-safe, but you can't always have what you want when you want it.


Jeff

On Mar 31, 2008, at 1:49 PM, David wrote:

Thank you very much for the response which is chock full of helpful  
information. Its taken me some time to try and digest.
I must admit being a little demoralized. I've always considered  
threading to go hand and hand with GUI programming. I'm having  
trouble envisioning the scenarios where bindings and core data are  
intended to be used without threads.


I'm relatively new to Cocoa. From my previous work in win32 and Java  
this is the normal scenario, not an unusual one. Can someone point  
me to some sample code that illustrates how to have a worker thread  
updating data which is displayed in the UI?


In my case I am/was trying to maintain a outline view representing  
files, storing each node in core data. Based on these responses I'm  
not sure what technologies I should reasonably be using. Is this too  
fine grained for Core Data? Should I give up on bindings? Should I  
give up on NSTreeController?


If I try to maintain multiple MOCs, that means I have to save to get  
it to show up in the other moc, right? The save as binary file can  
take 15 seconds in my case when I have thousands of nodes. That  
hangs the UI longer than adding the nodes to start with. Should I  
try to use a in memory persistent store or will that still be slow  
or cause an excessive memory penalty?


Additional comments below:

On Sun, Mar 30, 2008 at 9:50 PM, Ben Trumbull <[EMAIL PROTECTED]>  
wrote:

If you want multi-threaded work with the view and controller classes
in Cocoa, you'll need to perform your background operations, and
communicate back to the main thread (view & controllers) via the run
loop.  -performSelectorOnMainThread and its friends in NSThread.h are
your best bet.

Using a run loop on a background thread and communicating from the
main thread to it with the new 10.5 -performSelector... methods is
often conceptually simpler (easier to debug) than many other
threading patterns.

Sharing a MOC with Cocoa Bindings and a background thread will end in
tears.  Cocoa Bindings doesn't lock its bound MOC, so you're
basically SOL.
Can I ask why don't bindings lock the bound MOC or provide the  
option to? I had assumed (incorrectly) that bindings would handle  
threads OR provide some means to control or configure its threading  
behavior.


Even if it did work, though, it'd be a bad idea.  Sharing a MOC means
a background thread would still at times block the main thread and
SPOB your app.
Why doesn't core data support locking at a finer grain? Or to  
rephrase, it would be very helpful if Core Data could lock at a  
ManagedObject level. I expected there to be a locking or transaction  
mode where I can lock it while I fill in an object. Nothing else  
should require me to worry about core data getting corrupted with  
multiple threads.



These 3 points (can't work, doesn't work, shouldn't work) are why the
Core Data Programming Guide says don't do this.
 The Core Data programming guide in the threading section guidelines  
states:

"3) Pass

Re: Modify Input in NSTableView

2008-03-31 Thread K. Darcy Otto

On Mar 31, 2008, at 00:29, Quincey Morris wrote:

> On Mar 30, 2008, at 23:08, K. Darcy Otto wrote:
>

>> I'm working on an application in which users enter data into a
>> table, but I need to substitute a greater-than symbol (>) for a
>> right-arrow symbol (→, unicode: 2192) as the user presses they  
key

>> (or copies the text, or whatever).  After looking at the docs and
>> this list, I'm not much closer to determining the best way to do
>> this (or even how to do it).  So far, I have been thinking I have
>> to do something with NSWindow and the fieldEditor; perhaps setting
>> the window's field editor to be a particular NSTextView, and
>> implement some method in that text view  (insertText:?) to make the
>> substitution.  I take it that working with keyDown: would not be
>> the best approach.  Would this be on the right track?  Any help
>> would be appreciated.

>
> You could try adding a validate method for the property that
> holds the string value. In that method, take the input string and
> create a new string, replacing whatever characters you need to. Pass
> the new string back in the first parameter, and return YES from the
> method.
>
> If I haven't overlooked something obvious, this would work no matter
> whether the text was typed or pasted into the editing field.
>
> Oh -- make sure you check "Validates immediately" for the table
> column binding in IB, too.

Of course, this is only going to make the replacement happen when the
user presses return or tab. To get it to happen as soon as a
replaceable character is typed, you'd have to convince the field
editor to validate after every keystroke or editing action. So maybe
this is not the best way.

This is exactly the problem I'm running into.  I can get changes to be  
made after the user exits the editing field, but I cannot get the  
changes to be made on-the-fly.  After some additional reading, I have  
tried to solve this problem by implementing the following in the  
NSWindow delegate (where DeductionTable is my NSTableView subclass,  
and DeductionTableFieldEditor is my NSTextView subclass):

-(id)windowWillReturnFieldEditor:(NSWindow *)window toObject: 
(id)anObject

{
if ([anObject isKindOfClass:[DeductionTable class]])
{
return [[DeductionTableFieldEditor alloc] init];
}
return nil;
}

Then, I started playing around with -(BOOL)textView:(NSTextView  
*)aTextView shouldChangeTextInRange:(NSRange)affectedCharRange  
replacementString:(NSString *)replacementString and - 
(BOOL)textShouldBeginEditing:(NSText *)aTextObject; but all I've  
succeeded in doing is messing up the editing functions that were there  
previously.  Any other suggestions?

___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: Network notifications

On Mon, Mar 31, 2008 at 7:23 PM, Randall Meadows <[EMAIL PROTECTED]> wrote:

>  But to use DO, there needs to be a known
>  connection between my app and the remote app, right?  We don't want
>  this connection

What is it that you are averse to? A persistent connection? A fixed
handle for your service? It's difficult to suggest a mechanism to
replace DO when you don't say why you don't want to use it...

Hamish
___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: Threads and Core Data, bindings results in view corruption

2008-03-31 Thread David

On Mon, Mar 31, 2008 at 2:26 PM, Jeff LaMarche <[EMAIL PROTECTED]>
wrote:

> 4) You can, as Ben mentioned, use performSelector:onMainThread: to
> actually have the object inserted on the main thread's context. It's a bit
> of a pain, but threads are always at least a little painful.
>

How? Core data says that to use NSManagedObjects between threads you need to
pass an ID and access it from another context. But you don't even get an ID
until you perform a save on the original context. I'm then back to my
original problem where the save itself takes too long.

>From what I've read so far, my current thinking is that I need to give up on
Core data. I can easily create my own objects, handle my own locking or
synchronization. I was thinking to still use NSTreeController bound to my
objects.

Its a shame because core data sounds so cool. I love the data modeling
aspects. Nice way to think through the problem even if I end up not using
it.
___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: Threads and Core Data, bindings results in view corruption

2008-03-31 Thread Jeff LaMarche



On Mar 31, 2008, at 2:36 PM, David wrote:



On Mon, Mar 31, 2008 at 2:26 PM, Jeff LaMarche  
<[EMAIL PROTECTED]> wrote:
4) You can, as Ben mentioned, use performSelector:onMainThread: to  
actually have the object inserted on the main thread's context. It's  
a bit of a pain, but threads are always at least a little painful.


How? Core data says that to use NSManagedObjects between threads you  
need to pass an ID and access it from another context. But you don't  
even get an ID until you perform a save on the original context. I'm  
then back to my original problem where the save itself takes too long.


From what I've read so far, my current thinking is that I need to  
give up on Core data. I can easily create my own objects, handle my  
own locking or synchronization. I was thinking to still use  
NSTreeController bound to my objects.


Its a shame because core data sounds so cool. I love the data  
modeling aspects. Nice way to think through the problem even if I  
end up not using it.


Well, I don't know exactly what you're doing in your thread, but you  
could create a method that that took, for example, a dictionary as an  
argument, then when you're ready to insert the object in your thread,  
pass that method the values you need having it fire on the main thread  
and then create the Core Data entity based on the passed values and  
then insert it into the main thread's context.  If you needed to do  
further work on that entity, like adding relationships to it, then it  
would get to be trickier, as you'd also need to get its  
managedObjectID back to your thread. I'm almost certain it's POSSIBLE  
to do what you want with Core Data, but it's also altogether possible  
that it would be easier or more efficient to go with traditional Obj-c  
persistence.


Sorry that I've got no magic bullet for you. :-/

Jeff
___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: Main Thread UI and Detached Thread

2008-03-31 Thread Matt Mashyna


As long as we're top posting...

Why not update values for your worker thread and spawn another thread  
that does the UI progress updates periodically ? Works nice for me. I  
update the UI with whatever my controller object's state is at that  
moment and then sleep for a little. I like this scheme because I can  
let my worker thread run full-tilt and tweak the progress thread if I  
need to.


Matt

On Mar 31, 2008, at 2:06 PM, Mike wrote:

I suppose it's possible. The spawned thread does a lot of setup then  
iterates some arrays of a bunch of objects in the filesystem that it  
needs to delete. The idea is to update the progress bar one  
increment with each item being deleted. I'm using a MacBook 2.16 Ghz  
but I doubt that the main thread is too slow to be able to do the  
updates.


Also, I set a message text item with the name of each item being  
deleted in the window as the worker thread runs. I never see it  
change even for an instant. I find it hard to believe that there  
can't be any visual update no matter how quickly the worker thread  
completes.


Hank Heijink (Mailinglists) wrote:
Just checking the obvious here - is it possible that your worker  
thread completes its work so fast that the main run loop hasn't  
updated the screen once before it's done? Keep in mind that the  
main thread has to display your window with the progress bar and  
the text and (depending on your implementation) that your worker  
thread may be working (and completing) while that's being done.

On Mar 30, 2008, at 2:55 PM, Mike wrote:
I have all my UI running on my app's main thread. I have a worker  
thread that I detach with  
detachNewThreadSelector:toTarget:withObject: (my worker thread).


In my worker thread I do a tight processing loop and one of the  
things I do in the loop is call two methods in the main thread to  
update the display (a text message and progress bar) - via  
performSelectorOnMainThread:withObject:waitUntilDone:modes.


However, when the loop runs in the spawned thread, the display  
doesn't get updated. If I insert a sleep(1) call into the loop,  
then the display  updates.


Why doesn't the main thread process the changes to the UI unless I  
call sleep? I thought the whole idea of using a separate thread  
was so that the main thread could continue to run on its own?


Thanks,

Mike



___

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/hank.list%40runbox.com

This email sent to [EMAIL PROTECTED]


___


___

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]

Simple NSComboBox example?

2008-03-31 Thread David Springer

Folks,

Is there a simple NSComboBox example that uses bindings out there?  I
want to populate an NSComboBox with a list of filenames using an
NSArrayController, etc.

Thanks!
- Dave.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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Main Thread UI and Detached Thread

Yes, but in some cases the loop doesn't run for 10,000. It could run for 
5 iterations or 100,000 depending on the # if files to delete.


There's no caveat in the docs on the use of 
performSelectorOnMainThread:withObject:waitUntilDone:modes - the docs 
make it sound that there are no restrictions on how often or which 
selectors can be called.


In my case I only call 2 each time through the loop - one method on the 
main thread to update the progress bar, one to update the message.


-m
=

Andy Klepack wrote:

Are you calling performSelectorOnMainThread:withObject:waitUntilDone:modes on 
every iteration of the tight loop? That seems like it could be terribly 
expensive. What if you throttle it back to every X (ten, hundred, thousand, 
etc) iterations? My speculation would be you're overwhelming your receiver.

-Andy
___

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/andy.klepack%40microsoft.com

This email sent to [EMAIL PROTECTED]


___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: Main Thread UI and Detached Thread

I have two methods in the main thread that I call from the worker using 
performSelector, etc. The method for updating the progress bar for 
example looks like this:


- (void)setProgressBarValue:(double)value
{
if( progressBar )
{
[ progressBar setDoubleValue:value ];

[ progressBar setNeedsDisplay:YES ];

[ progressBar display ];
}
}

The one for the message is similar. All the code works perfectly when I 
sleep or if the worker terminates so I know there is noting wrong inside 
the selectors I am calling.


This is a pretty simple app and I don't have time to dive into 
performance tools to discover why a single thread in a 10-page app isn't 
doing what it's advertised to do.


-m


j o a r wrote:


On Mar 31, 2008, at 11:02 AM, Mike wrote:
I'm not doing any work on the main thread while the spawned thread 
runs. In fact, the main thread is just idling doing nothing. And the 
behavior isn't really a responsiveness issue: the rest of the UI still 
responds fine, but my indicators that I update in the UI do *nothing* 
the entire time the spawned thread is running. Nothing. No activity. 
If I take the sleep calls out, then main thread updates the UI 
instantly upon termination of the spawned thread.



You said that you're calling the main thread, so I expect it to do 
*something*...


How do you notify the controls in the UI that they need to update to 
reflect new values?

What is the total time required to run the task by your worker thread?

j o a r




___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: Main Thread UI and Detached Thread


Hank Heijink (Mailinglists) wrote:


On Mar 31, 2008, at 2:06 PM, Mike wrote:
I suppose it's possible. The spawned thread does a lot of setup then 
iterates some arrays of a bunch of objects in the filesystem that it 
needs to delete. The idea is to update the progress bar one increment 
with each item being deleted. I'm using a MacBook 2.16 Ghz but I doubt 
that the main thread is too slow to be able to do the updates.


The issue wouldn't be the main thread being too slow, but the worker 
thread being too fast, as it were. You'd be surprised how often you can 
be wrong with this kind of stuff. I've wasted hours thinking "It surely 
can't be x" and then actually measuring and finding it was x all the 
time. How big is the bunch of objects your program needs to delete? How 
long does it take to delete one item?


It could be anywhere from 1 to an unlimited number of items. I have no 
idea how long it takes to delete each one and I don't have time to play 
around with performance tools.


Also, I set a message text item with the name of each item being 
deleted in the window as the worker thread runs. I never see it change 
even for an instant. I find it hard to believe that there can't be any 
visual update no matter how quickly the worker thread completes.


If you change the UI values with setNeedsDisplay: calls, they only get 
updated once in every iteration of the main run loop. If there's a lot 
going on on that run loop, you may see just one value change (the last 
one) or none at all if you reset the values when you're done. If you're 
using bindings I'm not sure about the timing, but it's definitely not 
going to be faster than direct calls.


I am doing nothing in the main run loop when th worker thread fires. The 
main thread is doing nothing but idling and this isn't a case of seeing 
intermittent things change - NOTHING ever gets updates while the worker 
is running. I don't really care about speed. Fast or slow doesn't 
matter. What I want is to see the items update while the worker is 
running, not after it's done. If I wanted nothing to happen until after 
the operation was done, then I would just abandon threads altogether and 
just call a single method on the main thread on completion.


Have you measured how long it takes for your worker thread to complete 
its task? If it's less than a second, I'm not sure if you need a 
progress bar at all. A progress bar combined with changing  text doesn't 
make a lot of sense if that updates faster than your user can read 
anyway, so you might want to tone down the update speed.


Well, it could be fast on a Mac Pro but very slow on a PowerBook G4 400. 
It could be fast because only one item is being deleted, or it could be 
very slow because 1,000,000 items are being deleted. The point is: I 
shouldn't have to care. It should just do the right thing and update 
when I tell it to.



Hank


Hank Heijink (Mailinglists) wrote:
Just checking the obvious here - is it possible that your worker 
thread completes its work so fast that the main run loop hasn't 
updated the screen once before it's done? Keep in mind that the main 
thread has to display your window with the progress bar and the text 
and (depending on your implementation) that your worker thread may be 
working (and completing) while that's being done.

On Mar 30, 2008, at 2:55 PM, Mike wrote:
I have all my UI running on my app's main thread. I have a worker 
thread that I detach with 
detachNewThreadSelector:toTarget:withObject: (my worker thread).


In my worker thread I do a tight processing loop and one of the 
things I do in the loop is call two methods in the main thread to 
update the display (a text message and progress bar) - via 
performSelectorOnMainThread:withObject:waitUntilDone:modes.


However, when the loop runs in the spawned thread, the display 
doesn't get updated. If I insert a sleep(1) call into the loop, then 
the display  updates.


Why doesn't the main thread process the changes to the UI unless I 
call sleep? I thought the whole idea of using a separate thread was 
so that the main thread could continue to run on its own?


Thanks,

Mike



___

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/hank.list%40runbox.com

This email sent to [EMAIL PROTECTED]


___

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/hank.list%40runbox.com

This email sent to [EMAIL PROTECTED]





___

Cocoa-dev maili

Re: Main Thread UI and Detached Thread


Matt Mashyna wrote:

As long as we're top posting...

Why not update values for your worker thread and spawn another thread 
that does the UI progress updates periodically ? Works nice for me. I 
update the UI with whatever my controller object's state is at that 
moment and then sleep for a little. I like this scheme because I can let 
my worker thread run full-tilt and tweak the progress thread if I need to.


Matt



But my question is: why should I have to?

The docs say run all the UI on the main thread and notify

the main thread from within the worker thread when the UI needs updating.

Now you're saying I have to spawn yet another thread to do what the docs

say the main thread should be doing? Why do I have to use an 
overly-elaborate


design for something Apple says I shouldn't have to? Is Apple lying in 
the docs?


Mike



On Mar 31, 2008, at 2:06 PM, Mike wrote:

I suppose it's possible. The spawned thread does a lot of setup then 
iterates some arrays of a bunch of objects in the filesystem that it 
needs to delete. The idea is to update the progress bar one increment 
with each item being deleted. I'm using a MacBook 2.16 Ghz but I doubt 
that the main thread is too slow to be able to do the updates.


Also, I set a message text item with the name of each item being 
deleted in the window as the worker thread runs. I never see it change 
even for an instant. I find it hard to believe that there can't be any 
visual update no matter how quickly the worker thread completes.


Hank Heijink (Mailinglists) wrote:
Just checking the obvious here - is it possible that your worker 
thread completes its work so fast that the main run loop hasn't 
updated the screen once before it's done? Keep in mind that the main 
thread has to display your window with the progress bar and the text 
and (depending on your implementation) that your worker thread may be 
working (and completing) while that's being done.

On Mar 30, 2008, at 2:55 PM, Mike wrote:
I have all my UI running on my app's main thread. I have a worker 
thread that I detach with 
detachNewThreadSelector:toTarget:withObject: (my worker thread).


In my worker thread I do a tight processing loop and one of the 
things I do in the loop is call two methods in the main thread to 
update the display (a text message and progress bar) - via 
performSelectorOnMainThread:withObject:waitUntilDone:modes.


However, when the loop runs in the spawned thread, the display 
doesn't get updated. If I insert a sleep(1) call into the loop, then 
the display  updates.


Why doesn't the main thread process the changes to the UI unless I 
call sleep? I thought the whole idea of using a separate thread was 
so that the main thread could continue to run on its own?


Thanks,

Mike



___

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/hank.list%40runbox.com

This email sent to [EMAIL PROTECTED]


___


___

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/junklists%40michael-amorose.com 



This email sent to [EMAIL PROTECTED]


___

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]

Problem with setting color in NSBitmapImageRep

2008-03-31 Thread Christian Kaiser

I'm struggling with setting color in a NSBitmapImageRep. I'm computing 
the components of a NSColor according to a numeric value; its basically 
a linear interpolation between all components of two NSColors. I've got 
a function which is computing the new NSColor based on a given value. If 
I call this function repeatedly using the same value and setting the 
color using NSBitmapImageRep setColor:atX:y:, I expect to have a uniform 
image if applying to all pixels. But this is not the case...! What am I 
missing ?


As I'm probably a little bit confusing, here the code producing my 
strange image :




   // Creating two colors which define a gradient. The color for our image
   // will be computed using this gradient.

   NSColor *lightYellow =
   [NSColor colorWithCalibratedRed:0.97 green:0.93 blue:0.65 
alpha:1.0];
  
   NSColor *darkRed =
   [NSColor colorWithCalibratedRed:0.69 green:0.09 blue:0.11 
alpha:1.0];



   // Creating an empty image with the same color space.

   NSBitmapImageRep *img = [[NSBitmapImageRep alloc]
   initWithBitmapDataPlanes:NULL
   pixelsWide:10
   pixelsHigh:10
   bitsPerSample:8
   samplesPerPixel:3
   hasAlpha:NO
   isPlanar:YES
   colorSpaceName:[lightYellow colorSpaceName]
   bitmapFormat:0
   bytesPerRow:0
   bitsPerPixel:0];
  


   // Assigning the same (???) color to all pixels.
   int x, y;
   for (y = 0; y < 10; y++)
   {
   for (x = 0; x < 10; x++)
   {
   NSColor *imgColor = [GradientColor gradientColorWithValue:40.0
   minColor:lightYellow maxColor:darkRed
   minValue:30.0 maxValue:60.0];
  
   [img setColor:imgColor atX:x y:y];

   }
   }
  
  
   [[img TIFFRepresentation]

   writeToFile:@"/Users/chkaiser/Desktop/img.tif" atomically:YES];


And the function computing the gradient color based on our values:

+(NSColor*)gradientColorWithValue:(double)value minColor:(NSColor*)c1
   maxColor:(NSColor*)c2 minValue:(double)v1 maxValue:(double)v2
{
  
   // Color components.

   CGFloat comps1[5];
   [c1 getComponents:comps1];
   CGFloat comps2[5];
   [c2 getComponents:comps2];
  
   // Compute the multiplication factor for the value. This factor has

   // a value between 0 and 1.
   double factor = (value - v1) / (v2 - v1);
  
   // Compute the new components.

   int i;
   CGFloat newComps[5];
   for (i = 0; i < [c1 numberOfComponents]; i++)
   {
   newComps[i] =
   (factor * (comps2[i] - comps1[i])) +
   comps1[i];
   }
  
   // Create the new color with the computed components.

   NSColor *newColor = [NSColor colorWithColorSpace:[c1 colorSpace]
   components:newComps count:[c1 numberOfComponents]];
  
   return newColor;
  
}



What is going wrong here ?

I have not found any similar topic on this list until now, even if it 
seems to me quite strange. Is there something obvious I am missing ?


--Christian Kaiser


___

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]

NSPredicate and Arrays

2008-03-31 Thread Jake Carter

Hey Guys,
I'm trying to use NSPredicate to filter an array. Here's the structure of my
array

ArrayOfFoos:
Foo: (Custom Object)
Bars: (NSArray *)Bar: (Custom Object)
Baz = 1 (int Property on custom object)
Bar:
Baz = 3
...
Foo:Bars:
Bar:
Baz = 2
Bar:
Baz = 1
...
...

and
So what I want to do is pull out all Foos who have a baz == 1.

I've tried

NSPredicate *p = [NSPredicate predicateWithFormat:@"bars.baz == 1"];
NSMutableArray *ma = [NSMutableArray arrayWithArray:[arrayOfFoos
filteredArrayUsingPredicate:p]];

which obviously won't work because the bars don't have a baz property
because it's an array.

I've also tried adding [] so that it know it's an array, but that didn't
work either...

NSPredicate *p = [NSPredicate predicateWithFormat:@"bars[].baz == 1"];
NSMutableArray *ma = [NSMutableArray arrayWithArray:[arrayOfFoos
filteredArrayUsingPredicate:p]];

I'm not sure what expression to use to denote that I want the predicate to
drill down in to each bar to look for the baz.

I hope this make sense. Any help would be great.

Thanks,

:// Jake
___

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]

libpq prepared statement

2008-03-31 Thread Justin Giboney

I am trying to get a libpq prepared statement to compile (not actually  
work) in my app. I am having difficulty finding an example of one on  
the internet somewhere. I don't really understand the documentation ( http://www.postgresql.org/docs/8.1/static/libpq-exec.html#LIBPQ-EXEC-SELECT-INFO 
 ) to well, but I thought I would try it before asking.


Here is what I have (it is probably nowhere close)

NSString *theUUID = @"test"; //this works
PGconn *conn = PQconnectdb(conninfo); // this works

PQprepare *statement = PQPrepare(theConnection, "stmtname", "SELECT *  
FROM admin WHERE id = %s", 1, [theUUID]);


I get two errors here
1) 'statement' undeclared (first use in this function)
2) syntax error before ']' token

The documentation says that this will be used with the PQexecPrepared,  
but I don't understand how.


If you have an example I could look at that would be great.

Thank you,

Justin Giboney

p.s. why is it that Apple has no documentation on having Cocoa work  
with Databases? Try typing in "mysql" or "postgresql" in the search  
box of this page http://developer.apple.com/cocoa/ while restricting  
it to cocoa. Do they not want business to use Cocoa?

___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: Main Thread UI and Detached Thread



On Mar 31, 2008, at 12:20 PM, Mike wrote:
I have two methods in the main thread that I call from the worker  
using performSelector, etc. The method for updating the progress bar  
for example looks like this:


- (void)setProgressBarValue:(double)value
{
if( progressBar )
{
[ progressBar setDoubleValue:value ];

[ progressBar setNeedsDisplay:YES ];

[ progressBar display ];
}
}



Your calls to "-setNeedsDisplay:" and "-display" are basically  
mutually exclusive. You should typically not call "-display" directly.



This is a pretty simple app and I don't have time to dive into  
performance tools to discover why a single thread in a 10-page app  
isn't doing what it's advertised to do.



I don't think you're saving any time by not learning how to use the  
performance tools.



j o a r


___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: Network notifications

2008-03-31 Thread Randall Meadows


On Mar 31, 2008, at 12:34 PM, Hamish Allan wrote:
On Mon, Mar 31, 2008 at 7:23 PM, Randall Meadows <[EMAIL PROTECTED] 
pc.com> wrote:



But to use DO, there needs to be a known
connection between my app and the remote app, right?  We don't want
this connection


What is it that you are averse to? A persistent connection? A fixed
handle for your service? It's difficult to suggest a mechanism to
replace DO when you don't say why you don't want to use it...


Ok, well, frankly, the previous versions of these app used Core Data  
over DO (a situation which I understand was never intended), and the  
code is a mess and quite fragile.  So we decided to take a much  
simpler approach for this version 2 rewrite, and use the built-in web  
server as the distribution mechanism.


The two apps that are going to be communicating* will have similar,  
though not identical life times.  In general, my app is going to be  
launched first, and will be gathering data; the remote app will likely  
come online later, and then gather all information collected thus far  
by my app, and then start listening for when my app acquires more data  
to it can keep up-to-date in more or less real-time; this is so that  
the remote can always have the latest data, in case my app quits (my  
user goes to lunch, or is done for the day and leaves the site, for  
example).


So basically, yes, KISS is our motto (or at least KIASAP), so we are  
looking to keep them untethered if at all possible.  An ideal solution  
would be NSNotification that works across a LAN.


Does that help?
randy

*In theory, it could be that more than one remote app is going to be  
interested in retrieving the data that my server app is gathering, but  
in practice, it's likely going to be just one.  Another reason we went  
with the simpler apache delivery system.

___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: libpq prepared statement

2008-03-31 Thread stephen joseph butler

On Mon, Mar 31, 2008 at 2:44 PM, Justin Giboney <
[EMAIL PROTECTED]> wrote:

> PQprepare *statement = PQPrepare(theConnection, "stmtname", "SELECT *
> FROM admin WHERE id = %s", 1, [theUUID]);
>

http://developer.apple.com/documentation/Cocoa/Reference/Foundation/Classes/NSString_Class/Reference/NSString.html#//apple_ref/doc/uid/2154-CJBHCCED

> p.s. why is it that Apple has no documentation on having Cocoa work
> with Databases? Try typing in "mysql" or "postgresql" in the search
> box of this page http://developer.apple.com/cocoa/ while restricting
> it to cocoa. Do they not want business to use Cocoa?
>

The Cocoa database support is through CoreData. If you want to do MySQL or
Pg then it's expected that you'll know how to do it yourself (or, actually,
that the respective DB companies will provide documentation). A search on
MSDN for MySQL only gets forum links... which isn't any better than what
Apple provides.
___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: Main Thread UI and Detached Thread



On Mar 31, 2008, at 12:25 PM, Mike wrote:
I am doing nothing in the main run loop when th worker thread fires.  
The main thread is doing nothing but idling



This is not true, as you call to the main thread for display updates.



On Mar 31, 2008, at 12:28 PM, Mike wrote:

But my question is: why should I have to?
The docs say run all the UI on the main thread and notify the main  
thread from within the worker thread when the UI needs updating.



That should indeed be enough.

I think that you need to either post more code, or preferably a sample  
project that exhibits this problem, for us to be able to help you  
figure out what's wrong.



j o a r


___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: Threads and Core Data, bindings results in view corruption

2008-03-31 Thread Ben Lachman

On Mar 31, 2008, at 2:47 PM, Jeff LaMarche wrote:

On Mar 31, 2008, at 2:36 PM, David wrote:

On Mon, Mar 31, 2008 at 2:26 PM, Jeff LaMarche
<[EMAIL PROTECTED]> wrote:
4) You can, as Ben mentioned, use performSelector:onMainThread: to
actually have the object inserted on the main thread's context.
It's a bit of a pain, but threads are always at least a little
painful.

How? Core data says that to use NSManagedObjects between threads
you need to pass an ID and access it from another context. But you
don't even get an ID until you perform a save on the original
context. I'm then back to my original problem where the save
itself takes too long.

From what I've read so far, my current thinking is that I need to
give up on Core data. I can easily create my own objects, handle
my own locking or synchronization. I was thinking to still use
NSTreeController bound to my objects.

Its a shame because core data sounds so cool. I love the data
modeling aspects. Nice way to think through the problem even if I
end up not using it.

Well, I don't know exactly what you're doing in your thread, but
you could create a method that that took, for example, a dictionary
as an argument, then when you're ready to insert the object in your
thread, pass that method the values you need having it fire on the
main thread and then create the Core Data entity based on the
passed values and then insert it into the main thread's context.
If you needed to do further work on that entity, like adding
relationships to it, then it would get to be trickier, as you'd
also need to get its managedObjectID back to your thread.

Actually this isn't true. You can add relationships, etc. without
having to pass them around since you will be doing a save at some
point and that will sync everything back to the persistent store.
Then, once you pass the OID of your newly inserted object back to you
main thread you can fetch it from the store and the relationships you
added to it, etc. will be intact.

My worker thread looks something like this (pseudo-code):

Main thread:

[NSThread detachNewThreadSelector:@selector(workLoop:)
toTarget:newWorker withObject:self];

Worker thread executes work loop which inserts new managed objects,
saves them and sends the new oids back to the main thread by calling:

[owner performSelectorOnMainThread:@selector(addResults:) withObject:
[newManagedObjectSet valueForKey:@"objectID"] waitUntilDone:NO];

The worker also notifies its owner (which was passed to detach...)
just before exit.

This is loosely based on SIWorkerThread by Daniel Vollmer www.maven.de/2007/01/cocoa-worker-thread/> with use of
performSelectorOnMainThread to pass OIDs back.

You also should try using an SQLite store. It will be faster than a
binary store for saving incrementally since it only touches part(s)
of the file. However if you are adding lots of objects make sure you
look at how often you save and if there are ways to decrease that
frequency.

Lastly, I kind of wonder if there might be some way to integrate a
secondary In-Memory store into this setup for use in passing the
objects created by the worker thread back to the main thread, it
seems like it might introduce some more complexity but might also be
worthwhile performance-wise since saving to the SQL store does have a
certain amount of latency due to how it hits the disk (particularly
on Tiger). Any thoughts on this Ben?

->Ben
--
Ben Lachman
Acacia Tree Software

http://acaciatreesoftware.com

[EMAIL PROTECTED]
740.590.0009

___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: Main Thread UI and Detached Thread

2008-03-31 Thread Ken Victor

At 1:08 PM -0700 3/31/08, [EMAIL PROTECTED] wrote:

Date: Mon, 31 Mar 2008 12:20:41 -0700
From: Mike <[EMAIL PROTECTED]>
Subject: Re: Main Thread UI and Detached Thread
To: Apple Cocoa List 
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

I have two methods in the main thread that I call from the worker using
performSelector, etc. The method for updating the progress bar for
example looks like this:

- (void)setProgressBarValue:(double)value
{
if( progressBar )
{
[ progressBar setDoubleValue:value ];

[ progressBar setNeedsDisplay:YES ];

[ progressBar display ];
}
}

are you calling:
performSelectorOnMainThread:withObject:waitUntilDone:
(or one of its variants) passing in a selector for setProgressBarValue: ?

could it possibly be that setProgressBarValue: takes a double 
argument, yet performSelector... expects an id for the withObject 
parameter? thus, you have potential garbage being passed to your 
setProgressBarValue method.

ken
___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: libpq prepared statement

2008-03-31 Thread Keary Suska

on 3/31/08 1:44 PM, [EMAIL PROTECTED] purportedly said:

> PQprepare *statement = PQPrepare(theConnection, "stmtname", "SELECT *
> FROM admin WHERE id = %s", 1, [theUUID]);

Yes--it not even close. The libpq prototype is:

PGresult *PQprepare(PGconn *conn,
const char *stmtName,
const char *query,
int nParams,
const Oid *paramTypes);

It also looks like you are confusing regular C with Objective-C
(syntactically). Libpq is a C library, so constructs such as PGresult are
pointers, *not* objects. If you don't know C very well, you really should
brush up on it. It will also help your Cocoa, since Objective-C is a
superset of C.

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: outlineViewSelectionDidChange not called

2008-03-31 Thread Jonathan Dann


Hi Adam,

I've found that programmatically changing the selection using the tree  
controller's -setSelectionIndexPath(s): will always send the  
NSOutlineViewSelectionDidChangeNotification, you might want to have a  
look here


http://www.wilshipley.com/blog/2006/04/pimp-my-code-part-10-whining-about.html

in particular the -indexPathToObject: method, which allows you to  
write things like this:


[treeController setSelectionIndexPath:[treeController  
indexPathToObject:anObject]];


which then send the note.  In 10.5 the NSTreeNode has an -indexPath  
method, but (AFAIK) there's still not an out-of-the-box way of taking  
an arbitrary object in your model and getting its indexPath in the  
tree. I've requested an enhancement : rdar://problem/5832408


Happy hunting,

Jon

smime.p7s
Description: S/MIME cryptographic signature
___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: Network notifications

On Mon, Mar 31, 2008 at 8:47 PM, Randall Meadows <[EMAIL PROTECTED]> wrote:

>  The two apps that are going to be communicating* will have similar,
>  though not identical life times.  In general, my app is going to be
>  launched first, and will be gathering data; the remote app will likely
>  come online later, and then gather all information collected thus far
>  by my app, and then start listening for when my app acquires more data
>  to it can keep up-to-date in more or less real-time; this is so that
>  the remote can always have the latest data, in case my app quits (my
>  user goes to lunch, or is done for the day and leaves the site, for
>  example).

Well, you could just use Bonjour to advertise a TCP port on which the
client can connect, and then both server and client would keep that
connection alive until the client quits, and the server could simply
send the URL of any changed items in plain text to the client.

Hamish
___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: NSPredicate and Arrays

2008-03-31 Thread Keary Suska

on 3/31/08 1:41 PM, [EMAIL PROTECTED] purportedly said:

> ArrayOfFoos:
> Foo: (Custom Object)
> Bars: (NSArray *)Bar: (Custom Object)
> Baz = 1 (int Property on custom object)
> Bar:
> Baz = 3
> ...
> Foo:Bars:
> Bar:
> Baz = 2
> Bar:
> Baz = 1
> ...
> ...
> 
> and
> So what I want to do is pull out all Foos who have a baz == 1.

How about @"ALL Bars.baz = 1" ? Have you read the Predicate Programming
Guide 
 ?

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Bindings for NSComboBox?

2008-03-31 Thread David Springer

All,

I'm having trouble setting up the bindings for my NSComboBox.  I bind
the NSComboBox's content to NSArrayController's arrangedObjects.  This
works fine.

Now, I want to add to the content array when you enter a new string
into the combo box.  Say, for example, I start with an array of @"file
1", @"file 2", @"file 3".  Then, in the combo box, I enter "file foo".
 I want to add this string to the content array, but I am at a loss as
to how to set up the bindings to do this.  Do I bind NSComboBox's
value to something?  My experiments in doing this so far are failing.

Help?
- Dave.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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Threads and Core Data, bindings results in view corruption

2008-03-31 Thread David

I found a post with a solution similar to what I was asking about,
http://lists.apple.com/archives/student-dev/2006/Jun/msg00104.html
Essentially he proposed to maintain multiple mocs in sync using an in memory
persistent store. But I worry that that will be too slow and consume
excessive memory.
___

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]

remote debugging between ppc & intel

2008-03-31 Thread Daniel Child

I have a project that is going to require remote debugging, and I am  
wondering if there are any restrictions on remote debugging between a  
PowerPC Mac and one of the newer Intel machines. Apple's  
documentation makes no mention of this other than for the case of  
panic kernels.


Can one computer be running Tiger, the other Leopard? Would there be  
any other problems to anticipate?


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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Returning values from objc_msgSend etc

2008-03-31 Thread Sherm Pendley

On Mon, Mar 31, 2008 at 1:03 PM, Greg Parker <[EMAIL PROTECTED]> wrote:

> On Mar 31, 2008, at 8:34 AM, Sherm Pendley wrote:
> > On Sat, Mar 1, 2008 at 9:00 AM, Greg Parker <[EMAIL PROTECTED]> wrote:
> >>
> >> I don't think libffi does any type promotion.
> >
>
> ffi_call(3) says:
> "rvalue must point to storage that is sizeof(long) or larger. For
> smaller return value sizes, the ffi_arg or ffi_sarg integral type must
> be used to hold the return value."
> ...
> ...which means this isn't allowed. In fact, it's probably smashing
> memory on your stack.

I guess I may have misunderstood the term then. That sounds like type
promotion of the return value to me. :-)

Sorry about the noise.

sherm--
___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: libpq prepared statement

2008-03-31 Thread Andrew Farmer


On 31 Mar 08, at 12:44, Justin Giboney wrote:
p.s. why is it that Apple has no documentation on having Cocoa work  
with Databases? Try typing in "mysql" or "postgresql" in the search  
box of this page http://developer.apple.com/cocoa/ while restricting  
it to cocoa. Do they not want business to use Cocoa?


Neither MySQL or PostgreSQL is a component of the Cocoa framework.  
Apple's not responsible for documenting how you might use arbitrary  
libraries with Cocoa - at a certain point, you're on your own.

___

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]

linked list problem

2008-03-31 Thread Nick Rogers


Hi,
I have the following singly linked list:

typedef struct Dir
{
// some space to hold data here
	void *next;	// have to take void * here cause Dir* leads to compile  
error

}DIR;

In my code:

DIR *temp = parentDir;	//parentDir is allocated initially but its  
next is not allocated at this point

while (temp)
{
temp = (DIR*)temp->next; //here next is null so, temp now is null
}
temp = newDir;		//here newDir is already allocated, but temp doesn't  
get allocated, in a way parentDir->next remains null.



While this type of code works fine on VS2005, it doesn't wprk here in  
cocoa.

How else can I reach the end of the list and add a new node?

Please help.

Thanks,
Nick
___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: Threads and Core Data, bindings results in view corruption

2008-03-31 Thread Ben Trumbull


At 4:05 PM -0400 3/31/08, Ben Lachman wrote:
You also should try using an SQLite store.  It will be faster than a 
binary store for saving incrementally since it only touches part(s) 
of the file.


Binary store ? Binary store ?

The xml, binary, and custom atomic stores are all atomic.  The entire 
file gets read or written.  No partial loading, no partial saving. 
Those 3 stores behave similarly to NSKeyedArchiver.


They act a lot like document based apps such as Text Edit.  No 
incremental operations.


Having multiple threads save to an atomic store is kinda crazy. 
Definitely highly discouraged.


Even without multiple threads, the sqlite store outperforms them in 
straight up races once you get to a few hundred records.  More or 
less depending on just how big your records are.  It performs 
comparably on smaller data sets, and is only slower for very tiny 
sets (like 10).


On 10.5, with Core Data's SQLite store, I get insertion speeds of 
about ~29,000 rows/s on a quad core Mac Pro, and fetch speeds of 
~800,000 rows/s.


David, your morale should improve dramatically by changing that 1 
argument in -addPersistentStore:...


Once you get to one thousand record, the only reason to use a binary 
store is if you really really need that atomic behavior, and you're 
willing to pay for it.


For example, if you require soft real time constraints, and loading 
the data into memory is more desirable than accidentally firing a 
fault at any time in the future.


Similarly, the xml and custom atomic stores are for managing an 
external, possibly public, data format.  Not for performance, not for 
concurrent operations.

--

-Ben
___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: Problem with setting color in NSBitmapImageRep

Don't know why you got this problem, but if I had to fill a bitmap  
using a simple gradient, i would probably use either CGGradient  
(Leopard required) or CGShading (if you want a greater control of the  
shading function, etc…).


It can be done like this:

NSGraphicsContext *ctxt = [NSGraphicsContext   
graphicsContextWithBitmapImageRep:imageRep]; /* see doc for details  
about bitmap format supported */

CGContextRef cgctxt = [ctxt graphicPort];
CGShadingRef shading = CGShadingCreate(...); /* see Quartz 2D  
programming guide */

CGContextDrawShading(cgctxt, shading);
CGShadingRelease(shading);

This will be really faster than creating a NSColor object for each  
pixel.


In the same way, you can fill it with an uniform color using  
CGContextFillRect() function.


And is you want to use Cocoa drawing function instead, set your new  
context as the current context using -[NSGraphicsContext  
setCurrentContext:] and the you will be able to call NSBezierPath  
function for example.



Le 31 mars 08 à 21:30, Christian Kaiser a écrit :

I'm struggling with setting color in a NSBitmapImageRep. I'm  
computing the components of a NSColor according to a numeric value;  
its basically a linear interpolation between all components of two  
NSColors. I've got a function which is computing the new NSColor  
based on a given value. If I call this function repeatedly using the  
same value and setting the color using NSBitmapImageRep  
setColor:atX:y:, I expect to have a uniform image if applying to all  
pixels. But this is not the case...! What am I missing ?


As I'm probably a little bit confusing, here the code producing my  
strange image :




  // Creating two colors which define a gradient. The color for our  
image

  // will be computed using this gradient.

  NSColor *lightYellow =
  [NSColor colorWithCalibratedRed:0.97 green:0.93 blue:0.65  
alpha:1.0];

NSColor *darkRed =
  [NSColor colorWithCalibratedRed:0.69 green:0.09 blue:0.11  
alpha:1.0];



  // Creating an empty image with the same color space.

  NSBitmapImageRep *img = [[NSBitmapImageRep alloc]
  initWithBitmapDataPlanes:NULL
  pixelsWide:10
  pixelsHigh:10
  bitsPerSample:8
  samplesPerPixel:3
  hasAlpha:NO
  isPlanar:YES
  colorSpaceName:[lightYellow colorSpaceName]
  bitmapFormat:0
  bytesPerRow:0
  bitsPerPixel:0];

  // Assigning the same (???) color to all pixels.
  int x, y;
  for (y = 0; y < 10; y++)
  {
  for (x = 0; x < 10; x++)
  {
  NSColor *imgColor = [GradientColor gradientColorWithValue: 
40.0

  minColor:lightYellow maxColor:darkRed
  minValue:30.0 maxValue:60.0];
[img setColor:imgColor atX:x y:y];
  }
  }
  [[img TIFFRepresentation]
  writeToFile:@"/Users/chkaiser/Desktop/img.tif" atomically:YES];


And the function computing the gradient color based on our values:

+(NSColor*)gradientColorWithValue:(double)value minColor:(NSColor*)c1
  maxColor:(NSColor*)c2 minValue:(double)v1 maxValue:(double)v2
{
// Color components.
  CGFloat comps1[5];
  [c1 getComponents:comps1];
  CGFloat comps2[5];
  [c2 getComponents:comps2];
// Compute the multiplication factor for the value. This factor  
has

  // a value between 0 and 1.
  double factor = (value - v1) / (v2 - v1);
// Compute the new components.
  int i;
  CGFloat newComps[5];
  for (i = 0; i < [c1 numberOfComponents]; i++)
  {
  newComps[i] =
  (factor * (comps2[i] - comps1[i])) +
  comps1[i];
  }
// Create the new color with the computed components.
  NSColor *newColor = [NSColor colorWithColorSpace:[c1 colorSpace]
  components:newComps count:[c1 numberOfComponents]];
return newColor;
 }


What is going wrong here ?

I have not found any similar topic on this list until now, even if  
it seems to me quite strange. Is there something obvious I am  
missing ?


--Christian Kaiser


___

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/devlists%40shadowlab.org

This email sent to [EMAIL PROTECTED]



___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: linked list problem

2008-03-31 Thread stephen joseph butler

On Mon, Mar 31, 2008 at 4:31 PM, Nick Rogers <[EMAIL PROTECTED]> wrote:

> Hi,
> I have the following singly linked list:
>
> typedef struct Dir
> {
>// some space to hold data here
>void *next; // have to take void * here cause Dir* leads to
> compile
> error
> }DIR;

It won't compile because at this point Dir isn't typedefed, so C requires
"struct Dir". So...

typedef struct Dir
{
   // some space to hold data here
   struct Dir *next;
}DIR;

> In my code:
>
> DIR *temp = parentDir;  //parentDir is allocated initially but its
> next is not allocated at this point
> while (temp)
> {
>temp = (DIR*)temp->next;//here next is null so, temp now is
> null
> }
> temp = newDir;  //here newDir is already allocated, but temp
> doesn't
> get allocated, in a way parentDir->next remains null.
>
>
> While this type of code works fine on VS2005, it doesn't wprk here in
> cocoa.
> How else can I reach the end of the list and add a new node?

There is no way the code you show works for any C compiler, let alone
VS2005. You never do the linking part of the linked list.

Besides, none of this is really Cocoa so it doesn't belong on this list.
___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: Threads and Core Data, bindings results in view corruption

2008-03-31 Thread Ben Trumbull


At 4:05 PM -0400 3/31/08, Ben Lachman wrote:
If you needed to do further work on that entity, like adding 
relationships to it, then it would get to be trickier, as you'd 
also need to get its managedObjectID back to your thread.


Actually this isn't true.  You can add relationships, etc. without 
having to pass them around since you will be doing a save at some 
point and that will sync everything back to the persistent store.
Then, once you pass the OID of your newly inserted object back to 
you main thread you can fetch it from the store and the 
relationships you added to it, etc. will be intact.


On 10.5, if you use NSMergeByPropertyObjectTrumpMergePolicy, you can 
add and remove objects from relationships in a different MOC on a 
background thread and just let the merge policy figure it out.


This even works from another process, if you use an sqlite store.

If you're doing a lot of background operations, you'll want to 
familiarize yourself with the MOC's merge policies.


Lastly, I kind of wonder if there might be some way to integrate a 
secondary In-Memory store into this setup for use in passing the 
objects created by the worker thread back to the main thread, it 
seems like it might introduce some more complexity but might also be 
worthwhile performance-wise since saving to the SQL store does have 
a certain amount of latency due to how it hits the disk 
(particularly on Tiger).  Any thoughts on this Ben?


Probably less important on 10.5, but yes, you could do this.  The 
easiest way would be for the background thread to push changes to the 
main thread with -performSelectorOnMainThread: ... more aggressively 
with NSManagedObjects saved to the in memory store, and "clone" them 
over to the sqlite store in larger, coalesced batches.


After saving the "real" one, pass a message to the main thread to 
remove the temporary one, and use the real one.  You'll want to catch 
user edits in the intervening window.

--

-Ben
___

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]

Cocoa GUI app invocation from CLI with arguments

2008-03-31 Thread Mac QA

Hi,

In the past I have written a few little Cocoa programs that when
double-clicked are opened in GUI mode, or can also be invoked from the
CLI by passing in a few arguments. In those situations when invoking
from the CLI I never actually displayed a GUI, but just performed the
same core functionality w/o a GUI. However, now I have the situation
of having a pre-existing GUI app that I would like to add a CLI
interface to. What is different is that I want to pass the CLI
arguments into the text fields of the GUI, not just use the values to
start executing some core functionality. I am unclear how to
accomplish this. Can anyone suggest how, when invoked from the CLI, I
can throw up my existing GUI and then fill in the values from the CLI
into the corresponding fields of the GUI. Any suggestions are
appreciated. 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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: linked list problem

2008-03-31 Thread Andrew Farmer


On 31 Mar 08, at 14:39, stephen joseph butler wrote:

On Mon, Mar 31, 2008 at 4:31 PM, Nick Rogers <[EMAIL PROTECTED]> wrote:

In my code:

DIR *temp = parentDir;  //parentDir is allocated initially but its
next is not allocated at this point
while (temp)
{
  temp = (DIR*)temp->next;//here next is null so, temp  
now is

null
}
temp = newDir;  //here newDir is already allocated, but temp
doesn't
get allocated, in a way parentDir->next remains null.


While this type of code works fine on VS2005, it doesn't wprk here in
cocoa.
How else can I reach the end of the list and add a new node?



There is no way the code you show works for any C compiler, let alone
VS2005. You never do the linking part of the linked list.


In particular, the (effective) code sequence

A = B;
B = C;

does not set A to C in any language I'm familiar with.

Also, I'd recommend against naming any type DIR, as there's a libc  
type by that name in .

___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: Simple menu-action question

2008-03-31 Thread Rick Mann



On Mar 30, 2008, at 7:58 PM, Graham Cox wrote:
I'm not sure if using Core Data would make a difference, but I'd  
just do this by responding to the menu command by putting up an  
NSOpenPanel then processing the filename it returns appropriately. I  
don't think there's any magic "proper" way to do this within the  
document architecture, except for...


No, I didn't mention Core Data because I thought it would change the  
way this was done, just for completeness.


Just list the file types (UTIs) that you can open in your info plist  
and map them to different NSDocument subclasses (if indeed a  
different document type is used for each different file type) or map  
different UTIs to the same class and differentiate the file type  
passed in the document's -readFromURL:ofType:error: method. This  
latter approach means you don't even need an "Import" menu, it just  
integrates into the existing Open file menu, which is more user  
friendly in my book - it "just works" rather than the user having to  
worry about what "Import" really means and whether, why and when  
they need to use it.


Well, I guess it's a separate argument as to whether or not "Import"  
should be used instead of "Open". I tend to think of "Import" as being  
used to add to an existing document's data (creating one if none  
exists), and for data types that are not "native" to the app.


It's easy enough to make my app open more document types, but that  
doesn't really get at the core of the problem...how does one add  
fundamental commands similar to Open? They're targeted at the first  
responder, and it seems that typically, one does not subclass  
NSApplication. Who handles these actions when the messages are sent,  
in the varying cases of having a document open, vs. no document open,  
etc?


--
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Cocoa GUI app invocation from CLI with arguments



You can get cli arguments at anytime using NSProcessInfo.

- [[NSProcessInfo processInfo] arguments];

So just get them in -applicationDidFinishLaunching or in -awakeFromNib  
and do what you need with them.



Le 1 avr. 08 à 00:18, Mac QA a écrit :


Hi,

In the past I have written a few little Cocoa programs that when
double-clicked are opened in GUI mode, or can also be invoked from the
CLI by passing in a few arguments. In those situations when invoking
from the CLI I never actually displayed a GUI, but just performed the
same core functionality w/o a GUI. However, now I have the situation
of having a pre-existing GUI app that I would like to add a CLI
interface to. What is different is that I want to pass the CLI
arguments into the text fields of the GUI, not just use the values to
start executing some core functionality. I am unclear how to
accomplish this. Can anyone suggest how, when invoked from the CLI, I
can throw up my existing GUI and then fill in the values from the CLI
into the corresponding fields of the GUI. Any suggestions are
appreciated. 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:
http://lists.apple.com/mailman/options/cocoa-dev/devlists%40shadowlab.org

This email sent to [EMAIL PROTECTED]


___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: linked list problem



Le 1 avr. 08 à 00:19, Andrew Farmer a écrit :


On 31 Mar 08, at 14:39, stephen joseph butler wrote:
On Mon, Mar 31, 2008 at 4:31 PM, Nick Rogers <[EMAIL PROTECTED]>  
wrote:

In my code:

DIR *temp = parentDir;  //parentDir is allocated initially but its
next is not allocated at this point
while (temp)
{
 temp = (DIR*)temp->next;//here next is null so, temp  
now is

null
}
temp = newDir;  //here newDir is already allocated, but temp
doesn't
get allocated, in a way parentDir->next remains null.


While this type of code works fine on VS2005, it doesn't wprk here  
in

cocoa.
How else can I reach the end of the list and add a new node?



There is no way the code you show works for any C compiler, let alone
VS2005. You never do the linking part of the linked list.


In particular, the (effective) code sequence

A = B;
B = C;

does not set A to C in any language I'm familiar with.

Also, I'd recommend against naming any type DIR, as there's a libc  
type by that name in .




And as we are talking about libc. The libc already provide linked  
list. 'man queue' for details.



___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: Cocoa GUI app invocation from CLI with arguments

2008-03-31 Thread Jens Alfke



On 31 Mar '08, at 3:18 PM, Mac QA wrote:


Can anyone suggest how, when invoked from the CLI, I
can throw up my existing GUI and then fill in the values from the CLI
into the corresponding fields of the GUI.


You can get the command-line arguments as [[NSProcessInfo processInfo]  
arguments].


—Jens

smime.p7s
Description: S/MIME cryptographic signature
___

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

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

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

This email sent to [EMAIL PROTECTED]

Re: Simple menu-action question