1

Here are just two ideas for some better window management


Problem: Precision sizing of a window takes longer than it should and is more prone to frustration on a miss
Idea: Make a 1/9 (e.g., tic-tac-toe) sizing grid on any window that helps with sizing and precision
update: Turns out this is already implemented, see here, thanks Moult!

Imagine not re-sizing a window based on the border of the window (which requires precision) but by holding a modifier key and dragging your mouse in any one of the nine (tic-tac-toe like) regions of a window instead. No more hunting for the border, a blind Parkinson's patient will now be able to enjoy re-sizing a window without sacrificing aesthetics to do so.

Problem: When you have more than a single display, some windows play Hide and Seek.
Idea: Help a window know where base is and help them get there

One of the small frustrations of using KDE and dual displays is, launching an application that insist on opening up in the one display that is turned off or on the display in which the source is different. I propose the following solutions from most preferable to least.

• A Kwin rule that "all new windows can only open in area/display"
• A "focus window here" option that doesn't take you to the window but brings the window to you
• A panoramic view widget of the desktop viewing area that allows you to move windows around
• A click and hold of the window task panel entry that allows you to blindly move a window around

These are two ideas.

For the first: try alt+RMB dragging on a window. That should give you exactly what you want

For the first: try alt+RMB dragging on a window. That should give you exactly what you want

Damn, you guys are too fast at implementing these features.

One of the small frustrations of using KDE and dual displays is, launching an application that insist on opening up in the one display that is turned off

This should *never* happen unless by "turned off" you mean "power off" - better turn off displays through xrandr, what unregisters them and helps the GPU.

A Kwin rule that "all new windows can only open in area/display"

4.10 has a screen rule, that allows to enforce or initially select a screen (notice that unless you force the screen, the client can still just move somewhere after being shown - this cannot reasonably be prevented and is what i assume you encounter for the active desktop is either the one with the active window or the mouse cursor on it, configurable in "kcmshell4 kwinoptions")

A "focus window here" option that doesn't take you to the window but brings the window to you

Ie. you want a way to move the window under the mouse cursor on activation?
The problem with this is, that you'll quickly gather all windows in one location - really rethought that
What is of course possible with compositing is some excessively annoying animation to hint activation =)

If this is just because of the deactivated screen, see general solution.

A panoramic view widget of the desktop viewing area that allows you to move windows around

aka "a pager"?

Quoting all of this

To clear up about windows opening up in the display that is turned off, I mean powered off. Windows have this aggressive tendency to open up on another display, regardless of where the mouse is and regardless of which display is the primary display. It's frustrating when the display is powered on *but* even more-so when it is powered off.

KDE always had some amazing options, some of them well hidden. I was hoping that by "focus window here", there would be a shortcut that would take a window from one display and move it (full-screen, maximized, etc) to another. I do all sorts of clicks on the task panel entry for a window hoping something like this would happen but nothing.

Although the Pager does show a panoramic view of the displays, it doesn't help at all moving full screen or maximized windows.

I'm really glad if this is addressed in 4.10 because as it is now, it's a major pain in the **** to lose control of your windows or to go through several extra steps to get to one.

I would have to agree. Windows can also get lost in-between activities.

It is addressed in the way that you can enforce windows to be always on a specific screen (and you cannot move them away either)
For 4.9 try to disobey the windows geometry request - that *might* be sufficient.

As for "focus window here" the problem is "here" because if "here" is under the mosue cursor and a shortcut had the problem to know "what window?"

What you likely want (file a wish/bug against libtaskbar, resp. the taskbar plasmoid) is a variant of the "move to screen" menu item you got in the Alt+F3 menu - it could theoretically also raise the window, but has to obviously happen in some hook on the window you still got (the taskbar) and not in the WM (it's supported there, but that doesn't help you)

That doesn't help the fact that you probably want to turn off the screen in X11 - not just the backlight of your panel (which will then enter standby anyway)

When you press Alt+F3, you can move a window (maximized or not) *but* when you right click a task entry, if the window is maximized, you have to uncheck that first and then right click again to move it. Imagine for a moment, middle clicking on a task entry and that window get's moved to the same display where the task panel is and that's what I mean by "focus window here". Sorry for not being clear about that.

It would be nice if new windows only opened up on a given display unless a specific window rule said otherwise. If you say that'll be available in 4.10, I'm glad to hear it and it's a welcome feature that's for sure.

1920x1080 wrote:It would be nice if new windows only opened up on a given display unless a specific window rule said otherwise. If you say that'll be available in 4.10, I'm glad to hear it and it's a welcome feature that's for sure.

Its a welcome features for sure.