On 04.12.2009, at 19:10, <joerg-cyril.hoe...@t-systems.com> <joerg-cyril.hoe...@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:
~/.local/share/applications
~/.local/share/desktop-directories
~/.local/share/icons
~/.lcoal/share/mime
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.
Mike
smime.p7s
Description: S/MIME cryptographic signature
