tony_lambregts@telusplanet.net wrote:
Holly Bostick wrote:
Leaving aside the fact that there is no real reason to even run WinZip under Wine (given that zip is provided by default with every distribution, so *.zip files are already handled, WinZip doesn't handle *.rar files or *.ace files, iirc, and in any case, both unrar and unace are available by selection under Linux as well, so that's no excuse either), I don't particularly care that everybody else finds that application their favorite. Furthermore, I'm either not at the appdb at all, or if I am, I am not looking for WinZip, *because it runs perfectly*! Thus the only information I'm getting is that it runs perfectly (which I already knew if I've tried to install and run it; how likely is it that I've come to the appdb to "shop" for base utilities like WinZip to see if they run before proceeding?), and that the proportion of the userbase that cares enough to register and vote loves it. Yeah, and? What "big picture" am I missing here?
Well the big picture is that the more apps that run "out of the box" the better Wine is. Apps that can be downloaded are available to anyone so if a regression occurs in one of these apps it is easier to debug than one that a developer does not have access to. It is even better for Wine if the program has source code available. So having entrys for and (hopfully) maintainers for programs like WinZip or Mozilla benifit Wine in a very real sense.
That explains why these particular programs should be listed in the appdb-- although they perhaps should be in a special location, 'for internal use' (not really that exact phrase, that's a sort of placeholder statement for what I mean), rather than displayed for users, as if users should be using them. This does not, however, explain WinZip taking up 1/6th of my screen with a big old "Gold List" entry and screenie when I enter the appdb via the front door.
Also for newcomers to linux knowing that programs that they are familiar with run eases the transition to what can be a very intimidating environment. If being able to run winzip instead of the native alternative makes someones life easier that IMHO is a good thing.
Yes, I get that; I run PSP under Wine, because I just can't deal with The Gimp and my graphics manipulation needs are not so great that it's worth it to me to learn The Gimp. But this is *WinZip* we're talking about here. It's much harder to explicitly run WinZip (even if it works perfectly) than it is to double-click the *.zip file in your file manager-- which would most likely be a Windows migrator's first action on such a file. Double-clicking the *.zip file will result in the file either opening directly in the file manager if Konqueror (KDE being most every distro's fave "newbie" default desktop), or Ark or file-roller (for we GNOME lovers) automatically opening the file, since *.zip is a default known association for these programs. I suppose it's possible, but I find it hard to believe, that your "average" user is going to completely assume that they cannot open a *.zip file without any type of attempt whatsoever to actually do so (in which case the file would already be open), then go to all the trouble of finding, downloading and installing both Wine (which they probably don't even know about, if they are that new) and WinZip, then running WinZip to open the file.
That's not only a lot of work, but it's not really the Windows User's Way-- Windows users tend to "just click" things (and then scream bloody murder if nothing happens, or evil things happen; the tendency to "just click"-- whether or not the user knows what will happen when they do so, or whether it makes logical sense for the individual to click the object-- is so prevalent that it formed the entire infection mechanism of the "I love you" virus, after all).
One last thing is that having programs that run on the front page is our way of blowing our own horn.
Well, all of it is blowing your own horn... which is fine, you should do more of it.
But, in this case, apps like WinZip or Mozilla, both of which specifically are more likely to be run in native versions by new users than via Wine-- WinZip we've already been through, and of course Moz is more than likely installed by default already-- are the applications being used to do it. Displaying them as your "star achievements" is much more of a wan 'blaat' than a resounding fanfare.
If you've accomplished getting a difficult, unique, and irreplaceable program running so well that it should be on the Gold list, by all means, make the notification big. I'll be the last to complain. Quicktime running under Wine is something that everybody wants/needs to know about for all kinds of reasons. IE installing/running under Wine is a big deal, even for those of us who don't use it as a browser. Even Grandma may well code up a simple web page and want to use IE to test the display and compatibility, and of course lots of unrelated programs require IE before they will install.
Placing applications such as those in a position of prominence not only gives users useful information and reassures them, but also reveals that you have done something *hard* to both the knowledgeable and the naive.
Placing WinZip there says... nothing much at all.
Welcome
This is the Wine Application Database. From here you get info on application compatibility with Wine. For developers, you can get information on the APIs used in an application.
Oooh, I can? Never noticed that.... sounds like it would be useful information even for a non-coding maintainer, since I would then have a better idea what debug channels I'd want to use in case of trouble. Must explore later.
I guess I never *really* read that. I think that what the appdb is today is not the original conception. From what I can decipher form other clues there was an idea that the appdb would contain all the windows calls that a program made. while this seems like good idea perhaps it was not a practical one.
I suspected as much. But it would be pretty doggone cool if it was the case or became the case.
The problem of collecting all the api's a program calls is do-able ( WINEDEBUG='all' ). However what do we do with that trace afterwords. Manually entering each call int the appdb is out of the question. I am certain that we could parse the file and somehow to get it into the database. However, how usefull would that data be for either the end user or the developer?
Naturally, developers have to answer for themselves, and for pure users it would be useless, but for those in-between (people learning to develop, or attempting to migrate their developement skills from Windows to Wine) it might be a useful reference, and it seems to me (in my ignorance) that correlating that information with Bugzilla might really cut down searching time as to where a bug is located-- if several programs which seem unrelated evidence the same or a similar bug to each other, and we look at this database and see that they all use the same or similar API for their different purposes, wouldn't that locate the general area of likely failure of the Wine code much faster than the way that it's done now?
[snip]
I mention this only because at least there I can find a (very tenuous) logical chain of incentive to vote. I don't see what motivation my voting gives to the Wine devs (who's going to "force" them to stop working on whatever they're interested in and work on Uru: Ages Beyond Myst?), and because of that, I don't see what is the incentive for me to vote, or in fact what is the purpose of this entire voting business. Is it possibly an implementation of an idea that was obsoleted by later changes in the project's direction? If not, it needs to be made much clearer what function it serves within the "project production line".
You are probably correct here. Certainly voting for an application version makes more sense to me. However voting for any app makes no "real" difference to the developers at this time.
The voting system is an indication of how popular (important?) a program is. I do think it really good at what it is supposed to do.
I'll take your word for that, but I guess what I'm asking is "How relevant is the question of how 'important' an application is (considered to be, considered to be by users, who-- no disrespect intended-- don't know squat about squat most of the time) to a) the goals of, b) the mechanism/standard operating procedure of, and/or c) the philosophy/mandate of the Wine project?"
If the question of how important an application is judged to be is not in fact relevant because 1) the mechanism by which Wine is developed does not lend itself to "focused development" (stop what you're doing and fix X); or because 2) the goal of the Wine project is to provide a fully-functioning implementation of the Windows API, not specifically to get X program working; or because 3) we aren't bloody TG, then why are we making such a big deal about collecting and publicizing this judgement?
If the question remains relevant, then why it is relevant should be much clearer, because I don't get it. Naturally, feel free to inform me if the reason I don't get it is that I'm just dim... but don't forget, if I'm dim, there's a million more out there like me.
I think that a system that indicates how popular a program is can be usefull. certainly you would like to have the database users be able to indicate that they would like a program to run. I would like to propose the following changes.
- Voting for app version ( not app family).
Makes sense and saves time, in case version 1 of an app works, but version 2 does not, the devs don't have to go hunting through the family to see which one needs fixing.
- only one vote per person per version.
Understandable, but still doesn't give me an option to increase the vote count on a low-rated app. Could we maybe have a time limit on this restriction, so that I could vote for the app (version) again in a month or three? That way you'd at least know that even though I might be the only one who wants this program running, I am at least dedicated enough to keep coming back to vote for it, month after month.... maybe somebody will take pity on me ;-) .
- more total votes, say 10-20 instead of 3.
Well, 20 might be too many, but 3 does seem to be too few. Although, if the voting is really going to affect the dev team's workload in a concrete way, you probably don't want to give the users *too* many votes....
[snip]
Yes, that's true. But now we're coming to another important issue: Publicity. Who really knows about the appdb (meaning in terms of Wine users)?
I think that we have a ways to go before we have a Grand (re)opening. There are stability problems and missing features that we need to address before we want to get slashdotted ;^). We are getting a steady increase in the number of comments and maintainers that so I think that the word is getting out anyways. I don't think that I want to make a big annoncement and have users going away dissapointed.
There are a couple of big features that need to be dealt with.
- Add monitoring system for users to monitor changes to an app without
becoming a maintainer.
I didn't even dare to dream of that. But $DEITY, would it be cool....!
- Revamp the integration with bugzilla so that a bug can belong to an
app version instead of the app family. Also it should be possible to link a bug to more than on app.
Wouldn't this require knowing what APIs each app uses (see previous)? How otherwise would the bugs be known to be linked (unless the connection was extremely obvious, such as a failure in Installshield, or Quicktime or whatever)?
By the way, if the parser you mentioned above was available, couldn't one of the first duties of a maintainer be to generate the WINEDEBUG='all' for their app and submit it to the database to be parsed?
- revamp the voting system.
... or give it a reason to be... ( :-) ).
- Make the documentation mor usefull.
Well, we all want that. But it can be done incrementally if necessary-- meaning, from what I can tell, most of the useful information is already available, but people can't find it. So while we're all beavering away at improving its readability and usefulness (which takes time), what can be done today is to make the path to even this less-perfectly useful information more accessible (which Jonathan has been making a start on by adjusting the links to it).
When more people can find the current information to read it, we will hopefully receive more reports on what they didn't understand, so that the documentation can be adjusted accordingly, more effectively, and more efficently. I mean, we already say that Wine is a work in progress; people shouldn't be freaked out on that account. Waiting until such time as the documentation is 'more useful' to encourage users to come by and use it is like cleaning up before the maid arrives. We're all in this together, and leaving the documents somewhat untidy gives less-technical users an opportunity to contribute that might be unavailable otherwise.
Holly