On Tuesday 20 December 2005 23:23, Vitaliy Margolen wrote:
Thus removing it from the official download page is a wise choice. I'm we will still get number of users on wine-users and #winehq with winetools related problems. But at least we will stop spread of "bad habits".
I did'nt use winetools for quite a while now, but it was a great tool to get a newbie up and running with wine back then. If it hurts us more than it helps today, then we should take some action. But could we perhaps get in contact with Joachim von Thadden before we remove the link? He has put a lot of effort in winetools and he's a great wine advocate (He wrote a multi page technical article on wine for c't magazine a few months ago, which is one of the big computer publications here in germany. This article was based on winetools, but also did a lot of advertising for CodeWeavers and Wine in general). In my opinion he deserves some respect from our part. We should give him a chance to fix the problems with winetools before we silently remove the link.
Bye,
On 12/21/05, Michael Jung mjung@iss.tu-darmstadt.de wrote:
I did'nt use winetools for quite a while now, but it was a great tool to get a newbie up and running with wine back then. If it hurts us more than it helps today, then we should take some action. But could we perhaps get in contact with Joachim von Thadden before we remove the link? He has put a lot of effort in winetools and he's a great wine advocate (He wrote a multi page technical article on wine for c't magazine a few months ago, which is one of the big computer publications here in germany. This article was based on winetools, but also did a lot of advertising for CodeWeavers and Wine in general). In my opinion he deserves some respect from our part. We should give him a chance to fix the problems with winetools before we silently remove the link.
I am in agreement with the above paragraph..
Cheers,
Tom
Bye,
Michael Jung mjung@iss.tu-darmstadt.de
Vitaliy Margolen schrieb:
I can't say how many people have come to #winehq with different problems that were related to winetools. From what I could see, not a single person who I talked to had winetools installed and had Wine programs working properly.
Well, it was just a few month ago when Joachim and me has reworked the winetools. It is no longer config file based, it is using the registry now. We have tested it on multiple Linux distributions and the newest release WineTools 0.9 III hasn't showed serious problems when walking through the menus as intended.
Joachim says that he has 30.000 downloads per month. That's a big number and if only one percent of the users has problems, then of course your hear of them.
And of course mostly users only report when they have problems. Can you refer these users to the Wine users mailing list? We need detailed feedback to fix remaining problems.
James, please don't see the value of winetools only from a developers view. Normal linux users don't want to test builtin dlls, they just want to get their windows apps working on linux. IMHO it's better for Wine if the users become an easy feeling of success instead of letting them fall from one pitball into another.
Thanks for the assistance of Tom and Michael.
Sven
On 12/21/05, Sven Paschukat Sven.Paschukat@t-online.de wrote:
James, please don't see the value of winetools only from a developers view. Normal linux users don't want to test builtin dlls, they just want to get their windows apps working on linux. IMHO it's better for Wine if the users become an easy feeling of success instead of letting them fall from one pitball into another.
I agree that Winetools has an intended audience and I think there's a place for an app like that. Heck, look at CodeWeavers and their cxsetup program.
Having said that, are there things that Winetools does that need to be moved into Wine? I'm not sure anyone has ever looked at that. Are there registry settings that belong in wine.inf? Any time a .EXE can't be run out of the box you have to question what Wine is doing wrong to prevent that.
-Brian
n 12/21/05, Sven Paschukat Sven.Paschukat@t-online.de wrote:
Joachim says that he has 30.000 downloads per month. That's a big number and if only one percent of the users has problems, then of course your hear of them.
That's the problem; a clear distinction between wine and winetools is required. The wine-devel and wine-users lists are for the wine project, and any problems users have with winetools, or because of winetools, should be reported on a winetools mailing list.
And of course mostly users only report when they have problems. Can you refer these users to the Wine users mailing list? We need detailed feedback to fix remaining problems.
James, please don't see the value of winetools only from a developers view. Normal linux users don't want to test builtin dlls, they just want to get their windows apps working on linux. IMHO it's better for Wine if the users become an easy feeling of success instead of letting them fall from one pitball into another.
Trust me, I don't. I think winetools is a great app, and I've used it on several occasions. I agree that most users want to easily use their windows apps using winetools, and I'm not of the opinion that they shouldn't use winetools.
Vitaliy's point is that wine is progressing rapidly towards a 1.0 stable release. Wine's COM implementation is being worked on heavily, along with msi (and uncountless other areas.) Wine is at the point where a user shouldn't need winetools to use many windows apps. For example, it's possible to install IE6 by only registering one native dll and using another native dll for the installer.
As much as I appreciate the work you, Joachim, and others have put into winetools, we're getting closer to the point in time when winetools needs to be phased out by a better, more functional wine. Part of this process is removing it from the official download page.
-- James Hawkins
On 12/21/05, James Hawkins truiken@gmail.com wrote:
As much as I appreciate the work you, Joachim, and others have put into winetools, we're getting closer to the point in time when winetools needs to be phased out by a better, more functional wine. Part of this process is removing it from the official download page.
Shouldn't Wine be fixed before it's removed? Isn't it kind of backwards to say we need to have Wine run everything out of the box and to accomplish this were going to remove a link to a user friendly tool that currently helps our users.
Then what? your going to have just as many, if not even more people on IRC asking for help who other wise wouldn't have had to do so.
Wine is easy for me, and I'm sure for yourself to use and configure but this is just not the case for a large number of people! Removing WineTools is the worst thing this project could do at this time, as its the *only* free GUI that makes a genuine attempt to help first time users.
Tom
-- James Hawkins
On 12/21/05, Tom Wickline twickline@gmail.com wrote:
Shouldn't Wine be fixed before it's removed? Isn't it kind of backwards to say we need to have Wine run everything out of the box and to accomplish this were going to remove a link to a user friendly tool that currently helps our users.
If users continue to use winetools, wine won't get the needed testing coverage that will really help boost the development process. Many bugs will go unnoticed, new features won't be tested, and we won't get the feedback to make wine better. That's the beauty of open source; users are encouraged to tell us every bug or missing feature, and we will do our best to address the issues. The more eyes on wine, the better.
Then what? your going to have just as many, if not even more people on IRC asking for help who other wise wouldn't have had to do so.
I would love to see that day. I have no problem with people asking for help with wine on wine-users or IRC. The problem is when people report problems that are winetool specific, as Vitaliy initially stated. That's one of the reasons why I advocate a winetools specific mailing list, so people using winetools can reach the people that work on winetools.
Wine is easy for me, and I'm sure for yourself to use and configure but this is just not the case for a large number of people!
Usability is another rapidly progressing area of wine. You are exactly right in that it is easy for us to use, so we can't see through the eyes of a new wine user. We need more people to try wine out and tell us exactly what are is too difficult or not intuitive to use. That way we can fix it and make it easier for potentially many more users. If that user had used winetools, we would never get the report, and the issue would still remain.
Removing WineTools is the worst thing this project could do at this time, as its the *only* free GUI that makes a genuine attempt to help first time users.
On the contrary, winecfg is a great tool aimed to ease the use of wine and is being actively developed. Keep in mind that we don't want to remove winetools, just phase out winetools by advancing wine itself, and avoid promoting it from winehq. This should be taken in no way as an insult to winetools developers or users. The winetools developers are very competent, and their work is appreciated. winetools will eventually no longer be needed (which is a good thing!), and this is one of the first steps towards that process and wine 1.0.
-- James Hawkins
On 12/21/05, James Hawkins truiken@gmail.com wrote:
winetools will
eventually no longer be needed (which is a good thing!), and this is one of the first steps towards that process and wine 1.0.
So you agree that is currently needed, I believe it should stay until 1.0
Tom
-- James Hawkins
On 12/21/05, Tom Wickline twickline@gmail.com wrote:
So you agree that is currently needed, I believe it should stay until 1.0
The link or the program? Whether the program itself is needed is up to the users of winetools, and they show that it's useful in the very least, which I agree. Whether winetools is useful or not is not in question though. As I and others have stated in previous emails, wine should not promote the use of winetools nor restrict its use. winetools should be a completely separate entity with a separate mailing list, bugzilla, etc, and the link should not be on wine's download page. For the reasons stated previously, this is in the best interest of the developers of wine, but more importantly the users of wine in the long run.
-- James Hawkins
On 12/21/05, James Hawkins truiken@gmail.com wrote:
On 12/21/05, Tom Wickline twickline@gmail.com wrote:
So you agree that is currently needed, I believe it should stay until 1.0
The link or the program? Whether the program itself is needed is up to the users of winetools, and they show that it's useful in the very least, which I agree. Whether winetools is useful or not is not in question though. As I and others have stated in previous emails, wine should not promote the use of winetools nor restrict its use. winetools should be a completely separate entity with a separate mailing list, bugzilla, etc, and the link should not be on wine's download page. For the reasons stated previously, this is in the best interest of the developers of wine, but more importantly the users of wine in the long run.
To sum my replies up, I hole heartily agree with you James it's just that we differ on when not if the link should be removed.
Winetools helps people run programs that they might not be able to and it helps them do that now. And that's what 99.9% of end users care about, can I run what I want to now? If the answer is no 99.8% of them will leave while .1% might stick around and wait on a fix.
Happy Holiday's
Tom
-- James Hawkins
On 12/21/05, Tom Wickline twickline@gmail.com wrote:
Happy Holiday's
Happy Holidays to you too :)
-- James Hawkins
Wednesday, December 21, 2005, 8:12:43 PM, Tom Wickline wrote:
Winetools helps people run programs that they might not be able to and it helps them do that now. And that's what 99.9% of end users care about, can I run what I want to now? If the answer is no 99.8% of them will leave while .1% might stick around and wait on a fix.
Could you please show me some one, or ask them speak up on #winehq. So for I have yet to talk to anyone there who had used winetools and had IE6 working (that's the main goal of this isn't it?).
Ok it looks like there is 1 person who did use winetools and they worked.
So, Tom, could you please specify the place where I can redirect all the people who having problems _with winetools_? To wine-users I presume? As it looks to me that's the place where all the advertisement going on about using winetools.
Also had an interesting case last night: person had problems with winetools. When I asked the version, he said it's 3.0.9. So, there is your problem. Some one packaged winetools and made this version number.
As far as winetools go. I see a really bad patterns there. 1. There is no clean way to install them for a local user to test. Winetools are invasive and change too many things and go into to many places. This is not the way to package software. 2. It can't use wine from the source tree (again for testing). 3. It's using redundant scripts to like findwine. For what purpose? 4. Those scripts override environment variables that wine and wine parts, depend on. Why? 5. It adds some extra needless overrides to the registry, like DLLOVERRIDES="*=native, builtin". Is there a reason for this? That _is exactly_ what we, developers, trying to avoid. 6. "Version"="win98" - that is wrong. Wine's default _is_ win2k.
Please, we do not need this "quality" "software" linked to from the main download page. We can have a link to it in user section of wiki. But NOT the main download page! These "tools" defeat the purpose of what we, developers, are trying to archive.
Happy Holiday's
Hi Vitaliy,
On Thursday 22 December 2005 18:32, Vitaliy Margolen wrote:
Also had an interesting case last night: person had problems with winetools. When I asked the version, he said it's 3.0.9. So, there is your problem. Some one packaged winetools and made this version number.
This seems to be the version we are distributing via our debian apt-repository. Have a look at http://wine.sourceforge.net/apt/binary/
As far as winetools go. I see a really bad patterns there.
- There is no clean way to install them for a local user to test. Winetools are invasive and change too many things and go into to many places. This is not the way to package software.
- It can't use wine from the source tree (again for testing).
- It's using redundant scripts to like findwine. For what purpose?
- Those scripts override environment variables that wine and wine parts, depend on. Why?
- It adds some extra needless overrides to the registry, like DLLOVERRIDES="*=native, builtin". Is there a reason for this? That _is exactly_ what we, developers, trying to avoid.
- "Version"="win98" - that is wrong. Wine's default _is_ win2k.
You should bring your concerns to Joachim von Thadden's or Sven Paschukat's attention. If they fix them, we can keep the link to winetools. If they prefer not to fix them, we can explain to them why we think this is a problem for wine's development progress and thus give a rational for removing the link.
Merry Christmas (or if you prefer, Happy Holidays ;)
Vitaliy Margolen wrote:
- It adds some extra needless overrides to the registry, like
DLLOVERRIDES="*=native, builtin". Is there a reason for this? That _is exactly_ what we, developers, trying to avoid.
Actually, this makes sense for apps that install executables that are coincidently named like programs that Wine has, e.g. calc.exe or user.exe.
On a slightly related note, in CrossOver we force a whole bunch of DLLs to be builtin, like ole32, oleaut32, rpcrt4 and msi. Maybe we should do the same for Wine?
Thursday, December 22, 2005, 12:04:52 PM, Robert Shearman wrote:
Vitaliy Margolen wrote:
- It adds some extra needless overrides to the registry, like
DLLOVERRIDES="*=native, builtin". Is there a reason for this? That _is exactly_ what we, developers, trying to avoid.
Actually, this makes sense for apps that install executables that are coincidently named like programs that Wine has, e.g. calc.exe or user.exe.
Then this is Wine's bug and has to be fixed as such. There is no reason to hide it. Not in Wine at least.
On a slightly related note, in CrossOver we force a whole bunch of DLLs to be builtin, like ole32, oleaut32, rpcrt4 and msi. Maybe we should do the same for Wine?
Well we could add them to the override list I guess. But I think it's the part of the same problem. We seems not doing it the same as windows does. We went from one extreme (using as much native dlls as possible) to another extreme (use builtins only).
Vitaliy
On 12/23/05, Vitaliy Margolen wine-devel@kievinfo.com wrote:
On a slightly related note, in CrossOver we force a whole bunch of DLLs to be builtin, like ole32, oleaut32, rpcrt4 and msi. Maybe we should do the same for Wine?
Well we could add them to the override list I guess. But I think it's the part of the same problem. We seems not doing it the same as windows does. We went from one extreme (using as much native dlls as possible) to another extreme (use builtins only).
Exactly!
And if you force ole32, oleaut32, rpcrt4, msi and im sure others to builtin a lot of programs that currently run in wine will stop working. I'm 100% sure you will get all the feed back you ever wanted. And i'm sure you will see a lot of cuss words included in that feed back!
The Wine Tools maintainers have agreed to look into the problems that you have brought to the surface, can we please drop this subject?
Pretty Please :-)
Merry Christmas, Feliz Navidad, frohe Weihnachten, Joyeux Noël, vrolijke Kerstmis
Tom
Vitaliy
Friday, December 23, 2005, 6:13:30 AM, Tom Wickline wrote:
The Wine Tools maintainers have agreed to look into the problems that you have brought to the surface, can we please drop this subject?
No. I'm still insisting on removing winetools from the download page. They are against the wine development goals, wine development practices, wine development and in most cases against the law.
Authors could fix winetools, but that hasn't happened yet, and didn't happen for so long time.
Vitaliy.
I'm going to have to side with Vitaliy on this one. I've helped dozens of users in #winehq that have had problems with wine due to winetools since we made the changes to remove the .config file. Apparently winetools has been upgraded to work with 0.9x versions of wine, this is great news although I don't think we want to promote winetools to users if the authors aren't going to help out in #winehq and provide better overall support.
Chris
On 12/23/05, Vitaliy Margolen wine-devel@kievinfo.com wrote:
Friday, December 23, 2005, 6:13:30 AM, Tom Wickline wrote:
The Wine Tools maintainers have agreed to look into the problems that you have brought to the surface, can we please drop this subject?
No. I'm still insisting on removing winetools from the download page. They are against the wine development goals, wine development practices, wine development and in most cases against the law.
Authors could fix winetools, but that hasn't happened yet, and didn't happen for so long time.
Vitaliy.
On Fri, 23 Dec 2005 17:33:05 +0100, Vitaliy Margolen wine-devel@kievinfo.com wrote:
I'm still insisting...........and in most cases against the law.
Everyone is responsible for thier own actions. Someone who makes a hammer is not responsible for a murder comitted with it.
How does wine ensure that everyone who uses M$ Orafice CoralDraw or PhotoShop has a valid licence?
Be a bit careful of the ingenuous arguements you use, they could backfire on you and the wine project as a whole.
And perhaps not taking it as personal challenge to your authority may help further the collective effort.
In your post about the download page you refer 3 times in one sentence to "wine development" and not once to "user".
That is the crux of this discussion . Is wine dev an end in itself , an intellectual challenge , or does one of the developement goals include the user?
You may not think so but maybe you should check with others before insisting too hard.
[sorry Tom , I cut your gmail from the to header but you'll probably a copy on the list ;) ]
Friday, December 23, 2005, 10:03:54 AM, wino@piments.com wrote:
On Fri, 23 Dec 2005 17:33:05 +0100, Vitaliy Margolen wine-devel@kievinfo.com wrote:
I'm still insisting...........and in most cases against the law.
Everyone is responsible for thier own actions. Someone who makes a hammer is not responsible for a murder comitted with it.
There were case in US when family of someone killed with such a tool sued manufacturer if said tool.
Be a bit careful of the ingenuous arguements you use, they could backfire on you and the wine project as a whole.
That's why we have to be _really careful_ what we "officially" recommend to users. Look at what happened to original Napster. Judge didn't care what their intentions were. But he did looked at what it was _meant_ to be used for. So pls don't start this BS about winetools are good, they help users but use them on your own risk agreeing that you comply with all licenses.
Authors of winetools know well and good that majority of it's users do not have valid win98 licence.
In your post about the download page you refer 3 times in one sentence to "wine development" and not once to "user".
Correct. Winetools is made by developer(s) and not users. If it's made by users, then it has no reason whatsoever to be listed on the same page with _developed_ programs.
That is the crux of this discussion . Is wine dev an end in itself , an intellectual challenge , or does one of the developement goals include the user?
No! It only includes _me_ as a developer, and other people who _asked_ "could it be done this way to make it better for me?". This _is_ open source. You don't like it - you don't use it or fix it for your liking. If you have user problems with using Wine, please, don't hesitate, and _list_ them here. User is too of abstract word, talk about yourself first. Or ask those "users" to tell us about _what_ do they need from wine.
You may not think so but maybe you should check with others before insisting too hard.
Last time I've checked this _is_ the place to discuss such a topic.
Vitaliy
On Fri, 23 Dec 2005 18:24:56 +0100, Vitaliy Margolen wine-devel@kievinfo.com wrote:
There were case in US when family of someone killed with such a tool sued manufacturer if said tool.
Yeah , and someone put thier poddle in the microwave and sued. Take that sort of judgement too seriously and you daren't step out of bed.
So pls don't start this BS about winetools are good, they help users but use them on your own risk agreeing that you comply with all licenses.
I dont ever recall saying winetools was good, but I think choice is.
Authors of winetools know well and good that majority of it's users do not have valid win98 licence.
Do they? How? Do wine devs "know that the majority" of thier users dont even have a licence for Office? Be careful you are not constructing a legal case to shut down wine!
I would have thought with the ammount of decommisioned win98 installations in the world anyone who even vaguely wanted a licence could get one for $2.
I have a couple on the shelf and I dont even have a win98 box. So I can legally use winetools or sidenet to install dcom98 or whatever.
Sticking to the technical critisisms of winetools would be wiser and fairer.
If you have user problems with using Wine, please, don't hesitate, and _list_ them here.
Well that's the biggest joke after the way you shot me down in flames last time you _misinterpreted_ one of my posts here as a "users cry for help".
Talk about bullshit . Maybe that's just your inflamatory style of writing.
User is too of abstract word, talk about yourself first.
Well I'm not talking about myself , I have enough experience to tackle a lot of the debugging needed. What I see around me in my personal contacts is a lot of real people , non-geek users (for want of a better term) who are at a complete loss without something like winetools/sidenet to get them running.
Last time I've checked this _is_ the place to discuss such a topic.
"No. I'm still insisting on removing winetools from the download page."
That's discussion? Maybe you just dont choose your words well and give the wrong impression.
Of course winetools is not _real_ quality software like the patches you write so has no right whatsoever to be seen anywhere near your work because it may get some undue reflected glory.
And anyone who has not written patches for wine is talking BS and doesn't count either.
I can see the userbase shrinking as I write.
I suppose everyone needs to feel important somewhere - some more than others.
Friday, December 23, 2005, 11:36:16 AM, wino@piments.com wrote:
I suppose everyone needs to feel important somewhere - some more than others.
Before we get personal, and start discussing who did what, please stop by on #winehq.
Then well'll talk.
On 12/23/05, Vitaliy Margolen wine-devel@kievinfo.com wrote:
Friday, December 23, 2005, 11:36:16 AM, wino@piments.com wrote:
I suppose everyone needs to feel important somewhere - some more than others.
Before we get personal, and start discussing who did what, please stop by on #winehq.
So it's NO?
Fine with me, let the flame war begin!
Were do you get that it's illegal ? WTF is this? You can install IE, DCOM, MDAC, etc etc.... in Wine even without Wine Tools so your saying Wine is illegal because it lets people install IE when they don't have a Windows licence.
And if you want to bitch and cry about helping people, there is a simple fix, don't help them. Ignore there post or just say im sorry I dont use WT ....
I believe we should have SPREAD FIREFOX LOGO'S on the front page! IE is Illegal and "Vitaliy" has pointed this out! So you flame about the removal of WT and I will flame about the inclusion of Spread FireFox!
This is going to get ugly fast.........
Then well'll talk.
Friday, December 23, 2005, 6:16:17 PM, Tom Wickline wrote:
On 12/23/05, Vitaliy Margolen wine-devel@kievinfo.com wrote:
Friday, December 23, 2005, 11:36:16 AM, wino@piments.com wrote:
I suppose everyone needs to feel important somewhere - some more than others.
Before we get personal, and start discussing who did what, please stop by on #winehq.
So it's NO?
Fine with me, let the flame war begin!
There will be no wars unless between you and someone else.
Here the way I look at this: both you (Tom Wickline) and (Unnamed wino_at_piments.com) DO NOT participate in any of the public venues created to help Wine users: #winehq IRC channel on freenode.net. wine-users@winehq.org mailing list.
So WHAT RIGHT do YOU have to speak for ANY of Wine users except yourself?
As such, you are just _a_ user of Wine that fails to listen. And there is no point to speak with you about something that you are not even a part of.
Vitaliy Margolen
On Sat, 24 Dec 2005 04:22:19 +0100, Vitaliy Margolen wine-devel@kievinfo.com wrote:
As such, you are just _a_ user of Wine that fails to listen. And there is
no point to speak with you about something that you are not even a part of.
well since once again you prefer to ignore or not even read most of what you chose to reply to I would agree there is little point in your replying (maybe you understand english as poorly as you express it) .
I suggest you ignore posts you feel not worthy of your time.
To avoid clutting the list with this kind of unproducive exchange I will avoid replying to any comments you make and I suggest you do likewise.
On 12/24/05, peter@piments.com peter@piments.com wrote:
On Sat, 24 Dec 2005 04:22:19 +0100, Vitaliy Margolen wine-devel@kievinfo.com wrote:
As such, you are just _a_ user of Wine that fails to listen. And there is
no point to speak with you about something that you are not even a part of.
well since once again you prefer to ignore or not even read most of what you chose to reply to I would agree there is little point in your replying (maybe you understand english as poorly as you express it) .
I suggest you ignore posts you feel not worthy of your time.
To avoid clutting the list with this kind of unproducive exchange I will avoid replying to any comments you make and I suggest you do likewise.
I agree with you Peter,
Vitaliy is hostile and refuses to read the comments given by other user's and people who have contributed to this project.
Wine Tools is in no illegal to use each app comes with a EULA and it is the responsibility of the end user to follow any EULA.
The maintainers of Wine Tools have posted in this thread that they will look into problems that Vitaliy has brought forward.
Vitaliy keeps ranting that they have had time to fix all known problems in Wine Tools.. This is a joke! in fact is worse than a joke, there a open source project and there contributors work for free and contribute when they can, this is how open source works!
Vitaliy says that me and Peter don't help new users so we have no say in the way they may be treated in the future. I don't know about Peter but Ive helped new users for the last four years! Ive went out of my way many times to help people find a way to get get a app or game to install or run! And for him to make such a remark only shows his knowledge of my time spent helping new users.. And I should point out Ive never complained about helping anyone I do it because its what I want to do.
I agree with the other posters here that removing the link to there site will do more harm than good. This will be my last post on this subject as well, as it's fruitless to try and convince someone hell bent on destruction to change there mind.
Tom
Vitaliy Margolen schrieb:
So, Tom, could you please specify the place where I can redirect all the people who having problems _with winetools_? To wine-users I presume? As it looks to me that's the place where all the advertisement going on about using winetools.
Why not to wine-users? Winetools is a tool from wine users to wine users, and so that list. As it looks to me it is not flooded by winetools questions. If it's getting the upper hand, we can discuss a separate mailing list, but I don't think this happens.
Also had an interesting case last night: person had problems with winetools. When I asked the version, he said it's 3.0.9. So, there is your problem. Some one packaged winetools and made this version number.
We renumbered winetools version from 2.xx to 0.9 to be near to the version number of wine. The "3" has technical reasons for making winetools updatable with debians apt-get. So 3.0.9 is winetools 0.9.
As far as winetools go. I see a really bad patterns there.
- There is no clean way to install them for a local user to test. Winetools are invasive and change too many things and go into to many places. This is not the way to package software.
It is installable for root like most rpms. It is installing its files to /usr/local/winetools/ and some links to /usr/local/bin. Similar is done by wine. Of course it is making changes to .wine and some places in the home dir when started, but that's necessary for its intention.
Furthermore there are install/uninstall script, both for the tar.gz and the rpm.
- It can't use wine from the source tree (again for testing).
It should. What were your problems?
- It's using redundant scripts to like findwine. For what purpose?
It makes some checks to avoid problems. It was not our goal to write perfect code like wine. So it is titled "3rd Party Tools".
- Those scripts override environment variables that wine and wine parts, depend on. Why?
Can you say more precisely what code fragment do you mean?
- It adds some extra needless overrides to the registry, like DLLOVERRIDES="*=native, builtin". Is there a reason for this? That _is exactly_ what we, developers, trying to avoid.
Using as much native dlls as possible makes chances best to install windows software, of course not user32.dll and such.
- "Version"="win98" - that is wrong. Wine's default _is_ win2k.
It is right for the goal of the winetools. Again, this is why it's titled "3rd Party Tools".
Please, we do not need this "quality" "software" linked to from the main download page.
Once a wise person said to me: "Software is good when it is used".
Sven
Thursday, December 22, 2005, 4:16:54 PM, Sven Paschukat wrote:
Vitaliy Margolen schrieb:
- It can't use wine from the source tree (again for testing).
It should. What were your problems?
I do not have Wine installed. All I have is wine symlink in my ~/bin dir. And winetools could not find wine nor winecfg. So when I ran wt it complained about that.
- It's using redundant scripts to like findwine. For what purpose?
It makes some checks to avoid problems. It was not our goal to write
Mm looking at those checks I would say 95% of them are invalid and/or not as flexible as wine itself is.
perfect code like wine. So it is titled "3rd Party Tools".
No one talks about "perfect code" here. We are talking about "entitlement" to be listed in the same line as Wine itself.
- Those scripts override environment variables that wine and wine parts, depend on. Why?
Can you say more precisely what code fragment do you mean?
findwine - 95% bogus. winetools - should be split into separate scripts for each installed app. Makes it cleaner and more flexible. All the scripts in scripts/ dir what are they for? Most seems to be 100% redundant to what "wine" or "wine prog.exe && wineserver -w" do.
- It adds some extra needless overrides to the registry, like DLLOVERRIDES="*=native, builtin". Is there a reason for this? That _is exactly_ what we, developers, trying to avoid.
Using as much native dlls as possible makes chances best to install windows software, of course not user32.dll and such.
No that's not the case at all. And this part specifically defeats the whole propose of developing new dlls. Why would anyone in their right mind start new dll, if you can use native? But the question is "can you?" Most people DO NOT own Windows 98 licence. That means that each such person should not even attempt to download or run winetools.
- "Version"="win98" - that is wrong. Wine's default _is_ win2k.
It is right for the goal of the winetools. Again, this is why it's titled "3rd Party Tools".
No, it's not. Some major changes have been made to low level code that makes Wine much more like with winNT then win9x. If you enforce win9x for each program - you creating potential problems. And again, most programs with do things differently on win9x then winNT. Like disabling some features. So that again means that we never getting feedback from users.
Vitaliy Margolen schrieb:
I do not have Wine installed. All I have is wine symlink in my ~/bin dir. And winetools could not find wine nor winecfg. So when I ran wt it complained about that.
That's a situation we don't have expected. I will try to make a fix.
Mm looking at those checks I would say 95% of them are invalid and/or not as flexible as wine itself is.
I will take a look.
findwine - 95% bogus. winetools - should be split into separate scripts for each installed app. Makes it cleaner and more flexible. All the scripts in scripts/ dir what are they for? Most seems to be 100% redundant to what "wine" or "wine prog.exe && wineserver -w" do.
Winetools code is manageable by us and the wine users out there creating patches. It's not needed to be splitten into 110 separate files.
One of the intention of the scripts dir is a simple possibility to start the installad apps. When you e.g. install the Internet Explorer, there comes different apps like IE, Outlook Express, Windows Media Player. Each of it bas an own script with the correct path and executable.
Using as much native dlls as possible makes chances best to install windows software, of course not user32.dll and such.
No that's not the case at all. And this part specifically defeats the whole propose of developing new dlls. Why would anyone in their right mind start new dll, if you can use native? But the question is "can you?" Most people DO NOT own Windows 98 licence. That means that each such person should not even attempt to download or run winetools.
Hm, there must be a way to become both - new users which don't have problems with there windows apps and also the wanted feedback from users using builtin dlls.
What if I create a new feature into winetools which allows the users itself to choice between stability and using as few natives as possible.
I believe winetools makes still sense without using native windows components. It allows easy download and installation of about 110 freely downloadable windows apps. The downloadable fonts are always nice. Furthermore some native windows components are currently not implemented in wine.
No, it's not. Some major changes have been made to low level code that makes Wine much more like with winNT then win9x. If you enforce win9x for each program - you creating potential problems. And again, most programs with do things differently on win9x then winNT. Like disabling some features. So that again means that we never getting feedback from users.
It is one of my future Todos to change the windows version from win98 to win2000. But until now it doesn't seem to make real problems. All of the
110 apps have been tested. Most of them are running good in win98,
the ones which doesn't have a special win2000 configuration.
Sven
On Fri, 23 Dec 2005 06:58:03 +0100, Vitaliy Margolen wine-devel@kievinfo.com wrote:
- "Version"="win98" - that is wrong. Wine's default _is_ win2k.
It is right for the goal of the winetools. Again, this is why it's titled "3rd Party Tools".
No, it's not. Some major changes have been made to low level code that makes Wine much more like with winNT then win9x. If you enforce win9x for each program - you creating potential problems. And again, most programs with do things differently on win9x then winNT. Like disabling some features. So that again means that we never getting feedback from users.
Maybe this highlights the fundemental issue here. There is a divergence between the needs of the developers to improve Wine and the needs of the users who want to use an albeit it imperfect tool to run windoze applications on Linux.
I just installed an linux system for a freind and included wine. The next day I got a call: she had no idea how to use it or where to go, so I started to explain.....
I quickly realised that it was too much and too complicated to explain.
May I suggest that anyone involved in the wine project gets an "ordinary user" to install and use wine. The dev must be gagged and bound for this test !!
This is what I do with my software. When a user installs the demo in my presence I tell him to pretend I'm not there and I watch. Sometimes I ask him to explain why he did/didnot do something. It's amazing how many things seem obvious to me but do not even exist in the world of the user.
A technically excellent tool that is unusable is useless.
If winetools and/or sidenet help many user to get going they are a valuable asset to Wine and Linux. Far from removing the winetools link I would prefer to see sidenet added.
If devs can demonstrate that win2k default now _works_ better that win98 for most apps, that would be grounds to suggest a change to winetools. For the app I use on wine I started with win2k and had to revert to 98.
If some things on winetools could be updated I'm sure suggestions will be welcome as long as not accompanied by veiled threats like "do this or we may decide we dont want the link". We all have the same goal but what is good for one is not good for all. Let's insure that different paths can coexist productively.
Linux desktop is taking off NOW. Wine will play whatever contribution it makes to the future of Linux now, not in 6mths a year or ten years when it hits 1.0
Stop tweeking the dlls , take a deep breath and look around. I think user access needs to be the number one dev objective at this time.
I hope all these comments and suggestions can be taken in a positive vein. I really want to see wine succeed.
Best regards to all involved. Peter.
James Hawkins wrote:
Usability is another rapidly progressing area of wine.
What usability? I've been reading the mailing list for a few months now, and the only extent of 'usability' discussions for wine has been over whether or not experienced linux geeks will be confused by options in winecfg. That's not usability. That just means it's easy for hardcore users to figure things out without having to look for docs. The work being done in winecfg is both good and necessary, but it's still a long ways away from wine being 'usable' to non-geeks. When all of the binary packages (heck, any) on winehq.org have .Desktop files so that winecfg is at least accessible without the use of a terminal, and you can launch a wine application that asks the user what windows app they would like to run or make shortcut to so they don't have to use terminal there either, /then/ maybe there can be some usability discussion.
And then maybe it would be appropriate to remove winetools.
On 12/22/05, Joseph Garvin k04jg02@kzoo.edu wrote:
What usability? I've been reading the mailing list for a few months now, and the only extent of 'usability' discussions for wine has been over whether or not experienced linux geeks will be confused by options in winecfg. That's not usability. That just means it's easy for hardcore users to figure things out without having to look for docs. The work being done in winecfg is both good and necessary, but it's still a long ways away from wine being 'usable' to non-geeks.
Wine is an open source project, and as such, the developers of wine encourage peer review. We value bug reports, comments, suggestions, and criticisms, whether good or bad, so that we can make wine a better application. Your comments infer that the developers aren't interested in making wine easier for the end user, or that we are too 'hardcore' to realize that wine may be hard to use. The latter is possible, but the former is completely untrue. We take usability reports very seriously, and increasing usability is a top priority. The only problem is that we don't get those types of reports as often as we should. One reason why we don't get these reports is because users have winetools to make wine easier. They don't run wine directly, configure wine with winecfg, and stumble over any usability issues. That is why this issue began in the first place.
Speaking specifically to you Joseph, I've checked through the wine-devel and wine-users mailing list archives for reports of usability issues from you, but this is the first one. The constructive thing to do would be to politely report your problems on the wine-devel list, or even file bug reports for them.
When all of the binary packages (heck, any) on winehq.org have .Desktop files so that winecfg is at least accessible without the use of a terminal,
On at least KDE and Gnome, alt-f2 will bring up a run dialog, type winecfg and press enter. Even if winecfg was only usable from the command line, that doesn't count against usability. If that were the case, many well-known command line applications would be considered to have poor usability.
and you can launch a wine application that asks the user what windows app they would like to run or make shortcut to so they don't have to use terminal there either, /then/ maybe there can be some usability discussion.
winefile
And then maybe it would be appropriate to remove winetools.
Please re-read the posts. No one is advocating removing winetools, only the link to the winetool's download from winehq.org.
-- James Hawkins
James Hawkins wrote:
encourage peer review. We value bug reports, comments, suggestions, and criticisms, whether good or bad, so that we can make wine a better application. Your comments infer that the developers aren't interested in making wine easier for the end user, or that we are too 'hardcore' to realize that wine may be hard to use. The latter is possible, but the former is completely untrue. We take usability reports very seriously, and increasing usability is a top priority.
I do think that often developers are so technical minded that things that seem obvious to them are definitely not obvious to the average user. I peek at the KDE usability mailing list sometimes, a project more obviously focused on usability, and they can be just as terrible about it :) I didn't mean to rag on the wine developers, it's just that up to this point I don't think usability is an area of wine that has had a lot of work done on it. I'm not saying you wouldn't respond to usability complaints, but I think it should be apparent that in its current state wine would suffer from a low usability score.
The only problem is that we don't get those types of reports as often as we should. One reason why we don't get these reports is because users have winetools to make wine easier. They don't run wine directly, configure wine with winecfg, and stumble over any usability issues. That is why this issue began in the first place.
This is true to some extent but I don't think wine is to the point yet where you could get meaningful usability reports from users. I think wine developers can quite easily on their own apply the "does the user have to open a terminal to use and configure wine" litmus test. To do usability testing you have to have an interface that the usability of can be tested. Wine has winecfg, but the average user can't even get to that interface to test it.
Speaking specifically to you Joseph, I've checked through the wine-devel and wine-users mailing list archives for reports of usability issues from you, but this is the first one. The constructive thing to do would be to politely report your problems on the wine-devel list, or even file bug reports for them.
Well I hadn't really thought a lot about wine usability until this came up on the list =) I think I will.
On at least KDE and Gnome, alt-f2 will bring up a run dialog, type
winecfg and press enter. Even if winecfg was only usable from the command line, that doesn't count against usability. If that were the case, many well-known command line applications would be considered to have poor usability.
Many command line applications /do/ suffer from poor usability. I would never expect the average user to make use of them. Each command has its own fairly arbitrary single letter shorthands for a variety of switches, with no consistency between command line apps. Even to have a command go recursively through a directory isn't consistent, sometimes it's -r other times -R. I don't consider the command line to be usable by the average user at all. Having to type "man command" and read through several pages of documentation before being able to perform simple actions doesn't qualify as intuitive. That said, the command line is very useful and powerful -- for power users.
and you can launch a wine application that asks the user what windows app they would like to run or make shortcut to so they don't have to use terminal there either, /then/ maybe there can be some usability discussion.
winefile
I don't think winefile does what I described.
And then maybe it would be appropriate to remove winetools.
Please re-read the posts. No one is advocating removing winetools, only the link to the winetool's download from winehq.org.
Err, that's what I meant. I was unclear, sorry.
Again, I don't mean to insult anyone. I think wine is progressing at a breakneck pace and that it's an awesome piece of software. But I think removing winetools, a utility that helps to compensate for a current lack of wine usability, maybe unwise until wine can adequately replace it. I would at least set this criteria:
-.Desktop files for winecfg in all binary packages
Because without that I don't think removing winetools will cause an increase in usability feedback.
On Thu, 22 Dec 2005 02:59:57 +0100, Tom Wickline twickline@gmail.com wrote:
On 12/21/05, James Hawkins truiken@gmail.com wrote:
As much as I appreciate the work you, Joachim, and others have put into winetools, we're getting closer to the point in time when winetools needs to be phased out by a better, more functional wine.
Getting closer, sure, but it's not for tommorow
Part of this process is removing it from the official download page.
Part of this process "will be" removing winetool link. "is" implies the present and we are not at this stage with wine yet.
Shouldn't Wine be fixed before it's removed? Isn't it kind of backwards to say we need to have Wine run everything out of the box and to accomplish this were going to remove a link to a user friendly tool that currently helps our users.
I agree, I think there has to be an easy start method with at least half a chance of getting things running.
Most new users , many probably new to linux as well will NOT even be aware of what an IRC channel is an probably never met a maiing list either.
It seems some of the ppl posting on this thread dont even realise that they are living on a different plane to those actually using wine.
If new users cant get some positive result quickly they will just conclude that wine is unusable, and from an average user point , they would be right.
If they can be hooked by getting somethings to work they _may just_ go a bit further with some things that dont. Hell , they may even read the doc if they can find it.
As for argueing that bugs wont get reported. I was not aware that there was a shortage of things to do in fixing Wine.
If Wine scares off new users by expecting everyone to be a software developer it will fail in it's primary role of helping users to migrate to Linux.
regards.
On Thu, 2005-12-22 at 09:43 +0100, wino@piments.com wrote:
On Thu, 22 Dec 2005 02:59:57 +0100, Tom Wickline twickline@gmail.com wrote:
On 12/21/05, James Hawkins truiken@gmail.com wrote:
As much as I appreciate the work you, Joachim, and others have put into winetools, we're getting closer to the point in time when winetools needs to be phased out by a better, more functional wine.
Getting closer, sure, but it's not for tommorow
As someone coming from a Windows (professionally at least, Linux at home) background I have to say that making it harder to install programs by dropping the link to winetools, given the known, current limitations of Wine, could completely undo all of the efforts of the last 10 years.
One thing to remember is that 'Windows users are stupid'. Of course, I don't mean that literally; rather, anyone considering a switch to Linux is going to want to see some hard proof that their Windows programs might work. If they just get a crash (or a 'go to irc at etc....') they will give up immediately. I have seen some very sensible comments suggesting that once Wine reaches 1.0 then THAT is the time to drop references to winetools.
Part of this process is removing it from the official download page.
Part of this process "will be" removing winetool link. "is" implies the present and we are not at this stage with wine yet.
Agreed
Shouldn't Wine be fixed before it's removed? Isn't it kind of backwards to say we need to have Wine run everything out of the box and to accomplish this were going to remove a link to a user friendly tool that currently helps our users.
I agree completely
I agree, I think there has to be an easy start method with at least half a chance of getting things running.
Most new users , many probably new to linux as well will NOT even be aware of what an IRC channel is an probably never met a maiing list either.
It seems some of the ppl posting on this thread dont even realise that they are living on a different plane to those actually using wine.
If new users cant get some positive result quickly they will just conclude that wine is unusable, and from an average user point , they would be right.
See above
If they can be hooked by getting somethings to work they _may just_ go a bit further with some things that dont. Hell , they may even read the doc if they can find it. As for argueing that bugs wont get reported. I was not aware that there was a shortage of things to do in fixing Wine. ing 'please look here
If Wine scares off new users by expecting everyone to be a software developer it will fail in it's primary role of helping users to migrate to Linux.
Could not agree more. Wine needs to 'get it right for the users ', even if that involves occasionally saying 'please look here; we like you and we want to keep you here'.
Fixing bugs is the devs job, not the end user's job, yes?
regards.
-
Brian Vincent -
Chris Morgan -
Dominic Wise -
James Hawkins -
Joseph Garvin -
Michael Jung -
peter＠piments.com -
Robert Shearman -
Sven Paschukat -
Tom Wickline -
Vitaliy Margolen -
wino＠piments.com