Version: (using KDE 4.4.0) OS: Linux Installed from: Fedora RPMs Steps to reproduce 1. click application icon in top left corner 2. select "Move" 3. try to move window off screen (on top) It should behave similar to Alt + click trick with windows center as reference point. Reason - large dialogs with buttons off screen and disabled user who can't press Alt and move Windows.
interestingly this is bound to the decoration (layout). looks like the screenborder is tested against the upper border (i.e. if you place the titlebar on the left and have no borders otherwise, this works in all directions, including left out...)
@Martin Change is simple: useractions.cpp:137 mMoveOpAction->setData(Options::MoveOp); -> mMoveOpAction->setData(Options::UnrestrictedMoveOp);
Git commit f6437dbc13ca203136d994d5c99239bb666ef02c by Thomas Lübking. Committed on 16/04/2012 at 17:53. Pushed by luebking into branch 'master'. make the rmb popup move trigger an unrestricted move FIXED-IN: 4.9 REVIEW: 104620 M +1 -1 kwin/useractions.cpp http://commits.kde.org/kde-workspace/f6437dbc13ca203136d994d5c99239bb666ef02c
I am strictly against this change. It has to be possible to easily revert actions. With this change, a user who does not know about the alt+drag method can move a window to a place where they don't know how to get it back from. The argument about the dialogs with off-screen buttons is not a good argument. I've checked with GNOME 3, Ubuntu, Xfce, LXDE, Windows and OS X. Of those, Xfce was the only desktop environment which allowed unrestricted moving triggered from the title bar menu. That means that an application which makes dialogs that are taller than the screen and puts important buttons at the bottom is - even if it runs only on Linux - screwed in at least three desktop environments. We should not risk users manoevering themselves into a dead end just to be one of a minority of desktop environments where even otherwise broken applications work. Instead, people should file bug reports on these applications and get them to be fixed.
I agree on the "broken dialogs are broken" part (though it happened a lot on early netbooks) The driving question is then of course why the move action is exposed in the menu at all. (The menu is accessed either via Alt+F3, but then your concerns do not apply, or the titlebar which prominently moves the window ;-) Maybe this is a good hook to prominently teach the user about the feature? "You could just have pressed Alt and moved the window by clicking it anywhere, you know?" [ ] Yeah, I don't have a keyboard, so don't tell me again, 'key? [Abort] [Retry] [Ignore] PS: 2010-03-08 13:40:24 UTC 2010-03-08 15:08:51 UTC 2012-04-17 19:28:32 UTC 2016-04-19 15:56:46 UTC Did somebody shoot himself here? ;-P
> Did somebody shoot himself here? ;-P The Wayland port of libtaskmanager uncovered that the move from task item and window decoration behave differently. I asked Thomas P. to look into it. @Thomas P: do you see ways how we can make the unrestricted move/resize more discoverable?
(In reply to Martin Gräßlin from comment #6) > @Thomas P: do you see ways how we can make the unrestricted move/resize more > discoverable? The global shortcut overlay that we're planning could cover this feature as well. It would still be only accessible with the keyboard, but I don't see any way around that, because I don't see any way to move a window with its titlebar off-screen back again without the keyboard.
(In reply to Thomas Pfeiffer from comment #7) > It would still be only accessible with the keyboard, but I don't see any way > around that, because I don't see any way to move a window with its titlebar > off-screen back again without the keyboard. - Taskbar (though not an internal feature) - active screen border (less "move window", more "move viewport¹"; gets the titlebar in sight again) - dedicated move/resize mode² (accessible from eg. /any/ Alt+F3 menu, as well as dbus/shortcut/whatever) [1] http://kde-look.org/content/show.php/Big+Screen?content=163224 [2] https://git.reviewboard.kde.org/r/103022/