Is there a way to detect if user adds Printer?

2012-06-07 Thread Marc Van Olmen
hi,

Is there a way to detect if the user added/removed a printer while my app is 
running? 

I'm currently displaying a popup with the contents of [NSPrinter printerNames] 
but my app would like to be notified when changes are happening to this 
contents.

thanks for some ideas.

marc
___

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

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

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

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


Removing an NSOpenGLView causes default background to be drawn.

2009-07-15 Thread Marc Van Olmen

Hi,

When I remove and NSOpenGLView or when I close a window that has an  
NSOpenGLView that area is drawn over with his default background color  
(in my case this is Black).
This only happens depending on how long it takes to replace or close  
that window. I can see it in my app when I quit because that takes a  
while.


I have a few ideas on how I can get rid of this visual effect. But I  
wanted to poke around if other people have seen it and solved it.


The effect that I see can be easily tested with any simple  
NSOpenGLView application. I tested an standard cocoa sample app:



http://www.mataderu.com/xphere/info/cocoa_tut01/index.html


Cocoa Appkit is calling CGLClearDrawable on the opengl context before  
it is getting removed then later on it removes the context and calls  
CGSRemoveSurface this last call when that is finished calling causes  
the black (or white depending your setting) area to appear.


To simulate the slow quiting/replacing i can demonstrate it with  
Debugger trick:


I run it with the debugger and put a breakpoint at CGSRemoveSurface. I  
quit the application, then it hits that breakpoint, and the window  
still looks normal. Then when I step out of this method it becomes  
white. Which is like the NSOpenGLView standard background color.

Here is the stack trace:


#0 0x954711ad in -[NSSurface _disposeSurface]
#1 0x9679e53c in _nsnote_callback
#2 0x912d764a in __CFXNotificationPost
#3 0x912d7923 in _CFXNotificationPostNotification
#4 0x9679b690 in -[NSNotificationCenter  
postNotificationName:object:userInfo:]

#5 0x967a4ee8 in -[NSNotificationCenter postNotificationName:object:]
#6 0x9553c710 in -[NSWindow _close]
#7 0x91364be5 in -[NSArray makeObjectsPerformSelector:]
#8 0x955dab93 in -[NSApplication _deallocHardCore:]
#9 0x955d98b1 in -[NSApplication terminate:]
#10 0x954fa4cb in -[NSApplication sendAction:to:from:]
#11 0x955a9108 in -[NSMenu performActionForItemAtIndex:]
#12 0x955a8e0d in -[NSCarbonMenuImpl  
performActionWithHighlightingForItemAtIndex:]

#13 0x955a8a93 in -[NSMenu performKeyEquivalent:]
#14 0x955a7338 in -[NSApplication _handleKeyEquivalent:]
#15 0x954c40fb in -[NSApplication sendEvent:]
#16 0x9542162f in -[NSApplication run]
#17 0x953ee834 in NSApplicationMain
#18 0x1b64 in main at main.m:13



Any ideas on how I can get rid of this last minute view clearing?.


marc
___

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

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

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

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


Re: Scheduling a selector when a thread completes

2009-04-29 Thread Marc Van Olmen
* You could use NSOperationQueue and set the maximumThread count to 1.  
and make for each of these methods an NSOperation. And then add those  
4 operations to your OperationQueue.


* But your case is simple so you can easily code this your self by  
creating an object for each operation you are performing. and create  
an Operation Array


yourself.

cheers,

marc



On Apr 29, 2009, at 9:55 PM, kentoz...@comcast.net wrote:


Hi


I wrote a directory scanner application that spawns 4 different  
threads with independent rescan intervals and need to repeat the  
process if and only if a thread has completed a scan. Basically, for  
each file type I'm watching, the process is



1. Spawn a thread to sample files of the specified type
2. Wait until the thread completes
3. Schedule another pass after a given time interval has passed.


