Hi, Christian Hammond wrote: > I'm working on an experimental project at VMware that will require us to > have greater control over a window's position while the window manager > is dragging it. We'd need to basically give the application more control > over the movement of the window, yet allow the the window manager to > apply whatever effects and conditions it would typically apply while > moving a window. We'd need to let the application, for example, prevent > the window from going past a certain part of the screen, or to stay > within a bounding box, or to just prevent it from moving over another > window.
It would seem more logical to me to convey these constraints to the WM, rather than adding an "escape hatch" that potentially leaves the WM with no clue what's going on or why. I'd guess metacity would have a really hard time knowing how to implement the "escape hatch" - most of the time, the move constraints in the metacity code apply even to moves originated by the WM itself. Certainly the codepaths related to this are "interesting" enough already. Is it possible to develop a more semantic hint instead of the escape hatch? (without more detail on the project, it's tough for me to suggest anything.) Havoc _______________________________________________ wm-spec-list mailing list wm-spec-list@gnome.org http://mail.gnome.org/mailman/listinfo/wm-spec-list
