Le 18 juil. 09 à 04:06, Steven Edwards a écrit :
On Fri, Jul 17, 2009 at 9:13 PM, James McKenziejjmckenzie51@earthlink.net wrote:
Bundles are WAY more friendly than using the installer. Installer programs are meant to remain on the system.
+1
Also speaking of bundles I'm going to hijack the thread for a bit, I've got a rough patch going that enables winemenubuilder to be able to spit out bundles when shelllinks are installed. Its still very rough and needs to be redesigned a bit (and Alexandre is not totally sold on parts of the design) but at least its all C. Take a look at the attached patch and give me some feedback if your interested in helping.
Thanks
Steven Edwards
"There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo <update-bundler.diff>
Hi,
Just few remarks about your patch : - why you didn't use CoreFoundation API (plain C and already used in Wine) insteed of fprintf to generate Info.plist ? - you don't really need a Carbon launcher. Just a plain shell script in MacOS for executable et voila ... (sample joined, just edit MacOS/Notepad to set correct path)
IMHO In a more general way, it's not a good thing to touch user directory without letting him decide. For application generated file you should used ~/Library/Application Support/Wine (see : http://developer.apple.com/documentation/MacOSX/Conceptual/BPFileSystem/Arti... /apple_ref/doc/uid/20002282-BAJHCHJI)
And at last, an NSStatusItem seem's a better choice to me for a wine application starter, instead of fake app bundles. Just generated description plist (dictionnary with app name, full path, arguments, and icon path ... and what ever you want) in ~/ Library/Application Support/Wine/WineMenuBuilder and lets Helper application (your Bordeau's helper, WineHelper, or Mike Kronenberg one's) deal with theese files as they want.
Emmanuel