GNOME Bugzilla – Bug 357703
Move transients with their parents? (definitely not vice-versa)
Last modified: 2020-11-06 20:08:54 UTC
Matthew suggested this on usability list as well; see near the end of his first comment at http://mail.gnome.org/archives/usability/2006-September/msg00137.html: "I think a better approach would be to move the dialog automatically when I move the window, but to not move the window automatically when I move the dialog." We don't currently automatically move a dialog when its parent is moved, but perhaps we should consider it.
Note that one thing to keep in mind is that dialogs should be kept fully onscreen if the parent window is, and kept partial onscreen no matter what. That basically means the constraints framework needs to be used, but to handle this right it'll need to be extended.
Can you tell me the files I need see?
I don't know exactly what will need to be changed for this. It might be update_move() in window.c or meta_window_move_resize_internal() or be put somewhere in constraints.c or ...
Elijah: I have created a function: static gboolean meta_window_move_transients_func (MetaWindow *window, void *data) { update_move (window, window->display->grab_last_user_action_was_snap, window->display->grab_latest_motion_x, window->display->grab_latest_motion_y); return TRUE; } to move transients calling: meta_window_foreach_transient (window, meta_window_move_transients_func, NULL); But, I don't know to get the right values to move transients left unchanged the relative coordinates. Can you help me?
I tried window->display->grab_latest_motion_x + window->frame->rect.width window->display->grab_latest_motion_y + window->frame->rect.height in update_move, but these values doesn't work...
Created attachment 74323 [details] [review] a wrong patch This patch doesn't work. The transient is moved faster (and out of control) than their parent.
Elijah: Can you help me?
I don't know from beginning to end how this will work out. Some notes: - update_move() is only called for mouse actions, not keyboard ones. Thus, this would break the relative placement when moving windows with the keyboard. The fix probably needs to be in constraints.c in some way. - You'll need to worry about transients that would be offscreen if the same relative position is maintained. constraints should prevent that if you handle it correctly, but then you don't want to change the future relative position if the user starts moving the window back where it came from. (Said a different way, the relative position of the transient should be allowed to _temporarily_ change if it would otherwise be forced off the screen, but if the parent is moved so that it goes back onscreen the old relative position should be used). - Our handling of transients is pretty broken (doesn't handle group transients at all really, other than in stack.c). So, until that's fixed, you won't have a completely working fix for this bug. Though, what you do might be useful learning tool or show how the eventual fix should occur. This is probably going to be a bit difficult to get done and get it right...
bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all old bug reports in Bugzilla which have not seen updates for many years. If you can still reproduce this issue in a currently supported version of GNOME (currently that would be 3.38), then please feel free to report it at https://gitlab.gnome.org/GNOME/metacity/-/issues/ Thank you for reporting this issue and we are sorry it could not be fixed.