Timer's don't work for my purposes because the execution time of the  
thread can easily exceed any arbitrary repeat interval I might  
choose which would require the use of busy flags and testing for a  
busy state etc... I want to avoid that.



I tried calling NSObject's


performSelector:(SEL) aSelector   withObject:(id) anArgument
afterDelay:( NSTimeInterval ) delay




But the receiver's  aSelector  method is never getting called. The  
only logical place to perform this scheduling is from inside the  
thread because only the thread knows when it is finished, but I'm  
having no luck getting the method to run.



Here are the methods that spawn the threads




- ( void ) initDirectories

{

 [ NSThread detachNewThreadSelector : @selector  
( initDirectoriesInThread :)


  toTarget : self

  withObject : nil ];

}




- ( void ) updateDirectories

{

 // Logging function that writes messages to my app's custom  
console view



KCLog ([ NSString stringWithFormat : @Checking for changes:  
%@ , userType]);





[ NSThread detachNewThreadSelector : @selector  
( updateDirectoriesInThread :)


toTarget : self

withObject : nil ];

}




And here are the corresponding thread methods






- ( void ) initDirectoriesInThread:( id ) inData

{

 @synchronized ( self )

 {

// allocate a new autorelease pool

NSAutoreleasePool *pool = [[ NSAutoreleasePool alloc ] init ];




KDirectory *rootDirectory = [ KDirectory directoryWithPath :  
path ];


rootObserver = [[ CNCDirectoryWatcher alloc ]  
initWithDirectory : rootDirectory root : self ];





// add root directory to observed list

[ self addDirectory : rootObserver ];




// schedule a new pass

[ self performSelector : @selector ( updateDirectories )  
withObject : nil afterDelay : catalogInterval ];





// release the pool

[pool release ];

}

}




- ( void ) updateDirectoriesInThread:( id ) inData

{

@synchronized ( self )

{

// allocate a new autorelease pool

NSAutoreleasePool *pool = [[ NSAutoreleasePool alloc ] init ];

 NSArray *dirs = [ directories copy ];


NSEnumerator *enumerator = [dirs objectEnumerator ];

 CNCDirectoryWatcher *directory;





while (directory = [enumerator nextObject ])

{

[directory update ];

}




// schedule a new pass

[ self performSelector : @selector ( updateDirectories )  
withObject : nil afterDelay : catalogInterval ];





// release the pool

[pool release ];

}

}


The initDirectoriesInThread method is getting called and runs  
correctly, but the updateDirectoriesInThread method never gets  
called.



I looked at


-(void)performSelectorOnMainThread:(SEL) aSelector   withObject:(id)  
arg   waitUntilDone:(BOOL) wait




But it doesn't appear to have a way to schedule the execution for a  
specified delay.



Is there a way to use  performSelector: withObject: afterDelay: to  
satisfy both step 2 and 3 above?



Thanks for any help

___

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/mvo%40sky4studios.be

This email sent to m...@sky4studios.be


___

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

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

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

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


Re: Bug+Fix: NSController (and subclasses) have problems with custom KVO keys

2009-03-26 Thread Marc Van Olmen


I just wanted to update this thread so that people that google for  
info see this update.


I got a confirmation from Apple that they are aware of this bug and  
that they are working on it.


regards,

Marc


On Mar 19, 2009, at 6:16 PM, m...@sky4studios.be wrote:


On Mar 19, 2009, at 12:03, m...@sky4studios.be wrote:


In this narrowed down code of the bug it will log this on
removeObserver
(please ignore the Terminating app due to uncaught exception
'NSInternalInconsistencyException', reason) because  I just created
simple
main sample code to narrow it down:

*** Terminating app due to uncaught exception
'NSInternalInconsistencyException', reason: 'Cannot remove an  
observer

Observer 0x10ac00 for the key path targetPhoto.name from
NSMyArrayController 0x1099d0, most likely because the value for
the key
targetPhoto has changed without an appropriate KVO notification
being
sent. Check the KVO-compliance of the NSMyArrayController class.'


