Le vendredi 04 février 2005 à 08:25 -0700, tony_lambregts@telusplanet.net a écrit :
WineHQ wrote:
ChangeSet ID: 15925 CVSROOT: /opt/cvs-commit Module name: appdb Changes by: wineowner@wine.codeweavers.com 2005/02/03 20:55:50
Modified files: . : appview.php screenshots.php admin : adminAppDataQueue.php editAppFamily.php editAppVersion.php include : screenshot.php user.php tables : appdb_tables.sql
Log message: Jonathan Ernst Jonathan@ernstfamily.ch
- no more appId in appData as appVersion implies an appId*
- screenshot class has been reworked to remove need of appId
- screenshot class has been improved to send e-mails so that email handling can be removed from other scripts
Patch: http://cvs.winehq.org/patch.py?id=15925
Old revision New revision Changes Path 1.47 1.48 +7 -18 appdb/appview.php 1.25 1.26 +30 -91 appdb/screenshots.php 1.10 1.11 +80 -107 appdb/admin/adminAppDataQueue.php 1.25 1.26 +0 -131 appdb/admin/editAppFamily.php 1.20 1.21 +3 -10 appdb/admin/editAppVersion.php 1.8 1.9 +237 -46 appdb/include/screenshot.php 1.34 1.35 +38 -17 appdb/include/user.php 1.18 1.19 +0 -2 appdb/tables/appdb_tables.sql
Bah! How are extra links in the appfamily suposed to work? Of course you seem to think that these are not important so you simply removed them from edit appfamily &%@#!. This is wrong !
--
Tony Lambregts
Hi Tony,
Did you read the explanation of the * near the first changelog entry ?
------------------------------------------------------------ * => application have no additional url but version have application description is now just describing an application and giving a link to the application web page. Version description can now have many urls to various interesting resources ------------------------------------------------------------
As I guess you did, here are some more explanations (you can read some in the IRC log if you have some):
APPLICATIONS ------------ *ELEMENTS STILL LINKED TO APPLICATIONS AFTER THESE PATCHES* - Description: General (not wine specific) description about the application. More or less what you can find on the editor site. (You might want to put a link to alternate native applications on linux here or to codeweaver's website at the end of the description as only the first line of the description is kept on summaries like search results, top-ten applications, etc.) - Webpage: webpage for the application
*ELEMENTS THAT WERE LINKED TO APPLICATIONS BEFORE THESE PATCHES* - URLs: Used to link to wine-specific material or version specific material. As it is not of general use for an application it should be deleted to avoid url duplication in APPLICATIONS and VERSIONS (we should also avoid that people put things like "I tested it with wine xyz and it worked" in the APPLICATION description as it is version specific as well.)
VERSIONS -------- *ELEMENTS STILL LINKED TO VERSIONS AFTER THESE PATCHES* - Description: Describe this version of this application, don't duplicate the description that belongs to the application (it is still the case in many version entry). - Screenshots: version specific screenshot
*ELEMENTS THAT WERE LINKED TO VERSIONS BEFORE THESE PATCHES* - Webpage: webpage should be removed as hardly no editor keeps a different page for each version of it's software (I'm not speaking about version-specific support, service packs, etc. which can be covered using the added URLs entries discussed below).
*NEW ELEMENTS THAT ARE LINKED TO VERSIONS AFTER THESE PATCHES* - URLs: using URLs you can give version-specific or wine specific links for the given version of an application. Another reason to don't keep the link from URLs to Application is that they are stored in the same table as screenshots and screenshots are not linked to applications so that if we want to keep URLs for applications we should make two tables.
Of course this is just what I _think_ (I don't *seem to think* anything and discussed everything on IRC, put it in the patch description and of course the patches I send are only proposals, etc.).
Finally nothing is *supposed to work* here as I: - took a great care at cleaning up the forms to remove the thing that are not available anymore using the new table schema - took a great care at testing every single function of the appdb to find regressions - made these changes willingly and documented those as well
I'm looking forward to reading your (and anybody else's) comments about these thoughts and if you found regressions that'd slip through, don't hesitate to send me a bug report, I'll fix them asap.
Best regards,
Jonathan
Tony pointed out a handful of cases where it is useful to have multiple urls for an appId and perhaps multiple urls for a versionId. Do we have that functionality right now via another mechanism? I think we should look to add such a capability back into the appdb since it was used for a small number of apps.
Chris
Le vendredi 04 février 2005 à 23:33 -0500, Chris Morgan a écrit :
Tony pointed out a handful of cases where it is useful to have multiple urls for an appId and perhaps multiple urls for a versionId. Do we have that functionality right now via another mechanism? I think we should look to add such a capability back into the appdb since it was used for a small number of apps.
Chris
I'd be interested to know about these cases, do you have examples ?
An example of app where we have URLs in application is here: http://appdb.winehq.org/appview.php?appId=10 (Word). IMHO (if the examples you are speaking about are like the Word example), in this case it is much more clear to put the link in the description than to have only a one-word description for each link.
_BEFORE WITH URLS IN APPS_ ------------------------------------ ¦ AbiWord ¦ ¦ ¦ CrossOver Office ¦ Description ¦ ¦ OpenOffice.org ¦ ¦ ------------------------------------
_APPS NOW_ ------------------------------------ ¦ Description ¦ ¦ ¦ ¦ Try it with CrossOver Office ! ¦ ¦ ¦ ¦ *Native alternatives:* ¦ ¦ - AbiWord ¦ ¦ - OpenOffice.org ¦ ------------------------------------
As you can see you can be much more descriptive and classify the interesting links.
In versions URLs have still a lot of sense as you can do thinks like: ------------------------------------ ¦ Download app ¦ ¦ ¦ Download MSX.dll ¦ Description ¦ ¦ ¦ ¦ ------------------------------------
See here for example: http://appdb.winehq.org/appview.php?versionId=2463
As I said I'd be interested to see these special cases where App URLs make sense. If there are more than only 4-5 application that need it and you think that the way to do it above is not right in these cases (or in all cases) we should of course bring back this feature.
To bring it back: 1) readd appid in appdata table: bad as it is strange to have columns with appid=0 for screenshots and versionid=0 for URLs
OR
2) rename appdata in versiondata, create a new appdata table and create an url class that has an appid and version id parameter, if appid is given, queries will be made in appdata and if it's versionid they'll be made in versiondata
OR
3) readd appid in appdata table and let people ad screenshots for applications (this can be screenshot of the application running in windows to show people how it looks like normally). I personnaly don't like it too much as the purpose of removing App URLs and version Keywords was to remove the bloat in editing pages to ease the task of maintainers and try to have a consistant appdb.
OR
...
Regards. Jonathan
Tony, does support appears to address your concerns that we lost functionality It looks good to me.
Chris
On Saturday 05 February 2005 5:43 am, Jonathan Ernst wrote:
Le vendredi 04 février 2005 à 23:33 -0500, Chris Morgan a écrit :
Tony pointed out a handful of cases where it is useful to have multiple urls for an appId and perhaps multiple urls for a versionId. Do we have that functionality right now via another mechanism? I think we should look to add such a capability back into the appdb since it was used for a small number of apps.
Chris
I'd be interested to know about these cases, do you have examples ?
An example of app where we have URLs in application is here: http://appdb.winehq.org/appview.php?appId=10 (Word). IMHO (if the examples you are speaking about are like the Word example), in this case it is much more clear to put the link in the description than to have only a one-word description for each link.
_BEFORE WITH URLS IN APPS_
¦ AbiWord ¦ ¦ ¦ CrossOver Office ¦ Description ¦ ¦ OpenOffice.org ¦ ¦
_APPS NOW_
¦ Description ¦ ¦ ¦ ¦ Try it with CrossOver Office ! ¦ ¦ ¦ ¦ *Native alternatives:* ¦ ¦ - AbiWord ¦ ¦ - OpenOffice.org ¦
As you can see you can be much more descriptive and classify the interesting links.
In versions URLs have still a lot of sense as you can do thinks like:
¦ Download app ¦ ¦ ¦ Download MSX.dll ¦ Description ¦ ¦ ¦ ¦
See here for example: http://appdb.winehq.org/appview.php?versionId=2463
As I said I'd be interested to see these special cases where App URLs make sense. If there are more than only 4-5 application that need it and you think that the way to do it above is not right in these cases (or in all cases) we should of course bring back this feature.
To bring it back:
- readd appid in appdata table: bad as it is strange to have columns
with appid=0 for screenshots and versionid=0 for URLs
OR
- rename appdata in versiondata, create a new appdata table and create
an url class that has an appid and version id parameter, if appid is given, queries will be made in appdata and if it's versionid they'll be made in versiondata
OR
- readd appid in appdata table and let people ad screenshots for
applications (this can be screenshot of the application running in windows to show people how it looks like normally). I personnaly don't like it too much as the purpose of removing App URLs and version Keywords was to remove the bloat in editing pages to ease the task of maintainers and try to have a consistant appdb.
OR
...
Regards. Jonathan
Jonathan Ernst wrote:
Le vendredi 04 février 2005 à 23:33 -0500, Chris Morgan a écrit :
Tony pointed out a handful of cases where it is useful to have multiple urls for an appId and perhaps multiple urls for a versionId. Do we have that functionality right now via another mechanism? I think we should look to add such a capability back into the appdb since it was used for a small number of apps.
Chris
I'd be interested to know about these cases, do you have examples ?
An example of app where we have URLs in application is here: http://appdb.winehq.org/appview.php?appId=10 (Word). IMHO (if the examples you are speaking about are like the Word example), in this case it is much more clear to put the link in the description than to have only a one-word description for each link.
_BEFORE WITH URLS IN APPS_
¦ AbiWord ¦ ¦ ¦ CrossOver Office ¦ Description ¦ ¦ OpenOffice.org ¦ ¦
_APPS NOW_
¦ Description ¦ ¦ ¦ ¦ Try it with CrossOver Office ! ¦ ¦ ¦ ¦ *Native alternatives:* ¦ ¦ - AbiWord ¦ ¦ - OpenOffice.org ¦
As you can see you can be much more descriptive and classify the interesting links.
In versions URLs have still a lot of sense as you can do thinks like:
¦ Download app ¦ ¦ ¦ Download MSX.dll ¦ Description ¦ ¦ ¦ ¦
See here for example: http://appdb.winehq.org/appview.php?versionId=2463
As I said I'd be interested to see these special cases where App URLs make sense. If there are more than only 4-5 application that need it and you think that the way to do it above is not right in these cases (or in all cases) we should of course bring back this feature.
By your argument we do not need the urls at all and could easily put them all in the description.
To bring it back:
- readd appid in appdata table: bad as it is strange to have columns
with appid=0 for screenshots and versionid=0 for URLs
OR
- rename appdata in versiondata, create a new appdata table and create
an url class that has an appid and version id parameter, if appid is given, queries will be made in appdata and if it's versionid they'll be made in versiondata
OR
- readd appid in appdata table and let people ad screenshots for
applications (this can be screenshot of the application running in windows to show people how it looks like normally). I personnaly don't like it too much as the purpose of removing App URLs and version Keywords was to remove the bloat in editing pages to ease the task of maintainers and try to have a consistant appdb.
OR
...
Regards. Jonathan
Option 1 is the way to go as far as I can see. We should not give up functionality for normalization. Normalization is fine but it is not an end in itself. The appdata table _worked_ the way it was. Sure it was not normalized but that was not a big problem. Adding a new table is not needed.
--
Tony Lambregts
-
Chris Morgan -
Jonathan Ernst -
Tony Lambregts