KWin/Default Options

Default Options for KWin 4.9

How to Help

Help us finding better default options for KWin 4.9. For that all you need is a 4.8 installation configured with KDE default settings (for example a new user account). Just use it and report issues here for what can be improved. Please add a section for your suggestion and provide a rational why you think there could be a better default option. It would be really great if you could also name which config keys need to be changed. You can easily find these in your kwinrc file in ~/.kde/share/config/.

Proposed Changes

Activate Desktop Change OSD and Desktop Grid on upper right screen edge

Rational

By default KWin uses only one virtual desktop. So even if the Desktop Change OSD and Desktop Grid on right upper screen edge is enabled it does not have any consequences for a user with default settings. But a user who wants to use virtual desktops gets a better configured system for virtual desktops without having to perform changes at many places.

Config Changes

metadata.desktop file for desktop change OSD script needs to be enabled by default and in Effect-DesktopGrid group the BorderActivate config key has to be set.

Review Request

todo

Commit

todo

Proposed By

Martin Gräßlin <mgraesslin [at] kde [dot] org>

Comments

> By default KWin uses only one virtual desktop.

Is this also true for most of the big KDE distributions? Kubuntu for example defaults to two virtual desktops when creating a new user. This does of course not mean one must adhere to settings of a specific distribution, but it is probably worthwhile to consider changes distributions apply to the default settings.

Why should it be the upper right screen edge. Is that not the most likely place for accidental activation, since the window control buttons are traditionally also located there? --Dns-hmpf 22:54, 12 March 2012 (UTC)

---

openSUSE defaults to two desktop as well. I think the top right edge is not optimal in multi-monitor setup, when the primary screen is on the left. (gpe)

---

The defaults of the distros do not matter when choosing the defaults for KDE Plasma. In fact it is quite bad that distros did change that.

> Why should it be the upper right screen edge. Is that not the most likely place for accidental activation, since the window control buttons are traditionally also located there?

I have been using it there for the last few years and never triggered it accidentially and I don't see a better corner for it. --Mgraesslin 13:22, 15 March 2012 (UTC)

---

With the close button in the top-right of the screen I can't imagine people won't activate that if you put something there. I've tried to use the top-right corner for stuff but always activate it accidentally.

About the effect chosen, for a while I used the top-left for present windows but as I have present windows as alt-tab switcher I pretty much always used the key combo. Now I have desktop grid under top-left and that actually works. I would suggest to go for top-left and use desktop grid instead of present windows. Jospoortvliet 10:35, 23 April 2012 (BST)

---

Desktop Grid instead of Present Windows in left upper corner is for 4.9 no solution as it is not as powerful (lacking filtering for example). That might be an idea for 4.10 after PW and DG have properly merged into QML --Mgraesslin 17:32, 23 April 2012 (BST)

Present Windows Task Switcher

Rational

By default KWin uses layout based switcher. This is quite confusing with alt+tab because it shows two simultaneous effects when one presses alt+tab so ones eye is not sure what's going on or where to focus. The 'Present Windows' task switcher is much cleaner for the average user to use and see what's going on. Also it's consisent with the 'icon tasks' widget on the panel which displays the same effect when one clicks on it.

Config Changes

todo

Review Request

todo

Commit

todo

Proposed By

Divan Santana <divan [at] s-tainment [dot] co [dot] za >

Comments

Present Windows as Alt+tab replacement is really bad on the eyes with multiple screens. This is currently a blocker for using Present Windows there. --Mgraesslin 13:20, 15 March 2012 (UTC)

---

Well if that can be fixed that'd be awesome - the new QML stuff might be helpful? 'cuz as far as I am concerned, present windows as alt-tab is the most brilliant thing of KWin... Jospoortvliet 10:36, 23 April 2012 (BST)

New shortcut keys for changing virtual desktop

Rational

By default KWin does not have any shortcut key defined for changing virtual desktops, left, right, up or down(only to a specific desktop via ctrl+f1). As by default there is only one virtual desktop this change won't impact the default set up. But if a user enables multiple virtual desktops, it is nice to have ctrl+alt+left-arrow to move VD left, or ctrl+alt+right-arrow to move VD right, and possibly the same for up/down. Just today someone asked what the default was, and I had to let them know there is none and how to manually set it.

Config Changes

`kde4-config --localprefix`/share/config/kglobalshortcutsrc

[kwin]
...
Switch One Desktop Down=Ctrl+Alt+Down,none,Switch One Desktop Down
Switch One Desktop Up=Ctrl+Alt+Up,none,Switch One Desktop Up
Switch One Desktop to the Left=Ctrl+Alt+Left,none,Switch One Desktop to the Left
Switch One Desktop to the Right=Ctrl+Alt+Right,none,Switch One Desktop to the Right
...

Review Request

todo

Commit

todo

Proposed By

Divan Santana <divan [at] s-tainment [dot] co [dot] za >

Enable "Dim Screen for Administrator Mode" by default

Rational

Asking for the user/root password is an important operation, so it makes sense that it is highlighted.

I propose that this effect is turned on by default, as it improves usability, and harmonizes with other desktops who do the same.

Config Changes

todo

Review Request

todo

Commit

todo

Proposed By

Ivo Anjo <knuckles [at] gmail [dot] com>

Change shortcut keys for present windows

The default global shortcuts to toggle present windows should be F7 for window class, F8 for current desktop and F9 for show desktop grid.

Rational

Currently there are three different "toggle present windows" shortcut actions plus the show desktop grid global shortcut keys, F7 is for the window class, F8 shows the desktop grid, F9 for the current desktop and F10 for all desktops.

