On 3/20/07, Vitaliy Margolen wine-devel@kievinfo.com wrote:
Tom Spear wrote:
- Is the menu location (~/.local/share/applications) pretty much
universal? In other words IF a patch were submitted to add Start Menu
See: http://standards.freedesktop.org/menu-spec/menu-spec-1.0.html#paths
creation under windows\profiles, would it require detection of the menu location, or (in the case that it is nearly universal) could it just be statically coded?
You talking about two totally separate things:
- Windows' "Start Menu" location
- XOrg's location for the menu entries.
Vitaliy.
No I'm not. Apparently wine is broken in the way that it handles making links anyways, because if you look in winecfg with a clean ~/.wine you see Desktop points to ~/Desktop which is not good. The reason this is not good is because when a user installs a program they get 2 icons, one is the lnk file that is used in windows (useless in wine/linux for launching programs), and the other is the .desktop file.
You missed that discussion. It was decided some time ago that for compatibility reasons with 1000 different distros Wine will be using symlinks. And it works properly. But the biggest reasoning behind it is integration. Wine should use ~/Desktop as desktop (if it's present).
So we want users to have both a .lnk file (which doesnt work) and a .desktop file (which does) on their desktop?
Ill file bugs if that is not correct, but afaics everything in the menubuilder code looks fine. Like I said if I disable the Desktop/My docs linking in the desktop integration tab of winecfg, then wine acts properly and puts lnk files where they should be (under the fake c drive's start menu/desktop) and puts desktop files where they should be (under the real xorg desktop and menu), which is what I meant when I had said "central location", I just hadnt thought to disable the link to boxes until after I said that.