Le 19 juil. 09 à 17:03, Steven Edwards a écrit :
On Sun, Jul 19, 2009 at 8:10 AM, Emmanuel Maillard<maha...@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/CFPropertyLists/CFPropertyLists.html
- 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/Articles/LibraryDirectory.html#/
/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
