Le 19 juil. 09 à 17:03, Steven Edwards a écrit :
On Sun, Jul 19, 2009 at 8:10 AM, Emmanuel Maillardmahanuu@free.fr wrote:
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 ?
I didn't see which functionality to call to generate the plist's in C. Could you point me to the api's that are of use?
http://developer.apple.com/documentation/CoreFoundation/Conceptual/CFPropert...
- 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)
Very Nice! I must have overlooked this when I was exploring other problems like getting the xattr stuff right in the plists. I'll change my patch to reflect this for the first iteration. I still believe a future version is going to need some sort of helper application if we ever want to actually interact with a running instance for example, sending a quit message or cycling through active windows, etc.
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)
I see that but that implies a separate application to manage installed Wine programs like you state below, like WineHelper. This is going to be very hard to get in to stock Wine given our limitations on not using Cocoa
But it's an external appplication, your desktop environment, that handle *.desktop file; wine just generate them...
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.
Perhaps but I don't think so. Allow me to present things from the user perspective. I think writing to ~/Applications/Wine is OK and does not violate HIG as installing an application under Wine (to me at least) is analogous to running a mpkg that does not prompt where to install.
So don't choose ~/Applications but : /Applications/Wine or let's the user to choose if want an Applications folder in is Homedir.
The user clearly wants to install the application if it gets to the point of generating the shortcuts and bundling it up. Having some sort of helper application application that manages it own internal list of menus seems to imply multiple operations and steps that don't seem correct at least to me. Here is the work flow I see
Case 1. With WineApp Helper User opens HomeDirectory or Finder User goes to /Applications or ~/Applications and starts the Wine helper User then selects Winword from the list of known installed Applications Winword Starts
False with WineHelper : User opens HomeDirectory or Finder User goes to desired path and selects Winword.exe (.msi, .lnk) (Helper start if needed) Winwords start as intuitive as your Case 2 ...
or
Case 2. With wine app bundles User opens HomeDirectory or Finder User goes to /Applications or ~/Applications and selects Winword Bundle Winword Starts
The second case seems simpler and more intuitive. Now I could see a third case that would kind of give you the best of both worlds. Assuming your helper application was part of the Dock, you could have it act as a special launcher that expands like the way the Documents and Downloads menu's do and the user could select a given Windows application from there. Assuming that's the way it behaved we could have something like the following:
Case 3. User navigates to Dock and icon for Wine Applications (or whatever its called) List of Installed Windows Applications is expanded vertically User Selects Winword from the list Winword loads
WineHelper is Open Source so you can add any features you want, fork it, ask write access to Darwine CVS, send me patches (i must still have write access)
I'm not really opposed to such a design, I think its more friendly than browsing around in the Applications folders but this all implies having a helper app that we can get in to Winehq. I know I can't write it, I don't know anyone can do it and make Alexandre happy. It is imperative to me to make stock Winehq be functional for the end user and that includes make some way for the user to have easy access to the applications they install under Wine. Given that, I will refocus on sticking the bash script directly in the bundle for now (thanks again for the tip) as I don't think Alexandre will reject that and we can go from there. If someone wants to change it to something else later and can get it in to Winehq, by all means.
So please just use /Applications or ask the user if he want an a new directory in his Homedir.
-- 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
Emmanuel