Alex,  
 did you check the log files?
What do they say?  
 Mihalis.
http://widgetbook.blogspot.com/  
 On 02 Jul 2008, at 20:52 , Daniel Gobera wrote:  
 Hi Alex,  
If your widget's code is pure JavaScript I doubt this is an Intel vs  
PPC issue. Is there any other difference between the environments of  
both machines? If they're querying a remote server it could be that  
one of them has problems contacting the server. Anyway, it's hard to  
tell based on the information you provided. Can you be a bit more  
specific? Are you using Dashcode? If so, use the debugger and  
breakpoints to figure out at what point the paths diverge. 

 Daniel  
 On Jul 2, 2008, at 1:43 AM, Alex wrote:

[...]

The difference between Theory and Practice
is small in theory but big in practice! 

Just released a widget I've been working on for around two years.  :-)  
It has examples of common questions inside it like: 
• How do I activate and deactivate the dashboard. 
• How do I get my widget to communicate with a third party application  
using applescript. [...]

I had Tiger vs Leopard issues with my widget (meaning that I had Safari 2 vs Safari 3 issues). For me it was because of a changed behaviour in XMLHttpRequest. Safari 2 returned status code 200 (OK) for local files as well as remote, while Safari 3 doesn't return any status at all for local files. [...]

[...]

Dashboard in 10.4 uses the Safari 2 version of WebKit, even if Safari  
3 is installed. 

 Dashboard in 10.5 shares the WebKit used by Safari 3.  
That probably explains the differences — there were many bug fixes and  
improvements in Safari 3. [...]

Hi Alex,  
If your widget's code is pure JavaScript I doubt this is an Intel vs  
PPC issue. Is there any other difference between the environments of  
both machines? If they're querying a remote server it could be that  
one of them has problems contacting the server. [...]

I have no troubles running your widget on a G3 with OS X 10.4.11. I can't identify any platfor specific issues since you do not use widget plugins.  Anyway - I've got some suggestions for improved UE (user experience) and better reliability.     1. if you start to type "b" to get Berlin, then you will get almost all cities listed. That should not be.  An user should be able to use your widget intuitively and must not be forced to type a "-" at the end.  If I type a "b" I expect to get only results that start with "b" and nothing else.  You always have to keep in mind that you are only going to type at most three letters... there is not much you want to find else.  Usually when you type in one to three letters the last thing that you expect to find is the Name of the cities that do not match those on the plate.     2. you use unix commands like grep and head to get the results. I'd suggest to make the widget entirely based on _javascript_.     you can read files with _javascript_ using XMLHttpRequest()  http://developer.apple.com/internet/webcontent/xmlhttpreq.html     just get the responseText attribute. Then you can easily manipulate the String to build up an array with two entries  a) the one to three letters from the plate  b) the corresponding city     then it is easy to fulfill the first suggestion.     Hope this helps.     Michael           wenn das noch nicht hilft, dann schreibe einfach ;)         

Hello everybody.

I developed a little Widget to use in Germany only. In Germany each motor
vehicle has an unique Identifier at the license plate number of the car,
where the first 1 to 3 letters stands for the city, the owner lives in.

So i.e. "K-XX 123" stands for the city Cologne (in German: Köln) or
"WAF-XX 123" for the german city "Warendorf" a.s.o.

I implemented a JS search wich works very well, but only on Intel mashines
with OS 10.5 installed, the search returns a "no hits" message on a (i.e.)
G4 iMac with 10.4.x installed.

I have no Idea at all why this is so. Could anybody perhaps have a quick
look and point the issue?

The Widget ist listed here:
http://mac-widgets.de/modules.php?name=Downloads&d_op=viewdownloaddetails&lid=457&ttitle=KFZ

Direct download link:
http://tiger-widgets.de/modules.php?name=Downloads&d_op=getit&lid=457

In advance thanks a lot for your time!

Kind regards, 

Alex.

 

It may be worthwhile to submit a feature request asking that the  
Dashboard be applescriptable (at least for showing and hiding)... 

Shawn,

Thanks. I'll try that tomorrow.

There's already a kludge-load of applescript getting executed to run Terminal anyway so it will definitely be the frontmost app.

Later,

Andy
Roslin Institute is a company limited by guarantee, registered in Scotland (registered number SC157100) and a Scottish Charity (registered number SC023592). Our registered office is at Roslin, Midlothian, EH25 9PS. VAT registration number 847380013.

