The user interface is what the user has to do to use the program. This is not supported in Wine. You will find links from winehq to several lists of things that run under Wine. When you attempt to use these lists you will find that many if not most of the programs do not run as is. The user outside the Wine world sees a totally false picture of Wine. He loads Wine and finds there are NO current instructions on how to use it so he presumes Wine to be worthless and goes away. Even if he persists there is still the problem of figuring out exactly how to make many if not most of the programs in the will run database work. The public simply won't put up with this. You can't have Wine so that a user must be a priest to load a special dll or to find out what special dll is necessary. Currently, there needs to be a short document written and KEPT up to date. To install and use Wine do ....... This document needs to point to somewhere where the user can get more help. There needs to be a WIKI where postings can be made specifically concerning what is necessary to make a program work on Wine. How do you currently make Office or Acrobat work on Wine? To my knowledge there are currently no large or complicated programs that you just load and run under Wine. You must set them all up first. It doesn't make any difference to the user if a program fails because of a sound driver. Waiting for all this to be fixed perfectly means a wait forever and serves no purpose without at least simple instructions on how to use Wine now.
gslink schreef:
The user interface is what the user has to do to use the program. This is not supported in Wine. You will find links from winehq to several lists of things that run under Wine. When you attempt to use these lists you will find that many if not most of the programs do not run as is. The user outside the Wine world sees a totally false picture of Wine. He loads Wine and finds there are NO current instructions on how to use it so he presumes Wine to be worthless and goes away. Even if he persists there is still the problem of figuring out exactly how to make many if not most of the programs in the will run database work. The public simply won't put up with this. You can't have Wine so that a user must be a priest to load a special dll or to find out what special dll is necessary. Currently, there needs to be a short document written and KEPT up to date. To install and use Wine do ....... This document needs to point to somewhere where the user can get more help. There needs to be a WIKI where postings can be made specifically concerning what is necessary to make a program work on Wine. How do you currently make Office or Acrobat work on Wine? To my knowledge there are currently no large or complicated programs that you just load and run under Wine. You must set them all up first. It doesn't make any difference to the user if a program fails because of a sound driver. Waiting for all this to be fixed perfectly means a wait forever and serves no purpose without at least simple instructions on how to use Wine now.
I'm sorry, gslink, but I cannot find any reasonable point of mediation or compromise in your position, as it does not completely make sense to me. On the one hand (the previous "Commercial Support" thread), you're against public requests for "support" (in the sense of "help" in various forms), because Wine is not "ready" in one or more senses. On the other hand, you admit that Wine needs "support", because it is not "ready", thus people can't use it. Am I the only one seeing the circular chain of reasoning here? All I can get (meaning, "guess wildly") from this (and our previous conversation) is that you feel that Wine(lib) must be made ready so that all these supposedly non-working applications can be ported so that they work transparently, because that's the only solution to this conundrum. Which would be very nice, I'm sure. However, my position is (as it has always in fact been), that concerns about the ease or difficulties of porting applications should be left to the next stage, not this stage (because Winelib isn't ready, for one thing)-- but that you (meaning, the project) are perfectly capable and ready to ask for support in solving problems like the one that you (gslink) have listed above, so that it *is* solved, and you (the developers) can devote your attention *to* making Winelib or whatever "ready", in whatever form you feel that "readiness" should take. I do not believe that every application must work 'transparently' out of the box *today*, as long as there is adequate documentation on how to get it to work readily available to the user.
Currently, there needs to be a short document written and KEPT up to date. To install and use Wine do ....... This document needs to point to somewhere where the user can get more help. There needs to be a WIKI where postings can be made specifically concerning what is necessary to make a program work on Wine.
I, personally, am perfectly capable of creating such a document. Probably right now-- literally, this very minute. As it happens, I just started (yesterday) documenting a huge comparison list of what I've got working under Wine vs. under Cedega, and what I had to do (or why it doesn't work), which I plan to put up on a web page to help users. So a simple document of "how to get Wine working" is nothing by comparison. I am not the only one capable of such a document, I am sure. I can think of at least two other people who hang out on Wine-users who could likely produce such a document, either alone, or in concert with others (even though those users may have never thought of doing so, or think that they're too "inexperienced" to do so). Unfortunately, there is no publicized and easy-to-understand methodology in place for me or anyone else to submit such a document, and of course, the only reason that I know you need one is because I go out of my way to hang out on this list. If I didn't, I would be ignorant of both things-- your need, and how to satisfy it-- rather than just the one thing (how to satisfy it). The wiki will not survive-- OBviously--without user support. The appdb will not recover without user support. *But the users do not know that you need their help!* And in all this discussion of requesting support, the prevailing consensus is against asking them-- because you're not even thinking about them, even though the "commercial" supporters you are discussing are ultimately just users, too. Who the hell knows about the Wiki?? You, me (because I hang around here), and the few users who go to the website. But who goes to the website? "Nobody" (not really, obviously, but proportionate to the number of people using Wine, nobody). Why? Because the vast majority of users don't even know the website exists. Why should they? SuSE (my fallback installation) installed Wine in the initial install. Gentoo, Debian (and variants), Fedora et.al, all have some version of Wine in their repositories. So the user just installs it from there. Half the questions on wine-users come from users using an insanely old version of Wine, and they don't even know that it's insanely old. We have to send them to the site to get a current download-- and don't forget, these are users who've managed to find the ML somehow, but not the site or its "download" link. I don't even want to speculate on the number of users who never find the ML nor the site, nor the current download (which they're probably not even looking for since they have no way to know that Wine has a montly release schedule). There is no popup on firstrun that says: "and by the way, if you need more help, or want to help, head over to http://www.winehq.org !", there is no documentation included (now that it's been split off from the main package, and I don't know if it's included in the pre-packaged binaries available on the various repositories)-- and even if the documentation was included and gave a reference to the site, man pages are not the default first search point of this so-called "average (Windows) user", or are the provided docs HTML and would pop up in a Web browser if a link to them was automatically generated in the K-menu or GNOME menu when Wine was installed? And other than Google, where is the existence of the site, much less its critical nature, much less the existence of the Wiki or the appdb published in GREAT BIG RED LETTERS? If they don't even know about the site, how exactly is the "average user" supposed to find out that there was a Wiki? It's not like the news was published anywhere this "average user" might have seen it. Ooh, a side reference on /. . Yeah, that would cover it. What about distribution news pages? What about IceWalkers? What about Freshmeat? What about NewsForge, or "ApplicationWatch" (a currently-non-existing variant on Distrowatch that would track news about "important" applications not supported by high-profile websites of their own)? Why is the important Wine news not published where the Wine users are, and in places where potential Wine users are? Why is there no one creating and maintaining a relationship with Tom's Hardware, whose Migration to Linux article was a year ago? Or Rage 3D, targeted at ATI users, who would be very interested in knowing how Wine overcomes or works around ATI driver bugs (heaven knows, I would)? Or Linux Journal, whose article about Wine that I found in a Google search is from 1994? I found an interview with Alexandre published in Linux Gazette from 2000, and a LinuxWorld article published in 2003. Where is the current news? Where are the current reviews? Where are the detailed changelogs (even quarterly) that let a user know that things are changing and give them some idea of the project's current status in terms of improvements and regressions (for instance, I know that Deus Ex regressed a few months back, but there is no way for me to know if that was fixed without trying it, which I haven't had time for). This is why I had to get on my soapbox twice in one week, to tell two different people on two different, unrelated-to-Wine forums that my reference to Wine was to the WINE project, and not Cedega. Because people know about Cedega, if they know anything at all. The squeaky wheel gets the most grease, as they say. I mean, please. If the project consists only of the development team, the development team clearly cannot -- and in fact, should not-- be responsible for managing publicity and administrative issues. However, it seems obvious that managing these issues is becoming a critical concern if the project as a whole is going to progress to the "next level". So for $DEITY's sake, ask for help. Ask everybody. Loudly, everywhere, and at every opportunity. You've got a lot of friends-- you've earned them with all the hard work you've already done. Make new teams. The documentation team. The legal team. Liasons all over the place to coordinate one team with the other. Become a not for profit organization so you can accept money without legal issue (and tax breaks for the contributors). Start treating yourselves like people doing valuable work instead of like a bunch of guys diddling around in the garage, because you are better than that, and have been for some time. But who is going to take you seriously if you don't act like you mean business? I love you guys, but you gotta stop selling yourself short. Holly
Holly Bostick wrote:
gslink schreef:
The user interface is what the user has to do to use the program. This is not supported in Wine. You will find links from winehq to several lists of things that run under Wine. When you attempt to use these lists you will find that many if not most of the programs do not run as is. The user outside the Wine world sees a totally false picture of Wine. He loads Wine and finds there are NO current instructions on how to use it so he presumes Wine to be worthless and goes away. Even if he persists there is still the problem of figuring out exactly how to make many if not most of the programs in the will run database work. The public simply won't put up with this. You can't have Wine so that a user must be a priest to load a special dll or to find out what special dll is necessary. Currently, there needs to be a short document written and KEPT up to date. To install and use Wine do ....... This document needs to point to somewhere where the user can get more help. There needs to be a WIKI where postings can be made specifically concerning what is necessary to make a program work on Wine. How do you currently make Office or Acrobat work on Wine? To my knowledge there are currently no large or complicated programs that you just load and run under Wine. You must set them all up first. It doesn't make any difference to the user if a program fails because of a sound driver. Waiting for all this to be fixed perfectly means a wait forever and serves no purpose without at least simple instructions on how to use Wine now.
I'm sorry, gslink, but I cannot find any reasonable point of mediation or compromise in your position, as it does not completely make sense to me.
On the one hand (the previous "Commercial Support" thread), you're against public requests for "support" (in the sense of "help" in various forms), because Wine is not "ready" in one or more senses.
On the other hand, you admit that Wine needs "support", because it is not "ready", thus people can't use it.
Am I the only one seeing the circular chain of reasoning here?
All I can get (meaning, "guess wildly") from this (and our previous conversation) is that you feel that Wine(lib) must be made ready so that all these supposedly non-working applications can be ported so that they work transparently, because that's the only solution to this conundrum.
Which would be very nice, I'm sure. However, my position is (as it has always in fact been), that concerns about the ease or difficulties of porting applications should be left to the next stage, not this stage (because Winelib isn't ready, for one thing)-- but that you (meaning, the project) are perfectly capable and ready to ask for support in solving problems like the one that you (gslink) have listed above, so that it *is* solved, and you (the developers) can devote your attention *to* making Winelib or whatever "ready", in whatever form you feel that "readiness" should take. I do not believe that every application must work 'transparently' out of the box *today*, as long as there is adequate documentation on how to get it to work readily available to the user.
Currently, there needs to be a short document written and KEPT up to date. To install and use Wine do ....... This document needs to point to somewhere where the user can get more help. There needs to be a WIKI where postings can be made specifically concerning what is necessary to make a program work on Wine.
I, personally, am perfectly capable of creating such a document. Probably right now-- literally, this very minute. As it happens, I just started (yesterday) documenting a huge comparison list of what I've got working under Wine vs. under Cedega, and what I had to do (or why it doesn't work), which I plan to put up on a web page to help users. So a simple document of "how to get Wine working" is nothing by comparison. I am not the only one capable of such a document, I am sure. I can think of at least two other people who hang out on Wine-users who could likely produce such a document, either alone, or in concert with others (even though those users may have never thought of doing so, or think that they're too "inexperienced" to do so). Unfortunately, there is no publicized and easy-to-understand methodology in place for me or anyone else to submit such a document, and of course, the only reason that I know you need one is because I go out of my way to hang out on this list. If I didn't, I would be ignorant of both things-- your need, and how to satisfy it-- rather than just the one thing (how to satisfy it).
The wiki will not survive-- OBviously--without user support. The appdb will not recover without user support.
*But the users do not know that you need their help!* And in all this discussion of requesting support, the prevailing consensus is against asking them-- because you're not even thinking about them, even though the "commercial" supporters you are discussing are ultimately just users, too.
Who the hell knows about the Wiki?? You, me (because I hang around here), and the few users who go to the website. But who goes to the website? "Nobody" (not really, obviously, but proportionate to the number of people using Wine, nobody).
Why? Because the vast majority of users don't even know the website exists. Why should they? SuSE (my fallback installation) installed Wine in the initial install. Gentoo, Debian (and variants), Fedora et.al, all have some version of Wine in their repositories. So the user just installs it from there. Half the questions on wine-users come from users using an insanely old version of Wine, and they don't even know that it's insanely old. We have to send them to the site to get a current download-- and don't forget, these are users who've managed to find the ML somehow, but not the site or its "download" link. I don't even want to speculate on the number of users who never find the ML nor the site, nor the current download (which they're probably not even looking for since they have no way to know that Wine has a montly release schedule).
There is no popup on firstrun that says: "and by the way, if you need more help, or want to help, head over to http://www.winehq.org !", there is no documentation included (now that it's been split off from the main package, and I don't know if it's included in the pre-packaged binaries available on the various repositories)-- and even if the documentation was included and gave a reference to the site, man pages are not the default first search point of this so-called "average (Windows) user", or are the provided docs HTML and would pop up in a Web browser if a link to them was automatically generated in the K-menu or GNOME menu when Wine was installed?
And other than Google, where is the existence of the site, much less its critical nature, much less the existence of the Wiki or the appdb published in GREAT BIG RED LETTERS?
If they don't even know about the site, how exactly is the "average user" supposed to find out that there was a Wiki? It's not like the news was published anywhere this "average user" might have seen it. Ooh, a side reference on /. . Yeah, that would cover it.
What about distribution news pages? What about IceWalkers? What about Freshmeat? What about NewsForge, or "ApplicationWatch" (a currently-non-existing variant on Distrowatch that would track news about "important" applications not supported by high-profile websites of their own)?
Why is the important Wine news not published where the Wine users are, and in places where potential Wine users are? Why is there no one creating and maintaining a relationship with Tom's Hardware, whose Migration to Linux article was a year ago? Or Rage 3D, targeted at ATI users, who would be very interested in knowing how Wine overcomes or works around ATI driver bugs (heaven knows, I would)? Or Linux Journal, whose article about Wine that I found in a Google search is from 1994? I found an interview with Alexandre published in Linux Gazette from 2000, and a LinuxWorld article published in 2003.
Where is the current news? Where are the current reviews? Where are the detailed changelogs (even quarterly) that let a user know that things are changing and give them some idea of the project's current status in terms of improvements and regressions (for instance, I know that Deus Ex regressed a few months back, but there is no way for me to know if that was fixed without trying it, which I haven't had time for).
This is why I had to get on my soapbox twice in one week, to tell two different people on two different, unrelated-to-Wine forums that my reference to Wine was to the WINE project, and not Cedega. Because people know about Cedega, if they know anything at all. The squeaky wheel gets the most grease, as they say.
I mean, please. If the project consists only of the development team, the development team clearly cannot -- and in fact, should not-- be responsible for managing publicity and administrative issues.
However, it seems obvious that managing these issues is becoming a critical concern if the project as a whole is going to progress to the "next level".
So for $DEITY's sake, ask for help. Ask everybody. Loudly, everywhere, and at every opportunity. You've got a lot of friends-- you've earned them with all the hard work you've already done. Make new teams. The documentation team. The legal team. Liasons all over the place to coordinate one team with the other. Become a not for profit organization so you can accept money without legal issue (and tax breaks for the contributors). Start treating yourselves like people doing valuable work instead of like a bunch of guys diddling around in the garage, because you are better than that, and have been for some time.
But who is going to take you seriously if you don't act like you mean business?
I love you guys, but you gotta stop selling yourself short.
Holly
You say it better than I! This is exactly the point of what I am trying to get across. I am tired of having to step people through installing Wine on the user forum because nobody ever said anywhere to install the latest rpm and then run something.
On Mon, 16 May 2005 09:43:44 -0400, gslink wrote:
The user outside the Wine world sees a totally false picture of Wine. He loads Wine and finds there are NO current instructions on how to use it so he presumes Wine to be worthless and goes away.
The basic idea is you don't need any instructions. We currently associate EXE files with Wine, so you can just click on the EXE file. Problem is, there's no icon for them! It looks like any old unrecognised file. Unintuitive as hell, that's for sure. We need to get Jimmac or somebody else to draw us some nice win32 file icons and get them merged into the default icon themes (or our CVS). This is a *concrete* and *achievable* task, which would hugely improve the usability of WineHQ IMO. Hand-waving about what the developers should or should not do isn't that useful, but this is the sort of job anybody can do. So why not go do it? thanks -mike
participants (4)
-
gslink -
Holly Bostick -
Ivan Leo Puoti -
Mike Hearn