"Show windows from all desktops" and "desktop grid" are very similar. Therefore a preconfigured global shortcut for only one of this actions should be choosen. I would vote for show grid, the additional spatial clue and the added functionality (drag&drop from one desktop to another) make more than up for the smaller preview window size.

F7 to F9 to toggle the smallest to the biggest action is probably the most expected pattern for users, e.g. compare with volume sliders which go from left to right (not only in some computer interfaces but also on real world stereos).

Config Changes

`kde4-config --localprefix`/share/config/kglobalshortcutsrc

[kwin]
...
ExposeClass=Ctrl+F7,none,Toggle Present Windows (Window class)
Expose=Ctrl+F8,none,Toggle Present Windows (Current desktop)
ShowDesktopGrid=Ctrl+F9,none,Show Desktop Grid
ExposeAll=none,none,Toggle Present Windows (All desktops)
...

Review Request

todo

Commit

todo

Proposed By

Dirk Sarpe <dns_hmpf [at] web [dot] de>

Comments

>Show windows from all desktops" and "desktop grid" are very similar. Therefore a preconfigured global shortcut for only one of this >actions should be choosen. I would vote for show grid [...]" If kwin would only predefined one "present windows" mode as default it should be the "Toggle Present Windows (All desktops)" mode (now Ctrl+F10). The focus of both modes are totally different. Desktop Grid is for arranging all open applications to the different desktops, to expand/close virtual desktops or to switch between them. Toggle Present Windows is more for selecting a window to get it to the foreground and work with this application. For this task Toggle Present Windows provide more features (name of the window, keyboard inputs to filter the window you want to work with, toogle between the windows with the arrow keys, close unneeded windows). So Toogle Present Windows is something like the taskbar but much faster in selecting windows. All the best you have not to leave your hands from the keyboard. Since some distributions only provide one virtual desktop as default (or some people don't make extend practice of virtual desktops) Desktop Grid is in my oppinion the wrong choice for a default (if it's the only one). --Rabuzarus 01:02, 14.March 2012 (CET)

OK, you are right that present windows (all desktops) has features desktop grid has not, but that is of course also true the other way around (see original proposal). So they serve two different purposes. To me the desktop grid feels more natural, to you present windows would be the first choice, if I understood correctly. But what do you think about the order of the shortcuts at the moment? I assume the most used shortcut here is present windows of the current workspace. Present windows of the current class is a subset of the this. Present windows of all desktops and desktop grid both have a larger scope. Therefore I would say a reordering of the keys from smallest to biggest scope makes sense. Currently it is mixed, smallest--biggest--intermediate--biggest. To me that feels wrong and I do not see a rationale there. --Dns-hmpf 23:34, 14 March 2012 (UTC)

I forgot: I seem to miss the point you try to make with the only one virtual desktop argument. You already have the present window for the current workspace anyway, so neither present window for all desktops nor desktop grid would add any functionality there, would it? --Dns-hmpf 23:38, 14 March 2012 (UTC)

You are right desktop grid also offers features which preste windows don't has. ;) It's (like everything) a question which workflow the user has. Of course I don't really know it but I would say beginners are dealing rather with windows than with workspaces. According your point with shortcuts. It seemed logical to me. On the other hand I have some general critization with these shortcuts. I wrote the explanation down to the discussion page of this wiki page (to long to put it here). But Martin already wrote on his blogpost that he is "more reluctant to change keyboard bindings". --Rabuzarus 01:53, 16 March 2012 (CET)

Default Oxygen Window Decoration to "no side border"

Rational

I'm not whether you'd count this as a KWin change, but it's in the same dialog. Please just delete this if you disagree.

It looks a /lot/ nicer, and avoids some of the box inside boxes look that you get with KDE apps. With shadows it provides an implicit border so you don't need any. Also because you're only disabling the side border you don't encounter any problems with size grips or resizing that you get if you disable all the borders.

Obviously this is partly subjective, but I recommend anyone reading this to try it for a day.

Config Changes

share/config/.oxygenrc/

[Windeco]

FrameBorder=No Side Border

Review Request

todo

Commit

todo

Proposed By

David Edmundson <[email protected]>

Comments

I agree with you 100%, I use it on all my systems, but wanted to point out an issue: "no side border" is just awful with suspended compositing, absolutely horrendous. So I'd like to ask that this is only enabled when compositing is on. --ianjo 12:13, 19 March 2012 (WET)

Highlight Windows Effect

Rational

The highlight windows effect is very confusing. sometime if you just want to go to the kmenu and slide over a task entry it will hightlight the window and if you click in this moment on the kmenu - it will open 90%invisible. Other cases - if you minimize a window and let the mousecursor in front of the window it will be highlighted and you can think it isnt minimized

Config Changes

/share/config/kwinrc

[Plugins] kwin4_effect_highlightwindowEnabled=false

Review Request

todo

Commit

todo

Proposed By

Sandra Karuving <lumks [at] ymail [dot] com >

Application Windows Size

Rational

Almost ALL application on the kde workspace will start (first run) with a to smal window. so the first thing every user have to do is to resize the window. So I think it would be good to start maximized if the resolution is smaller than 1200*X start with 70% of the screen if smaller than 1600*X start with 50% if bigger than 1600*X Some applications needs to be blacklisted, like chatclients but for the most it is a good change

Config Changes

todo

Review Request

todo

Commit

todo

Proposed By

Sandra Karuving <lumks [at] ymail [dot] com >

Comments

That's unfortunately something the applications have to set :-( --Mgraesslin 13:25, 15 March 2012 (UTC)

Note to original poster, that it would be worthwhile and perfectly valid to file a bug report to any application that has an incorrect default size. --D ed 16:33, 16 March 2012 (UTC)