8 replies to this topic

[William T. McVay]

In response to the problem faced by users like me, whose AccUpdater widget has always failed to scan because of home folder location, I have some ideas. Thanks for the workaround solution to "AccUpdater dysfunction," which clued me in to the root cause. This is a little technical, so novice users might want to stop here.

I found that one cause of this problem can be that the user directory (home folder) specified in AccUpdater widget 2.1.3 is hard-coded as a full path based on the Apple default location, /Users. However, some users' home folders are not in /Users. Using other drives, partitions, and servers to house home folders is becoming more common, so I expect this topic is timely.

My first idea was to hack the AccUpdater.js file to make it use the correct modulePath and pathPath values for the current user. For example, if the home folder is located in a Users folder on the "data" volume, change the string "/Users" to "/Volumes/data/Users" when setting those two variables in the widget's JavaScript code. This is a case-by-case hack that uses the same hard-coding technique originally used in developing the widget. Not ideal, but it solved the problem at the root cause, giving proof-of-concept for a better idea. (Putting an alias named /Users on the boot partition when a real /Users is still used cannot be done because of filename conflicts.)

A better idea is to have the widget discover the path to the appropriate user directory. A widget plug-in that uses Objective-C to access the NSHomeDirectoryForUser function would solve the problem elegantly by explicitly asking Mac OS X to provide the home folder path for the named user. This is in accordance (ha!) with Apple's longtime practice of having programmers abstract as much information as possible so the resulting code "just works." I guess this is a feature request.

[Joe Weaks]

Most folks who have moved their User folder have put in a symbolic link that fixes this problem, no?
Javascript can make an apple event call to get the home folder, as well. That'd be simple enough.

[Joel Brown]

I do agree that any sort of hard coding isn't pleasant to have do deal with on the user end - it works great for some people, but is quite inflexible. The reason such things exist are the poor development environment in which widgets are placed (it wasn't made nearly as stable nor robust as Obj-C in XCode). Anyway, excuses aside, this discussion has given me some ideas as to a way to implement home folder identification. Writing an Obj-C plugin is sorta out of the question right now, due to my fairly limited Obj-C experience. Also, I don't believe javascript widgets can make direct Apple event calls, but I'm quite certain I can get some process that should work just fine. I'll get to work on these fairly soon and hopefully release (along with other improvements). Also, as Joe mentioned, using a symbolic link should work just fine, even if Aliases don't.

[Joe Weaks]

...The reason such things exist are the poor development environment in which widgets are placed ... ideas as to a way to implement home folder identification ... javascript widgets can make direct Apple event calls

I would reiterate what Joel said about Widgets... theirs is kind of a half-baked development environment.
I do think running applescripts isn't hard to implement though. Is it hard to get a variable returned from a script? Maybe you need to wrap the applescript code in a shell script in order to have the variable passed. You can do that with a shell script in your package. Something like:

#!/bin/sh
osascript<<END
get path to home folder as string
-- may need Posix path
END

Save it as getHomePath and call it with something like

function getHomePath() {
widget.system("scripts/getHomePath", null);
}

Edited by Joe Weaks, 28 April 2007 - 05:40 PM.

[Joel Brown]

I would reiterate what Joel said about Widgets... theirs is kind of a half-baked development environment.
I do think running applescripts isn't hard to implement though. Is it hard to get a variable returned from a script? Maybe you need to wrap the applescript code in a shell script in order to have the variable passed. You can do that with a shell script in your package. Something like:

#!/bin/sh
osascript<<END
get path to home folder as string
-- may need Posix path
END

Save it as getHomePath and call it with something like

function getHomePath() {
widget.system("scripts/getHomePath", null);
}

Such a thing wouldn't be necessary in the slightest. The initial problem was that running existing scripts already required preknowledge of where the widget was located. In your example, it wouldn't know where the scripts folder is located. widget.system calls always start at the root directory. However, osascript can easily process a script directly from within the shell call itself, compiling the script in real-time. Thats what I'd implement.

[Joe Weaks]

Such a thing wouldn't be necessary in the slightest. The initial problem was that running existing scripts already required preknowledge of where the widget was located. In your example, it wouldn't know where the scripts folder is located. widget.system calls always start at the root directory. However, osascript can easily process a script directly from within the shell call itself, compiling the script in real-time. Thats what I'd implement.

I'm not following you, Joel. In something like:
widget.system("/usr/bin/osascript getPath.scpt", null);
it would look for the "getPath.scpt" file inside the widget bundle.

Anyhow, since we're only talking a simple one-liner, it's not too cumbersome to put the script into the command itself:

var output = widget.system("/usr/bin/osascript -e \"POSIX path of (get path to home folder)\"", null).outputString;

Then you have the location from StdOut saved in the variable output for you to work with.

That should be easy enough. Have fun with it.

Edited by Joe Weaks, 29 April 2007 - 02:50 PM.

[Joe Weaks]

If you were a glutton for punishment and wanted to use a Cocoa instance of NSAppleScript, I think it would be something like:

NSAppleScript *getPathScript = [[NSAppleScript alloc] initWithSource: @"POSIX path of(get path to home folder)"];
returnPath = [getPathScript executeAndReturnError: &errorDict];
[getPathScript release];

But, I agree, no point in going down this route.

[William T. McVay]

Most folks who have moved their User folder have put in a symbolic link that fixes this problem, no?
Javascript can make an apple event call to get the home folder, as well. That'd be simple enough.

I agree that you can put a symbolic link in the /Users folder to reach /Volumes/{other volume}/Users/{home folder}. That would leave open the existence of some home folders in /Users itself. Thanks. That is a good workaround as long as the widget does not discover home folders on its own.

[William T. McVay]

... Writing an Obj-C plugin is sorta out of the question right now, due to my fairly limited Obj-C experience. ...

Thanks for looking at the problem, Joel. I understand your reluctance to dig in without more Obj-C background. Since it strikes me as a generally useful plugin, I will look at writing one. If I get to it, I will let you know about it and the Javascript hooks for using it.

BTW, the modified widget is updating my Accordance modules pretty well. It likes to run with a very short list of selections, and it sometimes fails, but it sure beats manually searching the website every time! Thank you for providing a useful facility.