winefan62 Please read my responses and stop being a twit. I am one of the longest people assisting users to get wine up and running. > 1-POL already use Vanilla wine, builded from official sources, no modification. I have not disputed this. But in past for some programs POL has used custom versions and not displayed to users that they are so they bug report to us wrong. Yes we are happy with move here to the correct path. > 2-A child can reproduce POL script with wine+winetricks ince POl functions are the SAME as winetricks do but instead of a monolithic monster with 90£ useless functions (for a gamer), they use small simple usefull functions like nstalling d3dx9 dlls or dotnet or vcrun...only th usefull part of winetricks (again, for a gamer). This is a lie. POL script has screwed up installs of dotnet due to using out of date method. Also has had issues in past of installed d3dx9 dlls without overrides when they now require overrides due to wine having own versions. So exposing errors that don't exist in clean or if person used the current winetricks at the time. Yes using the winetricks upto date in one case made the program issue with POL not appear. Due to the fact it was override alterations due to changes in wine for dotnet. This here is one of our biggest issues with POL. It would be simpler for these parts if POL dropped having there own scripts for it and just used winetricks like everyone else. Yes I know its a 192 kb file. Advantage is that is single version. If I need to retest with the same scripts the person used I grab the one file and I can. So I can bug report winetricks as well Even if it was a 1 mb file I would not care from a support point of view. Key thing is that everyone is installing all those parts the same way from the same script. We will want command line users and POL users to be aligned so making appdb entries simpler. POL making there own subscripts independant to winetricks just adds another possible area of difference. Items are simple to debug is the number of variables are kept to a min. > 3-POL use tips/tweaks/modifications reported on AppDB tests and AppDB tests only to make the game WORKING, like disabling hardware cursor for Kotor, ect...So arguing about modifications (not you Dan) is ridiculous. There are issues here. There should be matching Bug numbers for these alterations. Yes wine here is not without our own internal problems. Where appdb maintainers write up howtos then forget to take out bug reports. Bug reports are what developers use to trace down what they should be fixing. Also instructions in the appdb may not be current to developer status. Bugs are. Being based purely off appdb can be trying to make programs run with out of date instructions so can be suffering from bugs that should not exist. But when something goes wrong and the program does not work. Every alteration has to be tested. I learnt this from a game called roll-cage. Each alteration can cause a program to take a different internal code path. > 4-POL v4 will use full python language for scripts, no more bash code you wil definitly don't want tests from it. > > I perfectly understand you need to be absolutely sure problems come from wine or the game only, but in his actual form, POL is a GUI doing BASH commands, the EXACT same bash commands you will do installing the game by hand. Why do we maintain winetricks. We don't trust people todo exactly the same long processes from the command line. And we don't want to have to read a long process for installing like IE and so on. Yes winetricks does not ship with wine but its the official way to install native code parts we support. No point saying the exact same bash commands. Were those compads executed from a version numbed script that we can trace to an exact version of winetricks yes or no. Current answer is no so what POL does just makes our live harder. If this is going to change to yes I will be happier. One of the current issues is winetricks maybe updated and POL is not so POL user I cannot simply say update your winetricks and try again and see problem go by by. We don't want to have to be debugging more than we have to. Asking a person what version winetricks they have checking that its working saves us doing support hours. > Don't tell me, when you see wine error output like this "err:ole:RevokeDragDrop invalid hwnd 0x1012c" it's POL fault, this is indeed wine error output. > > Now when POL users report POL bugs (GUI bugs) here it's absolutely normal you tell them it's POL related but when they report wine problems, it's neither fair nor normal to tell them it's POL fault. Problem is this is your lack of skill. I have seen RevokeDragDrop be POL only for an application due to list of alterations POL did. We will reject all items that have not been tested by our methods so get over it. Even when we see that in normal wine we go back and to a clean prefix and test each addition. Its all about code paths. Adding native parts or altering registry keys can change the internal code path of the application causing it to use a different set of functions. Ie one combination of parts the application can work perfectly another it can fail. Now if the bug is coming only from a particular combination we need to know. Could be a runtime. This is part of diagnostics. Basically we need POL users to be able to follow our methods. Other wise POL has to take care of itself. POL is making it hard for us to tell what is at fault. Is it the program not working or is it the additions that POL has added to so called make the program run. DanKegel is walking the POL author through how debuging methods. What I have listed here over and over. Something plays up go back to no alterations and then test and add each alteration 1 at a time to see if problem will magically disappear. Hopefully locate where the bug is coming from. Basically you cannot ask us to support POL at this stage and refuse to install wine manually so you can follow our debuging methods. If users don't want to follow manual diagnostics at this stage they should bug report to POL and hopefully someone there will come and follow our process or alter POL so it can follow our process. Yes POL is heading in the right direction to be compadible with people like me. But its not there yet there are still issues where it cannot follow the debugging methods. Yes the debugging method compatibility is one of keystone for us to be able to support POL and share POL results across all users of wine. And from what I am seeing is the last keystone left then we will be able to bridge the user-bases. Basically stop argueing that POL is fine and start working on how we can get the last keystone so it works.
