How to start a Dashboard widget as soon as the user logs in?

[Behrang Saeedzadeh]

Hi,

I want to write a dashboard widget that starts up working in the
background as soon as the user logs in to his account and that plays a
chime whenever a specific event occurs (i.e it should be always running
in the background). Is this possible at all?

Cheers,


-- 
Cheers,
Behrang Saeedzadeh
http://www.behrang.org
___

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: How to start a Dashboard widget as soon as the user logs in?

[John Joyce]

> Hi,
> 
> I want to write a dashboard widget that starts up working in the
> background as soon as the user logs in to his account and that plays a
> chime whenever a specific event occurs (i.e it should be always running
> in the background). Is this possible at all?
> 
> Cheers,
> 
> 
> -- 
> Cheers,
> Behrang Saeedzadeh
> http://www.behrang.org
> ___


Dashboard Widgets do not begin doing anything until the first time the user 
launches Dashboard.

___

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: How to start a Dashboard widget as soon as the user logs in?

[Joanna Carter]

Le 22 mai 2011 à 09:43, John Joyce a écrit :

> Dashboard Widgets do not begin doing anything until the first time the user 
> launches Dashboard.

I would think the best option for Behrang would be to write an ordinary app, 
that can be launched on startup, that provides the services behind a Dashboard 
Widget, which the widget simply "connects" to.

Joanna

--
Joanna Carter
Carter Consulting

___

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: How to start a Dashboard widget as soon as the user logs in?

[Kyle Sluder]

On Sun, May 22, 2011 at 1:57 AM, Joanna Carter
 wrote:
> I would think the best option for Behrang would be to write an ordinary app, 
> that can be launched on startup, that provides the services behind a 
> Dashboard Widget, which the widget simply "connects" to.

Yes, this is the way to go. But it's also possible to use a launch
agent, and therefore avoid having an app icon in the dock.

--Kyle Sluder
___

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

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

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

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

Re: How to start a Dashboard widget as soon as the user logs in?

[Andy Lee]

On May 22, 2011, at 12:15 PM, Kyle Sluder wrote:
> On Sun, May 22, 2011 at 1:57 AM, Joanna Carter
>  wrote:
>> I would think the best option for Behrang would be to write an ordinary app, 
>> that can be launched on startup, that provides the services behind a 
>> Dashboard Widget, which the widget simply "connects" to.
> 
> Yes, this is the way to go. But it's also possible to use a launch
> agent, and therefore avoid having an app icon in the dock.

I don't understand the need for a Dashboard widget at all?

--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/archive%40mail-archive.com

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

NSCursor

[Adam Gerson]

I am trying to understand NSCursor better. I have an animation that
takes place in my view and I dont want to allow any mouse or keyboard
interaction while the animation is running. That is easy to do. While
this is happening I want to display some kind of custom "waiting"
cursor which I have been able to do with:

NSCursor *cursor2 = [[NSCursor alloc] initWithImage:[NSImage
imageNamed:@"HourGlass"]
hotSpot:NSMakePoint(1,1)];

[cursor2 set];
___

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

NSCursor - ignore previous (was incomplete)

[Adam Gerson]

I am trying to understand NSCursor better. I have an animation that
takes place in my view and I don't want to allow any mouse or keyboard
interaction while the animation is running. That is easy to do. While
this is happening I want to display some kind of custom "waiting"
cursor which I have been able to do with:

NSCursor *cursor2 = [[NSCursor alloc] initWithImage:[NSImage
imageNamed:@"HourGlass"]
hotSpot:NSMakePoint(1,1)];
[cursor2 set];

I am not sure exactly where this code belongs or how to keep the
cursor set this way. When I begin my animation I set the cursor, but
it very quickly goes back to the "arrow". I believe this is happening
when some of my views are getting redrawn with setNeedsDisplay which
is part of what is happening in the background. Is there any way to
get a custom cursor to stay set even if the view is redrawn and stay
set until I manually set it back?

Thanks,
Adam
___

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: How to start a Dashboard widget as soon as the user logs in?

[Kyle Sluder]

On Sun, May 22, 2011 at 9:36 AM, Andy Lee  wrote:
> I don't understand the need for a Dashboard widget at all?

Because some people prefer it to Growl or utility widget apps?

--Kyle Sluder
___

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

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

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

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

Re: How to start a Dashboard widget as soon as the user logs in?

[Lee Ann Rucker]

I can imagine one - I had an otherwise cool astronomy widget I finally tossed 
because every time I launched Dashboard I had to wait 5-10 seconds for *any* 
widget to be functional while it fetched the latest content.

Something that ran in the background and fetched data for it every few hours or 
so, so that it could just pop up instantly like a widget ought to, would've 
been so much nicer.

