Peter Hutterer wrote: > The current code exposes to inconsistent updates, i.e. if handler N succeeds > but handler N+1 fails in setting the property, an error is returned to the > client although parts of the server now behave as if the property change > succeeded. I understand the problem, but are there really uses for this? I mean, 2 handlers responding to the same prop is nothing I could make sense of. At most, an additional handler which 'watches' the prop this way is conceivable to me.
> This patch adds a "checkonly" parameter to the SetProperty handler. The > handlers are then called twice, once with checkonly set to TRUE. > On the checkonly run, handlers _MUST_ return error codes if the property > cannot be applied. Handlers are not permitted to actually apply the changes. > On the second run, handlers are permitted to apply property changes. > Errors codes returned on the second run are ignored. Things could be simpler IMO when having different return codes for 'I don't care' vs. 'Yep, property properly changed'. I think that's the root of the problem. Fixing that would make it possible to discourage 'double' handlers by traversing handlers only until one succeeds. If that's a design goal, however, simply ignore me. Cheers, Simon _______________________________________________ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
