Bug 229942 - "Move" command should allow off-screen window moving same as Alt + click trick
Summary: "Move" command should allow off-screen window moving same as Alt + click trick
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Unclassified
Component: core (show other bugs)
Version: unspecified
Platform: Fedora RPMs Linux
: NOR wishlist (vote)
Target Milestone: 4.9
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-03-08 13:40 UTC by Jaroslav Reznik
Modified: 2016-04-20 14:33 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In: 4.9


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jaroslav Reznik 2010-03-08 13:40:24 UTC
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.
Comment 1 Thomas Lübking 2010-03-08 15:08:51 UTC
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...)
Comment 2 Thomas Lübking 2012-03-17 22:42:47 UTC
@Martin
Change is simple:
useractions.cpp:137 
mMoveOpAction->setData(Options::MoveOp);
-> mMoveOpAction->setData(Options::UnrestrictedMoveOp);
Comment 3 Thomas Lübking 2012-04-17 19:28:32 UTC
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
Comment 4 Thomas Pfeiffer 2016-04-19 15:56:46 UTC
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.
Comment 5 Thomas Lübking 2016-04-19 20:46:14 UTC
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
Comment 6 Martin Flöser 2016-04-20 06:29:07 UTC
> 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?
Comment 7 Thomas Pfeiffer 2016-04-20 09:38:54 UTC
(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.
Comment 8 Thomas Lübking 2016-04-20 14:33:53 UTC
(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/