Stephan Assmus <superstippi@xxxxxx> wrote: > When reading the patch, I figured as much, but it's between the lines > and a clear example of too little comments or explainations in the > code. I agree that we have too little documentation, but Window::Backmost() is actually documented. Removing it without even checking what it does is not between the lines, and should be avoided. > I think what Clemens tries to do should still be made possible. Even > with the constraints taken care of, it should be possible to mess > with > the window order in a deterministic way, and that means SendBehind() > can > actually raise a window too. But I don't think the computation of the > dirty region, or rather the region that is still clean, was anywhere > near complete after the change. Sure, it is definitely possible to implement this, I just don't think that it matches the semantics of BWindow::SendBehind() anymore. It would even cause bad user experience in case the window *is* already behind the specified window, because your application would change the window order without any benefit. It might have a use case (even though I can't think of one outside of manually grouping windows -- in which case the subset window approach could be used instead), but it should not clobber the semantics of the existing SendWindowBehind() call. Bye, Axel.