Jason Green wrote:
On 3/11/06, Tony Lambregts tony.lambregts@gmail.com wrote:
In simple terms we get WineTools to query the AppDB with an application name (ie somename.exe) and we return a list of applications for the user to choose from and the after the user selects the program WineTools gets the appropriate overrides from the AppDB and sets them for the user.
I think that that this is do-able if we work together.
First, great idea.
Second, here's a [very incomplete] list of what would need to be done to pull this off:
- AppDB would have to be extended to be able to get and report this
data, and it would make sense for each App's maintainer to be able to manage that information.
- Biggest issue here is that this information could have a tendency
to change very rapidly, so it might overload the app maintainers if they had to track this for each version of wine. What I think would make sense is to have regular snapshots (every 3 months?) and release a new version of "Winetools Plus" or whatever you want to call this thing a month later to give the maintainers time to update each of their apps based on the frozen version.
Well how often this should be updated depends on the development of the various dll. If all a program requires wine to emulate Windows 3.1 then it might not need updating ever.
- Data needed: AppID, AppVersionID, WineVersionID, Window Version, DLL
Overrides, Window settings (fullscreen/windowed - sometimes and issue), Sound options, Video acceleration required, General notes or HOWTO's, etc. You would need separate overrides/settings for Installing vs. Running the app.
You are right that we will probably need entries for both the installer and the program itself.
- AppDB could dump this information to an xml format which "Winetools
Plus" could be distributed with. Maybe have an option to download the latest xml file directly from winehq.org.
I see this as a dynamic thing as the list could get quite large. and downloading the whole thing for just one program seems excessive.
- The 'Winetools Plus' front-end would just be a menu which would
query all of the apps in the xml dump. The user picks they app they want to install, and it reads the necessary information, verifies the source installation media, and goes at it.
I think that it would be better if the user entered into WineTools the name of the exe they were trying to run but you may be right about this option
- Applying patches to apps might get tricky (e.g., where wine only
successfully runs version 1.5 of the app, but 1.0 is on the CD), but I'm sure it could be worked out.
We cannot solve all the problems at once.
Anyway, there's a start. That would encourage users to get involved in the AppDB reporting process as well as better organize how to just "get things done" using wine.
I would like to here from Joachim as to what WineTools would need. The main thing I would like to get away from in WineTools is the blanket changes that it now does of making wine emulate windows 95 and use native Dlls by default.
Thanks for your input
--
Tony Lambregts
Tony Lambregts