OT: General behaviour of the community (from 'Why winetools is
utterly useless, once and for all')
speeddymon at gmail.com
Wed Mar 29 16:51:34 CST 2006
On 3/29/06, Chris Morgan <chmorgan at gmail.com> wrote:
> I'm pretty sure people are capable of filtering their own email.
> Afaict the offending emails were between two individuals. You may not
> like them but that has no bearing on whether they should be allowed to
> post to the mailing list given that those emails to the mailing list
> are appropriate.
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.
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.
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.
IOW a user who uses wine doors should have a directory structure like this
--all the uncompiled and unlinked files
--all the binaries and dll's, etc for a proper wine install (including
wineprefixcreate, the wine executable, etc)
--all the files outside of binaries
--all the binaries and dll's etc for a proper wine install (like wine-doors
instead of wine, and wineprefixcreate-doors, etc)
--all the files outside of binaries modified to work with different apps
Then a user can run ./wine-tools and it will present them a prompt saying
"Detecting app to be run... Internet Explorer"
"Merging changes to wine registry to allow running of internet explorer"
"Running Internet Explorer"
Then boom.. Up pops IE..
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...
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the wine-devel