12 Jun
2001
12 Jun
'01
3:06 p.m.
The new Application DB (http://wine.codeweavers.com/appdb/) is starting to
fill up. But, we still need your help before we totally unleash it on the
Wine community. We need as much feedback, comments, and flames [:-)] as
possible this week. We need volunteers to take responsibility for updating
Apps in the DB. If you would like to help, email the appDB team at
appdb(a)codeweavers.com.
Areas we need help on:
- Add Apps and App Versions.
- Comments on Apps
- Application Owners
(the app db has a privilege system where you can be
owner of an app.)
- Screenshots (lots of 'em)
---
_ _WebGeek/NetAdmin CodeWeavers -= http://www.codeweavers.com
| \| |_____ __ ___ __ __ _ _ _ -= http://jnewman.codeweavers.com
| .` / -_) V V / ' \/ _` | ' \ -= mailto:[email protected]
|_|\_\___|\_/\_/|_|_|_\__,_|_||_| -= ICQ: 1842980 Yahoo: laxdragon
12 Jun
12 Jun
5:45 p.m.
On Tue, 12 Jun 2001, Jeremy Newman wrote:
The new Application DB
(http://wine.codeweavers.com/appdb/) is starting to
fill up. But, we still need your help before we totally unleash it on the
Wine community. We need as much feedback, comments,
A few bad links:
* http://www.winehq.com/support.shtml
'Application Database', fourth item in the Documentation column,
points to http://wine.codeweavers.com/fom-meta/cache/394.html
* http://www.winehq.com/dev.shtml
'Application Database', second item in the Wine Development list,
points to http://www.winehq.com/Apps/
Damn, now I'm lost, I can't find my way to the application database
anymore. I swear I found a link on the WineHQ site though...
Proposals:
* Currently the screenshot is in its own column. That's quite bad
sometimes: http://wine.codeweavers.com/appdb/appview.php?appId=42&versionId=22
I propose to remove this column and move the screenshot next to
'Description' with an 'align=right' on the table. It seems to work here:
<td class=color2 valign=top width='100%'>
<table width='100%' border=0><tr><td width='100%'
valign=top>
<!-- the screenshot starts here, I added align=right -->
<table align=right width="128" border=0 cellpadding=1 cellspacing=0 >
<tr><td align=center class=color3>
<small><font color=white><b> Screenshot </b></small>
</td></tr>
<tr><td class=color3>
<table width="100%" border=0 cellpadding=0
cellspacing=1"><tr><td
class=color2>
<a href='screenshots.php?appId=42&versionId=22'><img
src='./images/no_screenshot.gif' border=0 alt='No
Screenshot'></a></td></tr></table>
</td></tr></table>
<!-- End of the screenshot, Description will be on the same line -->
<b>Description</b><br>
[description originally by tegel at a site named dubaron.com]
<br>
<br>
I hope it works in all browsers...
http://wine.codeweavers.com/appdb/appimage.php?appId=27&versionId=0
* We should ban JPEGs for screenshots :-)
http://wine.codeweavers.com/appdb/appimage.php?appId=27&versionId=0
* It would be nice to see who owns a given application (but maybe
there's no owner yet).
and flames [:-)] as
No way. You're doing a great job.
--
Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/
Any sufficiently advanced Operating System is indistinguishable from Linux
6:01 p.m.
-----Original Message-----
From: Francois Gouget [mailto:[email protected]]
A few bad links:
* http://www.winehq.com/support.shtml
'Application Database', fourth item in the Documentation column,
points to http://wine.codeweavers.com/fom-meta/cache/394.html
Yeah, Andi put this one up as a holdover until we get the new AppDB up. Once
we feel it's ready (soon). We will update all the links on the site, and
Andi will update his FAQ to point to the new location.
Proposals:
* Currently the screenshot is in its own column. That's quite bad
sometimes:
I'll play with this some more. I'm assuming a web design that the average
user is going to be at 1024x768. Does anyone really use less than that
anymore? (save for web devices of course).
* We should ban JPEGs for screenshots :-)
http://wine.codeweavers.com/appdb/appimage.php?appId=27&versionId=0
Ewww, That is a bad shot, but not JPG's fault. It was converted from a GIF,
I'll get a better one.
* It would be nice to see who owns a given application
(but maybe
there's no owner yet).
That's a good idea. We'll add a App Contacts column, so we all know who to
ask for help on the app. Man, I hope that does not scare anyone off from
being an app owner though. :-)
and flames
[:-)] as
No way. You're doing a great job. 
6:09 p.m.
Proposals:
* Currently the screenshot is in its own column. That's quite bad
sometimes:
I'll play with this some more. I'm assuming a web design that the average
user is going to be at 1024x768. Does anyone really use less than that
anymore? (save for web devices of course).
6:12 p.m.
OK, you talked me into it. (Didn't take much, did it?). What I will do, is
move the Description text underneath the gray rows of app info. That's the
area that gets cut off at 800x600. Plus, that will give the URL's and names
more room to stretch.
the average
_ _WebGeek/NetAdmin CodeWeavers -= http://www.codeweavers.com
| \| |_____ __ ___ __ __ _ _ _ -= http://jnewman.codeweavers.com
| .` / -_) V V / ' \/ _` | ' \ -= mailto:[email protected]
|_|\_\___|\_/\_/|_|_|_\__,_|_||_| -= ICQ: 1842980 Yahoo: laxdragon
-----Original Message-----
From: James Hatheway [mailto:[email protected]]
Proposals:
* Currently the screenshot is in its own column. That's quite bad
sometimes:
I'll play with this some more. I'm assuming a web design that user is going to be at 1024x768. Does anyone
really use less than that
anymore? (save for web devices of course).
Yes, unfortunately... Many public places like libraries,etc. still
have terminals with 15 inch monitors at 800x600. 
26 Jun
26 Jun
9:22 a.m.
James Hatheway wrote:
Yes, unfortunately... Many public places like libraries,etc. still
have terminals with 15 inch monitors at 800x600.
agreed......alot of people are simply in a upper crust minority with screens
as large as 1024x768 and able to read that res without "squinting"
terribly......ie:at "least" a 19" monitor and those aren't cheap for
average
consumer...although Ihaven't checked prices recently my 21" hitachi is totally
adequate .......
I NEVER design without taking into consideration 15"/800X600......because the
outcome can be plain nasty.
signed
minority member <g>
Proposals:
* Currently the screenshot is in its own column. That's quite bad
sometimes:
I'll play with this some more. I'm assuming a web design that the average
user is going to be at 1024x768. Does anyone really use less than that
anymore? (save for web devices of course).
12 Jun
12 Jun
6:27 p.m.
On Tue, 12 Jun 2001, Jeremy Newman wrote:
[...]
Still, quite often I noticed that JPEG is not very good for
screenshots:
- screenshots often have large uniform surfaces, e.g. title bar, window
background... JPEG tends to render these with weird dithering-like
patterns.
- it tends to blur fonts. I believe that's because fonts are basically
thin lines, which means high frequency, which is exactly what JPEG's
lossy compression removes.
- if you ever write documentation that is going to be printed, you'll
notice that the printed version has very clear smudges all around the
text. These smudges are present on the screen too but they are
particularly visible when printed.
--
Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/
We are Pentium of Borg. You will be approximated. Division is futile.
* We should
ban JPEGs for screenshots :-)
http://wine.codeweavers.com/appdb/appimage.php?appId=27&versionId=0
Ewww, That is a bad shot, but not JPG's fault. It was converted from a GIF,
I'll get a better one. 
6:43 p.m.
Jeremy Newman wrote:
I'll play with this some more. I'm assuming a web design that the average
user is going to be at 1024x768. Does anyone really use less than that
anymore? (save for web devices of course).
This is one of my (many) pet peeves. Just because I have a high
resolution display doesn't mean that I'm going to devote the entire
screen to the web browser. IMO, web pages should be designed to work
without horizontal scrolling in a browser window 600-620 pixels wide
(unless there's a really good reason).
People using low-resolution displays will be able to use the page in a
maximized browser, and the rest of us will be able to actually benefit
from our technology investment.
--
========================================================================
Ian Pilcher ian.pilcher(a)home.com
========================================================================
13 Jun
13 Jun
9:04 a.m.
"Jeremy Newman" <jnewman(a)codeweavers.com> writes:
I'll play with this some more. I'm assuming a
web design that the average
user is going to be at 1024x768. Does anyone really use less than that
anymore? (save for web devices of course).
You can safely assume 600-700 pixels width. No more. I Sure don't run
my browser in 1600x1200 just because my desktop happens to run in that
resolution.
--
Peter Bortas http://peter.bortas.org
Roxen IS http://www.roxen.com
12:12 p.m.
You can safely assume 600-700 pixels width. No more. I Sure don't run
my browser in 1600x1200 just because my desktop happens to run in that
resolution.
Hmmm. You're imposing maximum resolutions without necessarily
considering the effects, and the overall design.
I believe that the design of the page
is such that if you browse with a more narrow browser than the
design calls for, the only information 'lost' is a screenshot.
This seems like a fairly decent design tradeoff to me.
(Of course, if the design doesn't work this way, maybe it
should, Jer <g>).
Jer
4:35 p.m.
OTOH - I always understood that hardcoding presentation elements into an
HTML document was eeviilll, that presentation was to be the province of
the displaying agent (browser).
-- Pat
Jeremy White wrote:
--
This message does not represent the policies or positions
of the Mayo Foundation or its subsidiaries.
Patrick Spinler email: Spinler.Patrick(a)Mayo.EDU
Mayo Foundation phone: 507/284-9485
You can safely assume 600-700 pixels width. No more. I Sure don't run
my browser in 1600x1200 just because my desktop happens to run in that
resolution.
Hmmm. You're imposing maximum resolutions without necessarily
considering the effects, and the overall design.
I believe that the design of the page
is such that if you browse with a more narrow browser than the
design calls for, the only information 'lost' is a screenshot.
This seems like a fairly decent design tradeoff to me.
(Of course, if the design doesn't work this way, maybe it
should, Jer <g>).
Jer
14 Jun
14 Jun
4:28 p.m.
New subject: Apps DB Round 3
Okay, with all of 3 days worth of data, we've already
figured out some problems with the current Apps DB.
The structure of the DB is that you have an
app, like MS Word. Now, when you're on MS Word,
you can see an app description, and people can post
comments.
Each App can (should?) have sub version records.
So, you can have a Word 2K and a Word 97 record. The Word
2K record can contain more info, more comments,
and we've also allowed the old 1-5 rating
for the specific app versions.
However, no one is really using the app versions.
A lot of people are submitting an App
(like Starcraft), and then just posting comments
against the main Starcraft app page, and ignoring
the version page.
For Starcraft, it seems like we should get rid
of the whole version stuff, because Starcraft
conceptually really only has one version.
However, for Word (and others), it seems
to me to be really important to maintain
the version distinction/info.
Jer and I have kicked around two possible
solutions, and I was hoping to see if anyone
else had any better ideas.
The first proposal was to modify the app's
main page so that it would always display
the version info of the most recent version
of the app. This would be a little tricky,
because we'd need to ask people to enter the
date of a particular version, but not too bad.
The other proposal was to modify the app's
main page so that you couldn't post any comments,
and we made it easy/obvious to get to the versions
page.
Thoughts? Better ideas?
Thanks,
Jer
3:32 p.m.
New subject: Apps DB Round 3
The structure of the DB is that you have an
app, like MS Word. Now, when you're on MS Word,
you can see an app description, and people can post
comments.
Each App can (should?) have sub version records.
So, you can have a Word 2K and a Word 97 record. The Word
2K record can contain more info, more comments,
and we've also allowed the old 1-5 rating
for the specific app versions.
However, no one is really using the app versions.
A lot of people are submitting an App
(like Starcraft), and then just posting comments
against the main Starcraft app page, and ignoring
the version page.
For Starcraft, it seems like we should get rid
of the whole version stuff, because Starcraft
conceptually really only has one version.
However, for Word (and others), it seems
to me to be really important to maintain
the version distinction/info.
Jer and I have kicked around two possible
solutions, and I was hoping to see if anyone
else had any better ideas.
The first proposal was to modify the app's
main page so that it would always display
the version info of the most recent version
of the app. This would be a little tricky,
because we'd need to ask people to enter the
date of a particular version, but not too bad.
The other proposal was to modify the app's
main page so that you couldn't post any comments,
and we made it easy/obvious to get to the versions
page.
Hmm.
I think there is a layer of indirection too much. The versions
should probably already be shown on the app page itself, it is
too confusing otherwise.
Or have the toplevel app page just display the ratings and have
a speific version edit/rate page, where the browsing user
can make changes.
Ciao, Marcus
8347
days inactive
8361
days old
12 comments
9 participants
participants (9)
-
Francois Gouget -
G.LeeJ -
Ian Pilcher -
James Hatheway -
Jeremy Newman -
Jeremy White -
Marcus Meissner -
Patrick Spinler -
Peter Bortas