- Original Message -
From: "Andy Lee" 
To: "Kyle Sluder" 
Cc: "John Joyce" , Cocoa-dev@lists.apple.com
Sent: Sunday, May 22, 2011 9:36:31 AM
Subject: Re: How to start a Dashboard widget as soon as the user logs in?

On May 22, 2011, at 12:15 PM, Kyle Sluder wrote:
> On Sun, May 22, 2011 at 1:57 AM, Joanna Carter
>  wrote:
>> I would think the best option for Behrang would be to write an ordinary app, 
>> that can be launched on startup, that provides the services behind a 
>> Dashboard Widget, which the widget simply "connects" to.
> 
> Yes, this is the way to go. But it's also possible to use a launch
> agent, and therefore avoid having an app icon in the dock.

I don't understand the need for a Dashboard widget at all?

--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/lrucker%40vmware.com

This email sent to lruc...@vmware.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

Re: How to start a Dashboard widget as soon as the user logs in?

[Andy Lee]

On May 22, 2011, at 2:10 PM, Kyle Sluder wrote:
> On Sun, May 22, 2011 at 9:36 AM, Andy Lee  wrote:
>> I don't understand the need for a Dashboard widget at all?
> 
> Because some people prefer it to Growl or utility widget apps?

Behrang's wish is to play a background chime when certain things happen. It's 
been suggested that Behrang write two things that will work together: an app 
and a widget. If an app has to be written anyway, why not have *it* play the 
background chime? It's not like it will matter whether the UI is in the app or 
in the widget.

--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/archive%40mail-archive.com

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

Re: How to start a Dashboard widget as soon as the user logs in?

[Kyle Sluder]

On May 22, 2011, at 1:22 PM, Andy Lee  wrote:

> Behrang's wish is to play a background chime when certain things happen. It's 
> been suggested that Behrang write two things that will work together: an app 
> and a widget. If an app has to be written anyway, why not have *it* play the 
> background chime? It's not like it will matter whether the UI is in the app 
> or in the widget.

That's why I suggested a launch agent instead of an app.

--Kyle Sluder___

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

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

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

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

Re: NSCursor - ignore previous (was incomplete)

[Graham Cox]

On 23/05/2011, at 3:26 AM, Adam Gerson wrote:

> I am not sure exactly where this code belongs or how to keep the
> cursor set this way. When I begin my animation I set the cursor, but
> it very quickly goes back to the "arrow". I believe this is happening
> when some of my views are getting redrawn with setNeedsDisplay which
> is part of what is happening in the background. Is there any way to
> get a custom cursor to stay set even if the view is redrawn and stay
> set until I manually set it back?


Setting the cursor should never be part of a view's drawing behaviour. If it 
is, then you will find managing it very difficult, if not impossible. If you've 
been doing that, you need to change it, but you can be sure that no views you 
didn't write are setting the cursor when drawing.

Cursors can be tricky, for sure. They are typically associated with an area of 
the screen - the cursor is set on entry to that area. This area might be a view 
or part of a view and the easiest and most reliable mechanism for getting 
notified when the cursor enters and leaves a given area is to use 
NSTrackingArea. 

--Graham

___

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

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

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

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

Re: NSCursor - ignore previous (was incomplete)

[Andy Lee]

On May 22, 2011, at 7:43 PM, Graham Cox wrote:
> Cursors can be tricky, for sure. They are typically associated with an area 
> of the screen - the cursor is set on entry to that area. This area might be a 
> view or part of a view and the easiest and most reliable mechanism for 
> getting notified when the cursor enters and leaves a given area is to use 
> NSTrackingArea.

Hi, Adam!

The docs are sparse and you may have read them already, but just in case:



I had to do some cursor management a while back and it wasn't too bad using 
NSTrackingArea but it still required some experimenting for some reason. It 
might be easier for you since your case sounds straightforward.

--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/archive%40mail-archive.com

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

Recursive search for files

[James Merkel]

I would like to add a capability to an application to search  
directories and sub-directories eventually opening all image files  
(basically using NSDirectoryEnumerator).
Obviously, I can't allow the user to start at say the volume level and  
do the search. However as far as I can tell, there is nothing in  
NSOpenPanel for example that prevents the user from starting there. I  
was trying to come up with a way to prevent the user from starting at  
the wrong place. (Putting up an Alert that says you can't start  
there). There's a method in the NSFileManager class called  
isDeletableFileAtPath. I am thinking that all of those volumes and  
higher level directories that I want to avoid are not deletable.  
Therefore I could use this as a filter. The only other approach might  
be to limit the search to a certain depth (maybe 10 or 20  
directories). However that seems kind of mickey-mouse. Should I be  
looking at the lower level File Manager Reference for some help here?


Has anyone come up with an approach for this?

Thanks,

Jim Merkel
___

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