One of my personal adjustments to KWin is using the top right screen edge as a trigger for the Desktop Grid effect. With the switch to KWin on 5 this hasn’t worked for me any more as we don’t have code in place to transfer the old configuration to the new system.
Last week I had enough of it. It was breaking my workflow. So I had to do something about it and had the following possible options:
- Change the default: bad idea as we don’t want to use the upper right corner as that’s where maximized windows have their close button
- Carry a patch to change the default on my system: bad idea as that breaks my git workflow
- Just change the value in kwinrc
- Bring back the configuration module
As I considered just modifying the config value in kwinrc as not a durable solution I decided to go for bringing back the configuration module (KCM).
After a little bit of hacking and facing the problem that it used some not-yet ported library inside kde-workspace I got the code compiled and installed. But when I started it using kcmshell5 from kde-runtime I hit an assert.
So either my code was broken or kcmshell5. I didn’t really want to investigate the issue of the assert and decided to try the most obvious thing to me: use another implementation to test the kcm. And so I started to port systemsettings.
After about one hour of work I had systemsettings compiled, linked and installed and could start it, but alas my KCM was still hitting an assert. So what to do? Is it my KCM or is something more fundamentally broken which needs fixing in a different layer? How to test (I still didn’t want to investigate) so I started to port a few very simple KCMs from kde-workspace as systemsettings is at the moment still rather empty. And look there, they worked in both kcmshell5 and in systemsettings.
So I started to port another KWin module and that one also hit the same assert. After some discussion on IRC with Marco I learnt that he also hit the same assert in another KCM which means that there was a pattern. And finally I started to investigate. Very soon I had a testcase with a slightly reduced KCM which I could get to hit the assert with adding one additional element to the ui file. A good start to find a workaround and now my KCM loads in systemsettings and I have my screenedge back:
Screenshot is featuring both systemsettings and KWin using Qt 5 and KDE Frameworks 5!
Now all I need to do is to extract my minimum “make it crash” code as a testcase and submit a bug report to Qt.
Systemsettings always worries me. Analyzing “Screen edges” kcm:
Banner: A 0-value description and a mini icon replica..
Window snapping: why ever disable Maximizing/Tiling? Don’t like it? (wait, it’s very useful!) Don’t drag’n’drop a window on screen border.
Quarter tiling: I never used it. Should we add another option to disable it? Or maybe let’s just default its activation area to 5%, just to never trigger it accidentally.
Switch desktop on edge: Can we simply have safe timing defaults? Anyway it belongs to Virtual desktops kcm. Why bothering if i use no virtual desktops?
Active screen endges: probably the only thing to show. Now with full fancy QML magic.
Anyway kwin flies, tnx 🙂
and now you made the typical user mistake to extrapolate from yourself to everyone. As you don’t need it, you don’t need the option and want to adjust the default so that it suits your needs. Btw. there is the option to disable it: 0 %
Now you can remove all the options you don’t need and make that default. It will end in many users complaining that we remove features. It’s not as easy as it might look from the user perspective.
here in 4.11.1 0% can’t be set.
anyway i believe that finding sane defaults that accomodate who uses a feature and who doesn’t is still possible.
You can do advanced tweaking in other ways, you don’t need to remove features.
Additional pain-point: italian description of “quarter tiling” option is something so esoteric that even to me that i know both feature and language.. it reminds me a bit that power management option..”never prevent an action on lid close”.. WTF is it!? What it does if..!? “You talkin’ to me? You talkin’ to me?” 🙂
I hope systemsettings modules and shell, after well pondered collective thought, get revamped in plasma workspaces 2.
hey, it’s not my fault the translators get it wrong and unfortunately we cannot even verify it as we don’t speak Italian.
off course it’s your fault! not speaking italian, how dare you! 😉
no, the interesting point is that translating is rather complex stuff.
how to render concepts/operations from a language to another that doesn’t exactly have them?
and how to vulgarize geeklish to universally comprehensible words is even more difficult.
if we add the notion/goal of design, how many trobles: it could take lots of words to explain something that, ultimately, is really easy to see.
And it is easy to see that many guis have certain long descriptions that are even more difficult to understand than the option they try to explain. Sometimes they are not worth it.
What i could say is that certain options whose function isn’t easy to conceptualize in practice probably shouldn’t appear in a delicate place like systemsettings.
That is the case, again, where sane defaults and the ability to tweak them through terminal/file editing, can prevent the aforementioned issue.
Hey at least I had Latin at school – so to say the more traditional Italian 😉
Well there’s the option to add context to a string to properly explain it. Just checked, this is not done for the quarter tile option. Probably we thought it’s not needed. Of course feedback from the translators helps, like “hey I don’t understand this option, please add context”. That’s something I have seen a few times.
I once complained to the German translators about bad translations and they told me that they don’t run the GUI at all, they just translate. That IMHO explains why there are bad translations. If you don’t know what the string will be used for you cannot translate it properly IMHO. A reason why I try to use software only in English and also reach technical manuals only in German.
I know that at least one of them (German translators), as documentation writer, run the program for sure 🙂
iirc the German translation team has now way less translators than before, which does not help.
You can always join the mailing list of the Italian translator and start a new discussion, proposing new translations. We have also an IRC channel, even if with low activity (the list is better).
http://community.kde.org/KDE_Localization/it
@tosky: i’ve been considering to enter translation team, i’ll try to step in then.
anyway the intent of my posting was not about translations, but usability.
For example, app style kcm > fine tuning > graphical effect. Very difficult to understand, so very difficult to tweak. Porting this option to Workspaces 2 (at least as it is) imho is a fail.
Or, from another perspective.. which cost/benefit has giving an option to disable windows snapping? Why in the world not using it? Resource hungry? Breaks your workflow?
Or disabling edge highlighting. Why? Detailed cosmetic pimping? Edit cfg files.
They are just amazingly useful features and they don’t get in the way of anyone’s day-to-day work, i would like to underline this.
The path followed in 4.11 by defaulting to a sane always-on window snapping glow effect is the right one, imho.
Can I point to you the next time we change a default in a way that makes more sense? Recently a user blamed me to be lazy because I said no to yet another config option.
yeah, i rad it on g+. well, since we have a mouth but we are not obliged to open it, we also have ears, but we may not open them too. i understand how opensource devs are in a quite stressing position. people that don’t respect others don’t deserve much respect too. a polite way of closing them is wont’tfixing bugs justifying that kde is a community, and that our software is built upon good will and that your work, first of all, deserve respect at minimum.
qt5 wants touch//non-touch workspaces,systemsettings,apps to serve the different goals of consumption//production devices.
(anyway i think that a single interface for plasmoids can do well in any workspace, for ex. new networkmanager applet)
now, while porting kcm modules that can also benefit of unprecedented ways of interaction thanks to qml, is the chance to change.
we can obtain a considerable operating margin by documenting tweakable hidden features in userbase wiki as the ultimate one-step guide for the more demanding users.
This is significantly more work than just porting. Porting a KCM is about half an hour work to get it to compile again. Then you are done. That’s nothing compared to have to actually do changes. I at least will not rework any KCMs as that’s significantly more work. It can be done, but it doesn’t need to be part of porting. At the moment our focus is just on porting the existing pieces to Qt 5.
Martin is right.
I for one use the 4 corners feature a lot.
Browser on left, terminal on the top-right and Kate on the top-left, and I’m ready to work(depends on what I am working)… That’s just one use case of mine.
i never thought about removing features (make exception if they cannot be maintained).
but, to me, just having a single sane (tested) default (5%? 7,7%?) would have avoided an (expert) option in systemsettings.
Hi Martin,
This “screen edge” feature is great but I don’t think it should be enabled by default.
Neophyte users don’t understand what triggered the desktop grid effect.
It hurts KDE because this behavior is disturbing.
It should be enabled by default only if the action is triggered on a mouse click event (not an hover event) and a popup should be displayed in the corner with a message such like “Click to trigger desktop grid effect”.
In any case, thank you for your great work on KWin !
I don’t know what you want to tell me, but Desktop Grid is not triggered through screen edge by default.
I am pretty sur this feature is enabled by default on kubuntu installs.
no, it isn’t 🙂 I know the source. Present Windows is enabled by default, but not Desktop Grid.
You are right, it is the present windows effect but it doesn’t change my opinion. Most people don’t understand why an action is triggered without any click.
Why not trigger the effect on a click event when cursor is on an edge ? (current behavior could be optional)
Why not display a message when cursor is on an edge in order to facilitate the discovery of the feature ?
The hot spots glow now, so there is some visual feedback.
Because a one-pixel click target is not clickable. And that’s why we introduced a high-light to illustrate that the corner is triggering the edge. Oh and activation through edge is available without click on all major platforms.
“And that’s why we introduced a high-light to illustrate that the corner is triggering the edge.”
It helps to discover the feature, yes. (but it doesn’t prevent unexpected triggering).
“Because a one-pixel click target is not clickable.”
“Oh and activation through edge is available without click on all major platforms.”
What do you call major platforms ?
I don’t remember that Windows 7 has this feature, except if you drag/drop a window (snap mode).
On Windows 8, there is a preview of the start screen when your cursor is hover the bottom left of the screen, and the start screen is triggered when you click on this preview, so it is technically possible:
http://cdn.ttgtmedia.com/ITKE/uploads/blogs.dir/79/files/2012/05/start8_1.png
Don’t misunderstand me, I don’t want a playskool start screen :D, I just want give ideas in order to improve ergonomy of current features.
On Windows 8 it triggers without click and when I tried to activate by clicking I completely failed because when you move the mouse over the the preview the preview hides again (very bad useability, just wanted to say).
Apart from that it’s present on Mac OS, GNOME Shell, Unity…
Nevermind about screen edges. The thing I always wanted is to activate desktop grid with a combination like _Meta_+Tab AND switch between virtual desktops with the same keyboard combination. Say like an “Alt+Tab” switch, but for virtual desktops. I was hoping this would be possible in KDE (see https://bugs.kde.org/show_bug.cgi?id=296069) but still there’s no option to do that.
There’s a TabBox mode which shows desktop previes just like Desktop Grid since 4.11
I’m sorry if I’m being stupid, but seriously I’ve been searching for that since the 4.11 stable release date and I don’t find such thing. Could you be so gentle to tell me where can I find it? Thanks!
It’s a rather hidden feature. You need to setup shortcuts for “Walk through Desktop List” or “Walk Through Desktops”. This will by default show a simple list, but no previews. At the moment I honestly don’t know which config value to change. But I have to do some work on this later today anyway and will add the information.
Lovely, thanks for your work.
With regards to dragging: it would be lovely to have a possibility to do the following: drag the window to the next/previous workspace by dragging it over the corner.
Now you might think this does exist: no, it drags it to the right/left workspace, which is meh if you have two rows of workspaces.
Now you might wonder why one has two rows, then: because the pager in the panel otherwise takes a lot of horizontal screen space.
It would be so nice to have an option to that, similar to the “wrap around” one, just not wrap around but rather just go to prev/next.
Kind regards,
Christian
I would suggest scripting
I appreciate that I can now finally reduce the “quarter-tiling triggered” area to a sensible amount around the corners.
But I wonder, why didn’t KWin simply use a smaller value by default?
If you start by dragging a maximized window by its title-bar, you should *not* have to drag it along a steep downwards slope in order to hit the area that allows you to half-tile it.
OTOH in the (btw much less common!) case that you do want to quarter-tile a window, you will be aiming for the corner, which is a very easy target to hit with the mouse (due to the two-dimensional side constraints) so no need to have a big portion of the screen sides dedicated to that (less common) use-case as well.
who says it’s a less common use-case? Did you ask all our users? If not, don’t put up such claims 🙂 The chosen size is based on symetry and math: 0.25 + 0.5 + 0.25.