Willie Sippel wrote:
Probably true. But Wine has several problems where a 'real' fix is so very complicated that we won't see something anytime soon, probably for years to come (like the DIB engine, planned for years, but nobody seems to even work on it). In the recent two years, Wine became unusable for many users - I even know some guys that switched back to Windows because of 'fixes' to Wine that render lots of application unusable, due to regressions expected when those fixes were commited. Those 'fixes' should never make it into CVS if there's not even a realistic timeframe for fixing the regressions.
How do you propose that we figure out if there's going to be regressions or not before the patches are committed?
Isn't it just better to start with a patch that is "right", but will still show regressions, then fix those regressions, as opposed to starting with a patch that is wrong, and then hacking on it forever trying to solve the unsolvable problems that causes?
The WM-rewrite/ broken windowed-OpenGL support is a perfect example, rendering
My counter example is richedit. As a half-baked wrapper around the edit control, it rotted in the CVS for at least 4 years until Krzysztof finally rewrote the whole thing. If the half-baked version never existed in the first place we would have had a working richedit control alot sooner.
It might be a little bit harder to get things done by avoiding hacks at the start, but it's *alot* harder to get rid of the hacks once they're there. People will complain and complain forever that the hacky version worked for them once for one application, even if the new version does alot better for all applications.
Mike