Jason Green wrote:
On 3/11/06, Tony Lambregts <[EMAIL PROTECTED]> 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
