Please Review - Revised OS X Application Bundle patch
mike.kronenberg at kronenberg.org
Sat Dec 5 13:43:34 CST 2009
On 04.12.2009, at 19:10, <Joerg-Cyril.Hoehle at t-systems.com> <Joerg-Cyril.Hoehle at t-systems.com> wrote:
>> The Application bundle provides a mostly 1 to 1 mapping for any *.lnk
>> that is generated and processed by Wine Menu Builder.
> What is this "Wine Menu Builder"?
> IMHO the Mac's ".app is one icon" does not match the typical
> installation on MS-Windows with 3-4 icons (the 3 above
> plus "About XY.url"). What do you plan to do about these
> 4 vs. 1 icons? How can the "Deinstall XY" bundle be
> related to the "Play XY" bundle?
> What I visually "see" is what existed in MS-Win3.x: Program
> manager windows that grouped together all the related icons.
> They still exist: just visit C:\users\me\startmenu\x\y\z with
> the file manager. These days you typically access the icons only
> via the "Start" menu.
> Kronenberg's distribution presents itself like win3.x: 3 icons
> in a window: one starts Wine, an other is the help file. But this
> window comes from a .dmg, while a .app presents one single icon.
Just have throw in me 2 cents here...
...I think we follow two totally different approaches.
Standard Wine is going the "ideal" path, where wine is just another abstraction layer like rosetta on OS X. It gracefully handles exes, installs files transparently to the OS X FS, mostly direct into the correct paths... we already have links into the home folder of the user, maybe there could be another one for the "Program Files" folder, so users find their stuff where they expect it.
In this way of thinking, having simple startup scripts to maybe fix the wineprefix is enough . In an ideal world, there is only one prefix. Using the resource fork for the custom file-image is the standard OS X way of applying icons to non bundle files. There are simple carbon or cocoa calls to do that.
But there is no ideal world, when it comes to run windows apps on an OS that shares about nothing with Windows, speaking in terms of architecture, security concerns and human user interface guidelines. It might be technically correct (in the eyes of windows) to have a gazillion icons on my desktop, after installing a windows app.
But this is not the OS X way. On OS X, the help has its help menu entry, the link to the program homepage goes probably into the about dialog and there is no uninstaller, as everything *should* be contained inside the app bundle. Further, the contents of the bundle should have probably the correct chmod settings and should work without admin privileges (the run wine as root thread comes to my mind). They should not be able to alter other applications. Further there is the "I can haz virus, too" thematics and the sand-boxing postings of Dan Kegel, which brings the direct linking of all native host directories into another light.
This all together just gives me the Heebie-jeebies on OS X. And this is why I go the "one prefix per app" way. I try to shoehorn everything into an as hermetic capsulated packages as possible :).
If I want windows behavior, I run Windows. But I just want one or two windows apps running on OS X, and they should behave like citizens of OS X.
But doing this for every OS Wine runs on, will just blow the boundaries of this project. This is why I suggest to continue the "ideal" path. The rest can be done by "platform natives" like it's done on loads of OSprojects.
This brings me to some other things I wanted to post about earlier. The more I try to isolate wine, the more lose endings I need to grab.
With the link to the host OS user folders, wine is spamming the host OS on all channels. Starting with little things like ~/Desktop/*.lnk. .thumbs and all other win system files will follow, I'm sure.
Then there are the other "hardcoded" wine folders
.wine (no problem with that)
~/Desktop/*.desktop (ok, I can disable this one with the menu hack)
But what about these:
Can I somehow disable them or move them inside the prefix? I know the concept of "share", but since I started with answering mails about how to completely remove wine the list of files and folders to search and clean is growing constantly.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3410 bytes
Desc: not available
More information about the wine-devel