I have issues with winetools, it seems to go round in circles after creating the base setup. Watching the output of this on the command line it seems winetools does some really dumb things, for instance trying to move the program files folder into itself!
After reading what was said recently about winetools in WWN it occurred to me that something should be done regarding wine configuration and application installation which fits with the philosophy of wine, retains as many built in libraries as possible rather than windows native libraries and gives general improvement over the hack fest which is installing and running windows applications on linux.
Introducing wine-doors a play on the word windows designed to inspire the ideal of opening doors to windows applications users.
Currently winetools only supports installing a few applications, like internet explorer, google earth, winamp and others but these installation profiles rely heavily on native dlls, and there isn’t a method of adding to this and therefore expanding the support.
Firstly and importantly I wouldn’t want to close wine-doors to applications which I don’t have the time to build up profiles for, the solution that should be reached regarding wine application installation should be easily accessible to new users and easily expandable by windows applications developers who want their apps to run on wine. The solution is glaringly obvious, I call them application packs, but essentially they are just scripts and resources used to suppliment application binaries to make wine installation simpler.
Another shortcomming of winetools is that it currently uses Xdialog and GTK+1.x rather than a better supported GTK2, it seems to be a fairly badly hacked together series of scripts which is badly maintained, badly designed and generally too reliant on microsoft code.
So I think it would be best to begin wine-doors by using pyGTK2 to provide the user interface. Using sidenet wine configuration tool and winetools as reference material and simplifying the installation as much as possible.
The final thing that annoys me about wine and cedega is that they don’t install applications as root, and therefore they aren’t made accesible to every user of the computer, and if I wanted to have 3 users on a machine with halflife2 installed for instance that would take up 12Gb of hard disk space rather than the 4Gb required for a single installation. The main problem here is that cedega and wine need to access the program files folder as if they were the administrator of a windows computer.
So why not use clever linking for save game folders cache folders etc… and set permissions for files which must be globally writable, basically try as hard as possible to make things work for all users of a desktop. While also allowing wine doors to work just like wine currently does within a user home folder.
Finally, I’m a transgaming subscriber, and I find the point2play install interface terrible, it just doesn’t work the way you’d expect it should, doesn’t work well as a user and doesn’t create desktop entries for games. I think that if I include support for cedega for transgaming subscribers, and for cedegacvs users a certain level of wine zen could be reached.
Below is a preliminary diagram of how things should work, in an ideal world.
Hopefully I’ll be able to get started on this soon.
Have added a link to your project page on the wiki.(under utilities)
regards
jb