motub at planet.nl
Fri Feb 11 14:10:06 CST 2005
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.
>> 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?
>> 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....
>> 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
> 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.
More information about the wine-devel