Le 18 juil. 09 à 04:06, Steven Edwards a écrit :
On Fri, Jul 17, 2009 at 9:13 PM, James McKenzie<jjmckenzie51(a)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