May be a bad idea to have Winetools in the next SUSE release

[Tony Lambregts]

Jason Green wrote:
> On 3/11/06, Tony Lambregts <tony.lambregts at 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