2008/12/18 Ben Klein <[email protected]>: > 2008/12/18 Sander Devrieze <[email protected]>: >> 2008/12/17 Scott Ritchie <[email protected]>: >> <snip> >>> If it's that users blame the distro when it's a Wine problem, then we >>> can present them with some sort of information before installing (or >>> perhaps running) Wine. After that we should get out of the way and let >>> them use Wine as normal. > > Is it a goal for Wine to be included as standard in distros? I'd say > not. The correct solution is *nix-native applications. E.g., how many > people use utorrent in Wine when they could use Deluge or > Transmission? Sure, Wine's goal should include support for apps like > utorrent (in that Wine's goal is to run as many Windows apps as > possible), but they shouldn't be prefered over *nix-native apps. > >> Wine should go out of way when the Windows application is known to run >> very well under Wine or when the user submitted feedback for this >> application in the past. Also, the user easily can skip the dialog. > > Known by whom? Are you suggesting appdb scraping?
No, I was thinking about including a list of hashes for the applications that are officially supported in the Wine distribution. >>> If the problem is that we're not getting enough feedback, then a default >>> feedback nag might not be the best answer either. >> >>> Writing an elaborate >>> system to tell us about known problems isn't particularly helpful; >> >> It shouldn't be an elaborate system: it can be as easy as asking the >> user to click on a button to send a list of API calls, used DLLs, a >> hash of the .exe binary, some critical information of his system, >> amongst others to the Wine project. User based input in the feedback >> form may or may not be a good thing; I just gave this as an example; >> it is no necessary element in what I am proposing. > > Sounds elaborate to me :) Though the winewatson sounds like it could > handle this sort of thing. > >> I guess this kind of feedback can be very powerful to Wine coders to >> create statistics like these: >> * Most popular API calls >> * Least popular API calls >> * Most common API calls that make applications fail >> * Unimplemented features used by very uncommon software (e.g. >> custom-built applications within companies) >> * Predicting the likelihood that a specific API call will be used when >> another API call is used in an application >> >> Maybe this information can be useful to detect which applications are >> affected by a bug in Wine. When this is known, testers can verify in >> multiple applications if the bug really is fixed in all applications. > > From what I've seen, most bugs in Wine aren't detectable by software - > it THINKS it's working fine, but the user can tell it's not :) In any > case, this would require a potentially large database of known bugs > and their symptoms ... I meant that this database can be used to see if a *manually* reported bug may also affect other applications. So, developers and testers can get a list of software that can be used to see if the bug is fixed. >>> reports from stable or nonlatest versions would be largely ignored, and >>> users of the latest beta can be asked to contribute in other ways, such >>> as on the download page itself. >>> >>> Remember, it doesn't take much work for us to know that an application >>> doesn't work - a single bug report can do that. Once we have that, we >>> don't need to ask a million other users (literally) for confirmation. >> >> Only geeks file good bug reports. Normal people don't care and will >> not spend energy on this. > > There's been a lot of talk recently about targeting Wine towards > end-users, e.g. the redesign of the website. It sounds like a great > idea, but Wine is still very much a developer's tool. It's not > user-friendly, and it won't be for a very long time, if ever. Most end-users primarily don't report bugs because they don't want to spend time on this. > winewatson sounds like a developer's debugging tool, but it could > prove useful for improving bad bug reports. > > Note that Microsoft has a system where any old application crash can > send a bug report to Microsoft. It's basically spamming yourself :) -- Mvg, Sander Devrieze.
