http://bugs.winehq.org/show_bug.cgi?id=4146
winebugger@piments.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|CLOSED |UNCONFIRMED Resolution|DUPLICATE |
------- Additional Comments From winebugger@piments.com 2007-13-05 11:18 ------- 18 months on as WINE targets 1.0 none of these issues have been addressed it seems.
Probably largely due to the fact that this was closed and marked as a dupe of a mata bug which did not address one single point raised here. Sure it's meta bug, hardly a dupe then.
Most of Vitaliy's comments from #4 either misunderstand the above comments or bear no relation to the points raised.
This is all belongs in the manual. There were numerous discussions about this on wine-devel. Wine is not Windows and we do not do things in windows ways. It's ap to packagers to create any link on the desktop or menu. And Wine should not associate itself with *.exe files - again up to packagers.
Manual , what manual? That's my fundemental point here how does the new wine user find the doc? If he types wine -h he's asking for help.
No-one said wine is windows but wine's primary function is to provide a migration path so assume that users are more windows mentality than Linux hackers wanting the odd windows app. and help them bridge that gap.
My reference to links just meant some textual reference telling the user where to find the info he is clearly seeking (not desktop shortcuts). All my comments relate to the output of wine -h et al , nothing more.
I never mentioned associating wine to .exe, I regard that as a bad idea.
So, in resumé, could wine output something useful to the obviously lost user in response to these simple command lines? (And preferably without setting up / root/.wine in the process. -h and -v clearly do not call for a winecfg be it root or user).
Sure, Wine is not windows but you may need to explain that to the user in detail elsewhere, let's help him find "elsewhere".
-
Wine Bugs