Real-world appdb

[Holly Bostick]

tony_lambregts at 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