This is not a lot of help to you, but I vaguely remember a discussion
on this list a couple of months ago about problems with KVO on
subclassed NSArrayControllers. I can't find the thread, but I did  
find

that someone has been here before you:

http://www.cocoabuilder.com/archive/message/cocoa/2008/4/15/204196


good catch i didn't find that one, at least i made some simple  
sample code
to point out the bug to Apple Developers, so hopefully they can  
address it

now.

Why it should fail is not clear, but it may be that the code that  
adds

observers does something special with NSArrayControllers (but doesn't
realize your class is a subclass, or can't work properly if it's a
subclass).

Alternatively, it may be a side effect of the well-known defect in
NSArrayController where its KVO notifications don't contain the  
proper

new/old values.

If I understand your workaround correctly, it bypasses (what we  
assume

to be) NSArrayController's own overrides of didChange.../
willChange... . That may get your custom property observer
notifications to work properly, but my guess is that this will break
(some) behavior of any objects using the NSArrayController's usual
notifications.


I call [super didChange... for non-custom keys and  I'm calling  
NSObject

didChange in case it is my custom key. So hopefully this address that
issue...

I haven't tested my patch long enough to say it will work 100% in all
scenarios but at least in the app I'm working on everything seems to  
work

ok so far... (need a few more days of testing before..).



A better workaround strategy might be to avoid subclassing
NSArrayController, and find another way to achieve what subclassing
was going to get for you.



___

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/mvo%40sky4studios.be

This email sent to m...@sky4studios.be


___

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

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

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

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


KVO notification not properly propagated isuse

2009-03-15 Thread Marc Van Olmen

hi,

Tracing an issue where a KVO notification wasn't propagated to all  
objects.


I added observation to an array controller

[mArrayController addObserver: self
   
forKeyPath:@arrangedObjects.photoTransformationSettings.filmType
  options:0
  context:kMyContextPtr];

and notification

- (void)observeValueForKeyPath:(NSString *)theKeyPath
ofObject:(id)theObject
change:(NSDictionary *)theChange
context:(void *)theContext

was never called, but I had a few other KVO that were bound directly  
to one of those objects that worked.


So after some debugging I realized that the cause was the  
ArrayController, and the fix for this was the following.


The array controller also had some KVO defined itself and

- (void)observeValueForKeyPath:(NSString *)theKeyPath
ofObject:(id)theObject
change:(NSDictionary *)theChange
context:(void *)theContext

{


 ... existing code

 // This line was added:

 [super observeValueForKeyPath: theKeyPath ofObject:theObject  
change:theChange  context:theContext];

}


And then the above KVO worked. So I'm curious now why I need to add


 [super observeValueForKeyPath: theKeyPath ofObject:theObject change:t

Because the documentation doesn't say anything about that. Is there a  
documented reason when you have to call [super  
observeValueForKeyPath ...]?


cheers

marc
___

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

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

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

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


Job Opportunity: Experienced Cocoa User Interface Developer ( Full Time, New York City)

2009-01-21 Thread Marc Van Olmen
Experienced Cocoa User Interface Developer (full time position, New  
York City)


Responsibilities:

• Participate in design activities with team members
• Discuss requirements with end users
• Sketch and wireframe possible user interfaces
	• Implement, test, debug, document and integrate new User Interface  
components into existing code base

Requirements:

• Very good knowledge of Cocoa/Objective-C
• At least 3 year experience with Cocoa/Objective-C
• Must have worked on shipping Cocoa products
• Experience with Quartz
• Experience with customizing Cocoa controls
• Passion for user interface design
• Knowledge of Apple Human Interface Guidelines
	• Ability to work on-location in Manhattan (no off-site consultants  
please)

Useful experience:

• OpenGL
• Subversion or git
Job Benefits (beside the industry standards):

	• Be part of a small team of experienced developers who enjoy  
creative freedom.

• Work in a large, bright Manhattan office.
	• Contribute to an exciting product that will be publicly launched to  
change the world of digital photography.

Who is Boxwork

Boxwork is the digital division of Box, a multimedia company that  
combines technical innovation and artistic sensibility. Using  
customized tools we offer a full suite of creative services from  
digital capture and image fabrication to exhibition and book  
publishing. Work by Box regularly appears on the covers and pages of  
major publications, television and cable networks, in fine art books  
and museums as well as some of the world's leading advertising  
campaigns.


Boxwork includes an internal research and development team that acts  
as a think tank to create novel solutions for internal and external  
production and administrative challenges. Our expert programmers,  
engineers and technicians work side by side to quickly turn ideas into  
realities. As a result we have several software and hardware products  
that have given us a range of tools to address digital capture,  
digital asset management, workflow oversight, color profiling, color  
enhancement and color management. We see these tools as a  
differentiator that keeps Box continually on the forefront of the  
industry.


Please send your resumes to:

boxworkj...@boxstudios.com___

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

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

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

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


Distributed objects NSURL is always encoded as proxy? is this a bug?

2008-09-13 Thread Marc Van Olmen

hi,

I have an NSURL that is encoded by:

[theCoder encodeBycopyObject:mFileURLSource];


but I notice that when i double check on the InitWithCoder that

mFileURLSource = [[theCoder decodeObject] retain];
if ([mFileURLSource isProxy] == YES)
{
OS_DEBUG_LOG(@MFileURLSOUrce is still a proxy object);
}

It is always a proxy object...

Al the other ivars in my object are encoded fine (they are NSNumber,  
NSDate and NSString classes.


I'm wondering if there is some kind of exception with NSURL?

regards,


marc
___

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: Distributed objects NSURL is always encoded as proxy? is this a bug?

2008-09-13 Thread Marc Van Olmen

Thanks for the thought Ken.
It was causing an invocation. That's why I tested for Proxy didn't  
look at the class, in the debugger, because gdb couldn't resolve the  
class, when i was trying it.

cheers,
marc
On Sep 13, 2008, at 5:27 PM, Ken Thomases wrote:


On Sep 13, 2008, at 11:12 AM, Marc Van Olmen wrote:


It is always a proxy object...

I'm wondering if there is some kind of exception with NSURL?


Have you checked with a debugger what the real class (the isa  
pointer) of the object is?  Just because it's a proxy doesn't mean  
it's an NSDistantObject (i.e. a Distributed Objects proxy).  Maybe  
NSURL is just implemented in terms of a proxy for some reason.  (I  
have no reason to believe it is, but who knows?)


Cheers,
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]


Job Opportunity: Box Services hiring a full-time Cocoa User Interface Developer, New York City

2008-03-20 Thread Marc Van Olmen
By list etiquette rules, please any responses to this e-mail, should  
be addressed directly and only to: [EMAIL PROTECTED]


-
Boxwork, the digital division of Box Services LLC, is responsible for  
research, software development, and digital photography capture.


We are looking to expand our MacOS X Software development team. As a  
software engineer at Boxwork, you will play a vital role in designing  
and implementing the next generation of Boxwork's Media Asset  
Management system. Your contributions at Boxwork will directly impact  
the quality of magazine photography around the world.


Cocoa User Interface Developer (full time position):

Requirements:
* Knowledge of Cocoa/Objective-C
* Passion for user interface design
* Knowledge of Apple Human Interface Guidelines
* Ability to sketch and prototype user interfaces (experience with  
mockups and wireframes)

* Good communication skills
* Ability to work on-location in Manhattan's meat-packing district (no  
off-site consultants please)


Additional useful experience:
* OpenGL
* Quartz
* Experience with interactive user interface design for web development

Please send resumes to: [EMAIL PROTECTED]

Regards,

Marc Van Olmen
Senior Software Architect
Box Services LLC
412W 14th Street,
New York, NY 10014
http://www.boxwork.com
http://www.boxstudios.com
___

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

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

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

This email sent to [EMAIL PROTECTED]