On 3/29/06, <b class="gmail_sendername">Chris Morgan</b> <<a href="mailto:chmorgan@gmail.com">chmorgan@gmail.com</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I'm pretty sure people are capable of filtering their own email.<br>Afaict the offending emails were between two individuals. You may not<br>like them but that has no bearing on whether they should be allowed to<br>post to the mailing list given that those emails to the mailing list
<br>are appropriate.<br><br>Chris</blockquote><div><br><br>Be that as it may, the person who made those comments made them as a direct attack on someone who posted to the list. Regardless of whether or not the insults were posted to the list, he shouldn't have made them. As the person who reported the incident said, had it been a new developer interested in helping wine (either directly by contributing code to the project, or indirectly by writing a support app), he probably would have said screw this, I'm not going to help out a project that has developers who verbally attack me. I know I would have.
<br><br>Sure we all have to deal with someone who is annoyed at a stupid comment or question every now and then, but those were not stupid (not in my opinion), and had some very valid points. If the "attacker" had done some research instead of spouting off because he was tired of users complaining about something not working and it turning out to be because of winetools, we wouldnt be having this convo.
<br><br>With all of that being said and trying to get back on topic, sure winetools breaks a lot of things, but from what I can see, it also gets a lot of things working. If we have better documentation and if (here is the key) the users took the time to read thru all of the docs, which I admittedly don't, there wouldnt be any need for winetools. Honestly, I think that winetools should have been (from the beginning) something that creates a second installation of wine, from source, and that plays with registry files outside of the main wine install.
<br><br>IOW a user who uses wine doors should have a directory structure like this<br><br>/<br>-wine-source<br>--all the uncompiled and unlinked files<br>-wine<br>--all the binaries and dll's, etc for a proper wine install (including wineprefixcreate, the wine executable, etc)
<br>-~/.wine<br>--all the files outside of binaries<br>-wine-doors<br>--all the binaries and dll's etc for a proper wine install (like wine-doors instead of wine, and wineprefixcreate-doors, etc)<br></div>-~/.wine-doors<br>
--all the files outside of binaries modified to work with different apps<br><br>Then a user can run ./wine-tools and it will present them a prompt saying<br><br>"Detecting app to be run... Internet Explorer"<br>
"Merging changes to wine registry to allow running of internet explorer"<br>"Changes Merged"<br>"Running Internet Explorer"<br><br>Then boom.. Up pops IE..<br><br>That is what winetools should have done. But since it doesn't, we are working on wine doors. A much more user friendly wine tool that will have more features. Of course, I'm not sure how it's going to look, and since I don't speak fluently in C, I won't be contributing, but hopefully it will be better than winetools without all of the problems of winetools...
<br><br>Tom,<br></div>