Alexandre Julliard : x11drv: Moved desktop mode handling to the
explorer process.
Mike McCormack
mike at codeweavers.com
Wed Mar 29 05:15:47 CST 2006
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
More information about the wine-devel
mailing list