The information contained in this e-mail (including any attachments) is confidential and is intended for the use of the addressee only.   The opinions expressed within this e-mail (including any attachments) are the opinions of the sender and do not necessarily constitute those of Roslin Institute (Edinburgh) ("the Institute") unless specifically stated by a sender who is duly authorised to do so on behalf of the Institute.



This is what I use to exit the Dashboard.  To make sure the terminal  
is the frontmost app, you could execute some AppleScript before  
calling this function to bring Terminal to the front.

-Shawn

function dismissDashboard ()
{
	if (widget)
	{
		widget.openURL('');		// This will exit the Dashboard and do nothing  
else
	}
}


On Jul 1, 2008, at 11:34 AM, andy law (RI) wrote:

[...]

Perhaps you can try to call     widget.openApplication( "com.apple.Terminal" );     This usually hides Dashboard and launches the application.  Since Terminal is supposed to be running already I think there will be nothing visible but dashboard hides. [...]

This is what I use to exit the Dashboard.  To make sure the terminal  
is the frontmost app, you could execute some AppleScript before  
calling this function to bring Terminal to the front. 

 -Shawn  
function dismissDashboard () 
{ 
	if (widget) 
	{ 
		widget.openURL(''); [...]

That link is a bit paranoid.  It's also in an Apple Document.
http://docs.info.apple.com/article.html?artnum=303771  
My question is... does this only occur when you install a widget for  
the first time, or will it check for new versions? 

 Stephen Zinn
email@hidden  
 [...]

Thank you Claudio.  
 Doesn't the Dashboard communicate back to apple when it is launched?
http://www.red-sweater.com/blog/153/apple-phones-home-too  
 Stephen Zinn
email@hidden  

  On Jul 1, 2008, at 10:06 AM, Claudio Procida wrote:  
Stephen Zinn ha scritto:

[...] [...]

Stephen Zinn ha scritto:

[...]

AFAIK this functionality is not (yet) provided by Dashboard.  
 You could get inspiration from the mechanism I use in my WebSMS widget:

[...]

It consists in a class, VersionChecker, which is able to fetch the 
latest version number from a customizable URL, and a couple of custom 
Javascript additions to obtain the bundle identifier and compare version 
numbers(*). 

You just provide your own callback that will be called when the latest 
version has been detected. 


(*) widget.system is used synchronously, which is a deprecated practice. 
This will probably become unsupported by Apple, and will be changed in 
WebSMS in the near future. You have been warned. 

 Best regards,
Claudio Procida
http://www.emeraldion.it

Is there built in version checking for widgets?  
If I submit a widget to the apple widget list, and submit a new  
version, will a client computer check apple's list for new version? 

 Or is this something I need to do myself.  
 Thank you.  
 Stephen Zinn
email@hidden  
 [...]

All,

I'm mulling over the possibility of knocking up a widget to act as a
'Terminal Session controller' to store and activate a set of preferences
for terminal ssh sessions to other machines. Kind of like putty sessions
for those of you who've used that beast on windows. [...]

[...]

You didn't make that clear in your original post.    > quoted text
   I would assume you'd call this sort of thing in the onshow event handler to see if the computer had gone to sleep... However, if you need to know without the user showing dashboard, I'd guess you'd have to do a timeout (or interval)... this is why it's important to know what the need is.     If you just need to know if the computer has gone to sleep since the last time the widget was shown, an interval would be overkill for that...      

Errol, this was just an example of what _javascript_ commands can be used to achieve a sleep detection.    If you want to know what widget does such things.... Mine does!     I just wanted to point out that the interval time takes milliseconds as parameter. [...]

What are you hoping to do with this? Is there a need for your widget  
to update outside of the Dashboard environment? 

 On Jul 1, 2008, at 2:59 AM, Michael Kwasnicki wrote:

[...]

Calling a function of any sort every few milliseconds just to see if  
it was called "on-time" will waste CPU cycles... just the sort of  
thing that would get your widget deleted from my Mac, and would  
potentially frustrate the average user. 

 What if EVERY widget did this? [...]

I bypassed this by having an function that is called by  
 setinterval( bla, timeInMilliseconds)  
that funciton compares the current time against the last time it was  
called. 
If the difference is bigger than 30 seconds you can be very sure that  
the mac has fallen asleep. [...]