SUMMARY KDE Plasma 5 has a Window Actions setting hidden in: KDE > System Settings > Window Management > Window Behavior > [Tab] Windows Actions > [Section] Inner Window, Titlebar & Frame > [Droplist] Modifier Key This setting by default is "Alt" and it breaks Krita's Alt modifier which is essential in many actions. It doesn't help that the setting itself being is difficult to find. Tested on Manjaro KDE 17.1.12, krita-4.2.0-pre-alpha-ea49ede-x86_64.appimage STEPS TO REPRODUCE 1. Use Krita under KDE Plasma 5 with its default settings. 2. Use Any of Krita's Selection Tools, make a selection 3. Then try press ALT and try to subtract from that existing selection OBSERVED RESULT Pressing ALT in Krita cause its window to move, while the expected Krita ALT modifier action (subtract from current selection in this case) cannot be triggered. EXPECTED RESULT Change this setting to Meta by default, so that it will never conflict with any graphics editor with this type of ALT interaction. SOFTWARE VERSIONS (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION
I understand there's a conflict, but kwin changing would break it for all kwin users. Openbox has alt+click to drag. GnomeShell I'm 90% sure does. So us changing won't really fix a wider problem. Shouldn't krita be the one changing?
Edit, gnome shell now doesn't.
I'm adding here a big +1 with @Tyson. Alt key belongs to the app, especially advanced app requiring more than shift and ctrl as modifiers (eg: Krita, Blender). Having the desktop environment (eg: Unity, Plasma) taking it in hostage to just 'move windows' by default was just wrong design from the beginning. I'm always switching it to Meta by default too, and it works way better because no apps touch to Meta key.
>and it works way better because no apps touch Meta key. That is not remotely true. https://lxr.kde.org/source/extragear/graphics/digikam/core/app/items/digikamimageview.cpp:428 I'm not breaking one app to fix another.
@David Edmundson: Sorry for my ignorance about Digikam using Meta key as a modifier. Thank you for pointing it with the sources. I understand the topic is really complex. The thread is marked as Resolved now and I accept the argument. So I'll keep advising to the Krita and Blender users under Plasma to manually go to the settings and change the behavior of the key manually. I advise that since years, so no big changes (eg. http://www.davidrevoy.com/data/images/blog/2013/01/mint14kde/10-thing-to-do-Alt-meta-KDE02.jpg , article http://www.davidrevoy.com/article155/linux-mint-14-kde-for-painters ). On a side note, I never thought of reporting this as a bug. I was happy to see @Tyson doing it today and had a glimpse of hope it could be changed for the long run :D But I understand the reasons it cannot and at least, this thread clarify now the situation.
I don't want this to turn into a who breaks whom, but let's face it. In this case KWin has been using Alt for this behavior much longer than Krita existed. Given the strong KDE reliance of Krita it's surprising that a shortcut was picked which obviously cannot work on a default KDE/Plasma session. If we would change Alt to Meta or something else we would just start to break other applications. Alt is the key belonging to the window manager as we can see with shortcuts as Alt+Tab. It's extremely difficult to use any shortcuts for a window manager. We used to have Ctrl+tab for switching desktops and then Firefox took it for switching tabs. If we please everyone we end up with a useless desktop. I'm open to ideas how Krita could indicate to KWin that they need the Alt key now, which would be a way better solution than changing the default. E.g. a property containing a region in which alt should be ignored. Due to technical difficulties that could only be added on Wayland, though.
Just to share my perspective here: # ALT for Add/Subtract is the industry standard that came much earlier than Krita Every graphics editor I know has been using ALT for the same "Add/Subtract from selection" since the dawn of computer graphics. Photoshop does the same and it is the defacto standard across graphic editors. I'm sure PS came much earlier than Krita and many other things. # ALT is essential for graphics editors in general Almost every digital artist is going to use this action on a daily basis. It was actually not Krita but the vector graphics editors like Inkscape are hit the hardest, since they can't do much without those modifiers. I wonder whether Digikam used Meta to avoid this conflict in the first place. # My past experience and confusion By keeping ALT occupied by window actions which most people have little use or even know they exist, we are keeping many digital art/graphics artists away from KDE Plasma, namely the normal Krita/GIMP/Inkscape/Blender users. It was one of the primary reasons every time I gave up using KDE Plasma in the past -- my main tools are missing features! But they are doing fine on other platforms! I could not find where the option is since it is hidden so deep in a jungle of cryptic names, so the logical decision I made every time was went back to Gnome/Windows. # Why I gave it another shot this time The only reason I finally figured it out was because I'm so embarrassed by being asked "you have designed the mascots for KDE, Krita and Kate, but why aren't you using KDE Plasma?", time after time. So I searched through every system settings page, flipping every possible switches like a hunter -- I don't want my decision of using other DEs make KDE Plasma look bad. I'm not sure other artists can be this persistent. It was not easy to type in the correct keywords in Google to get the proper workaround. You don't expect normal artists to have the know-hows like David Revoy. I have been very familiar with computing yet I still had trouble. # My suggestion I think it makes more sense to reserve the Meta key to Window Manager and let all application to use Ctrl and Alt, those not using Alt already can adapt, because I'm not sure whether their usage of Meta/Alt key is as essential as in this case. By unifying the modifier usage we can provide a more streamlined user experience. If nothing, at least organize the KDE settings so they are easier to understand and find. Gnome-tweaks/gnome-tweak-tool handles the same setting much better.
We cannot change such a default for one app. Sorry. It breaks tons of documentation and will break other software assuming meta is free. If you insist on changing it would mean you consider Krita's need as more important than those applications it would break. The only sensible thing is to come up with a protocol to hint the window manager which modifier it should not use right now. Everything else is not fixing the root problem. Changing the default won't fix anything. If you want a short term solution and a discoverable solution detect that KWin is running and offer the user to change the setting. Either by providing own GUI for it or just starting the correct kcm.
I don't expect things can be fixed now, since the decision has been made. I'm sorry but I think the solutions you mentioned seem to be way too far-fetched. I want to be honest here and make sure you understand my point: Yes, I AM putting Krita/GIMP/Inkscape/Blender's need above other applications. And for good reasons. I think you need to weight how important ALT is to Krita/GIMP/Inkscape/Blender, how important these applications are, then how important META is to those other applications you mentioned, and how important those applications are. Can we draw digital art or make graphics design under Linux without Krita/GIMP/Inkscape/Blender? I don't think so. Can these applications work without ALT? Some can't, some can but not without huge function/efficiency loss. And if we don't solve this, we'll lose digital artists as our KDE Plasma users and as allies. And digital artists has considerable influence over their followers. I don't know those META using applications you were talking about, and I don't know which function they are assigning to META. So can somebody educate me about them, like how important these applications are, and how important the META key is to them? I'm sure you don't want to break Photoshop under Windows just because a particular image viewer is using PS's keys for a minor function! A seemingly "fair" decision does not necessarily lead to good user experience. On top of that, my concern being: are we making the decision AFTER discussion and investigation have been made, or have we jumped into conclusion in less than one day, assuming the status quo to be the ideal solution just because it's easier one to make?
Also I would like to suggest we ask the developers of those META key using KDE applications this question: Why did they ended up with META of all things for their shortcuts in the first place? Was META their first choice? Or was META chosen just because kwin took ALT away.
>Or was META chosen just because kwin took ALT away. Kwin and openbox and older gnome and compiz and... Choosing a key that isn't already taken seems like a /very/ sensible thing to do. Why isn't krita changing?
> Why isn't krita changing? @David Edmundson : It is a standard adopted since decades by many apps and compatible MacOS and Windows. All the software I ever used in 20 years of career use combination of Shift, Ctrl or Alt to access modifier variation of tools. To quote a few: Indesign, QuarkXpress, Illustrator, Photoshop, PaintToolSai, ClipPaintStudio, Corel Draw, Corel Painter, GIMP, Inkscape, Blender, 3DStudioMax, Maya, etc..etc.. (and probably most of the professional application, including video editors). Alt is just not a key for the D.E. to move windows around. > "And if we don't solve this, we'll lose digital artists as our KDE Plasma users and as allies." @Tyson: In my point of view; the big part already left around 2014. I felt it on my blog with the feedback I had (I was a big Plasma4 advocate between 2011 to 2014 and had audience for that on my blog). They left at transition to Plasma5. Plasma5 was quickly adopted by distro and shipped without the digital art features. They were not part of the core things ported to Qt5. So, for the artists, the switch was too violent from something like Mint KDE 14 with Plasma4 with color management and tablet GUI out of the box and already installed by default (ref: http://www.davidrevoy.com/article155/linux-mint-14-kde-for-painters) beginner friendly to the new Plasma, unstable and without this features (unless creating bash script for xsetwacom manually, calibrate tablet with xinputcalibrator,colormanagement with ArgylCMS and obscure command line and flags - but this type of user are *rare* and can use their own Windows Manager and build their own distro). User base of artists I knew at this time exploded to other D.E. learning the hard way to adapt; and a part switched back to Windows defintely. For my own experience, I made a random path into XFCE/Mate/Unity/Awesome/GNOME/Cinnamon sometime experiencing night of work and research to get my workstation working. I'm only back to Plasma since 8 month or so. Nowaday, the tablet GUI is slowly getting back to maintenance on Plasma5 thanks to the work of @Valeriy Malov (I'm building it, my distro -Kubuntu- doesn't pack a version that works). But it will take time until https://github.com/oyranos-cms/oyranos color management system can be back with the tablet as built-in solution, packaged and working... Let just face it: we, artist/designers, are probably just a too minor target audience (something I learned after 10 years of GNU/Linux distros, breaking all what I advocated years after years on my blog and turned my involvement into a "this-guy-must-be-idealist-or-crazy-to-keep-using-that"...). So, I'm not really surprised if things doesn't change on this topic and that's why I gave up quickly on this discussion. But I appreciate your tenacity @Tyson and I fully support what you said. On my side, I'll probably change the tone of my blog posts and teach to digital artists this vision I experienced; the hard way" the command line tools, the settings to customize, the obscure flags... I don't expect anymore an out-of-the-box positive experience.
@David Reevoy: Thank you for all the explanation. Now I can rest in peace -- knowing there has been a history of intricacies behind all these and they all contributed to the status quo. I'm relatively new to this realm -- "only" 7 years (...wait what? what the heck it has been already 7 years? and it still gives me so much pain!? arghhh) I can't imagine what you have been through all these years. I'm still a little bit hot-headed when it comes to these seemingly obvious issues. Partly because I've just switched to Plasma for less than a season and all its problems are currently frying me inside-out. Without your dedication and others' I'm sure this KDE Plasma journey of mine would have been ended months ago. Thank you for looking out for us. And just like you but only 17 years for me being part-time IT support/administrator, I can say I have put my hands on all sorts of strange software creations imaginable, yet never once had I encountered this many problems like I had on KDE Plasma. If I have to name one, Ctrl/Shift/Alt/Meta being arranged differently than any other existing major OS/DE is absolutely going top them all. I was laughing in tears when I read "this-guy-must-be-idealist-or-crazy-to-keep-using-that" -- that's also exactly what other people see me these days. My involvement is so much shallower than you because I'm merely a power user for the most part, but I'm sure my suffering is just comical in normal people's eyes. I wonder if I'm actually scaring them off from Free and Open Source Software/GNU/Linux -- all those "voodoo blood-sacrifice" moments and "enigmatic spells from another dimension" needed to make my stuff barely working -- great materials for a comic if you ask me! But to be honest I wish we can offer people good out-of-the-box impression instead of "treasure hunts" and "goose chases" like this. Well, so much for pushing changes and time to coupe and workaround, I guess. You are right, I should have realized there are many more normal users than artists. Most of them don't care or even feel comfortable with the status quo. I might have the illusion of artist being a common place because I'm surrounded by fellow artists. In reality though, it is always us artists who are making all the compromises. :P @ Everyone: If I sounded overly passionate/aggressive in the last comments, you have my sincere apology.
To make it quite clear: I'm totally open to improve the situation. I'm not open to change the default shortcut. As I said: changing the default shortcut doesn't fix the problem. It just shifts it somewhere else. Yes, it's the easy fix. But I don't like easy fixes. Those are mostly wrong and do more harm than good. What I like is analyze the situation and improve. What Krita needs is the possibility to tell the window manager which modifier+mouse shortcut it needs and the window manager should honor it. That is an important feature and very important in the light of Wayland where KWin supports modifier+mouse shortcuts in general and not just the alt+lmb as currently. We can work on making an universal solution which suits both Krita and KWin and many more applications. It needs that we stick our heads together and think about how this can be done. And yes that would require Krita to also add code. Nevertheless what I proposed as a short term solution is sane and can be easily done: just check whether the window manager is KWin (dbus service org.kde.KWin) open kwinrc, read the correct value and pop up a dialog "hey your window manger uses alt to move the window. This breaks our foo feature. Do you want to change it to windows key?" On yes, change the kconfig emit the dbus call for kwin to reload the config and call it a day. That are less than 100 lines of code and can be written in less than half an hour. And the mechanism is totally fine, that's just how kwin's config works.
There are things I would like to clarify: 1) THIS IS NOT FOR KRITA I reported this bug, not because we are trying to push change for Krita's sake. I and David Revoy here are sharing the common sense of how Modifier keys operates on OS/DE in general. Our sincere intention here is to help you to improve the user experience for KDE Plasma. 2) THE COMMON SENSE We consider this to be a problem on kwin's side. Because what kwin has been doing is NOT COMMON SENSE. The COMMON SENSE and INDUSTRY STANDARD, as David Revoy mentioned: Ctrl/Shift/Alt should be reserved only for applications. This has been implemented since the dawn of of GUI and kwin is the one at odd here. kwin's taking away of the ALT key for window action goes against everything we have been using with a GUI. Only Plasma is doing it differently, and this is not what a sane people expect from a good desktop experience. 3) WHY SHOULDN'T KRITA CHANGE, BUT KWIN kwin's reservation of ALT for window actions is hitting every application outside of KDE, and not limited to applications outside of KDE. Those being hit are those adopted the INDUSTRIAL STANDARD and COMMON-SENSE. The more powerful they are, the harder they are hit. The applications we used for examples include Krita, GIMP, Inkscape, Blender. These are the NAMECARDS of the whole FOSS world. It delivers a clear message when they ONLY have problems under KDE Plasma, and the said problems CRIPPLES their CORE functionalities. If Krita should be the one to change, then EVERY application that adopt to this COMMON SENSE, this industry standard of modifier key arrangement should add rules specifically made for kwin. kwin is a special case in the grand scheme of things, not Krita, not GIMP/Inkscape/Blender/etc. And as a result, Krita shouldn't change, neither should GIMP, Inkscape nor Blener, etc. 4) THE SHORTTERM SOLUTION YOU PROPOSED I understand your proposal. I'm not a programmer so I don't know even what you mentioned is doable. But for now, let's assume it can be implemented. Then what? You have quieted one loudest scream that's closest to you. But what about everything else? Is this shortterm solution (implemented by Krita, although it is really a kwin issue) going to give you a false sense of security? What about those disgruntled users who can't reach you because they don't know what and where to report? While the status quo goes on, I wonder why people are so reluctant to adopt KDE Plasma as their daily DE. Missing ALT for whatever productivity applications they are using must be one of them. 5) WE CARE ABOUT KDE When a certain application has KDE Plasma specific compatibility issues like this, and by any luck it was reported to those projects as a bug, they will be for certain marked as UPSTREAM or NOT-OUR-BUG. Those information are rarely being relayed to you. We care because we are involved in KDE and we don't want to stand there watching it goes down a path that turns people away. 6) JUST DROP WINDOW ACTION SHORTCUTS BY DEFAULT Why do we even need to use ALT as a shortcut to move our window? Is it this important? Can't we just click on the titlebar and drag it around? It doesn't make any sense! My shortterm solution is to add a NONE option to window action and make it as default. 7) THE RESPONSIBLE SETTINGS ARE TOO HARD TO FIND The option to turn it off is hidden way too deep and hard to find, causing the learning curve to be insanely steep. If anything, at least change how the options are presented. Most people could not figure out how to change kwin's ALT to META, or in fact, figure out what is happening at all. So what do they do? They go back to the last other OS/DE they use and they will be more reluctant to try KDE Plasma for another time. I have been retrying KDE every year, only ending in retreat, only because I am involved in KDE community. Normal people would leave for good after their first or second disappointment. 8) IN THE END This discussion is for kwin and thus for KDE Plasma. This is not for Krita. We are not trying to make Krita works better under KDE Plasma. We are trying to help KDE Plasma works better for the majority of applications. I'm not saying you MUST do what I suggested here, but I do believe I and David Revoy have shared valuable information. We explained the context, history, and our perspective circling this problem. I hope you have read and digested our words carefully and thoroughly. I do hope in the coming years of maintaining kwin, our shared knowledge can help you make your decision wisely.
Guys, I don't care about industry standards. I can show 10 different industry standards. The only thing you present here is "my industry standard is more important than all other users". That's not a position from where we can start. It's not about who got the shortcut first or for whom it is more important. It's about how can we both use it. The behavior in KWin is also an industry standard- an X11 Standard, an Unix Standard. David already mentioned openbox, I throw in fluxbox (http://fluxbox.org/help/man-fluxbox.php) as an example for an even older window manager. Also Compiz (http://wiki.compiz.org/CommonKeyboardShortcuts) uses it and has also a shortcut for meta+lmb defined. The thing is: we are both right, it is our industry standard and we have both the right and the need for it. Asking you to change won't work, asking us to change won't work. So can we please stop the absolute position about KWin being wrong and has to change? Good, thank you! We are not going to worsen the user experience for the needs of a subgroup of users. You are not the only group of users demanding that their field is more important than all others. We cannot suite all and still have a good product. The problem is not that we use Alt. The problem is that modifier clicks can not be taken by the application. We can work on that but it'll require Krita to change code. If you are not willing to adapt Krita than we can stop the discussion.
I just did some research: the first window manager (twm) already uses the pattern of modifier+click to move a window (see for example: https://www.oreilly.com/library/view/x-window-system/9780937175149/Chapter03.html#ch3-06 ). According to it's documentation it uses the meta modifier. I'm not sure what is really meant by this as today's keyboards don't have a meta key. The best I found is: https://en.m.wikipedia.org/wiki/Meta_key Most likely that transferred to alt as keyboards in the beginning 90ies neither had a meta nor a Windows key. In old X speak windows is not the meta key, but super or hyper. I did this research out of personal interest as I didn't know why KWin has that binding. Now we see it is as old as X11 window managers which means it predates the digital painting industry.
If you have to put this this way, then just let us know about your priority -- who are your target users? A) The old time programmers (less than 1%) B) The majority of normal people who have been trained over 20 years with modern UI design (more than 99%) In the end of the day it is really your decision to make. If you make the decision to stay behind and to serve a niche position, that's totally fine! But just let us know about your philosophy, so that we as users can decide and act accordingly. It pains me to say this, but nowadays an overwhelmingly larger portion (99%) of human population is using either Windows, macOS or something similar. The world has already moved on 20 years ago, which is the core point we have been trying so hard to make across here. Yes you may defend kwin's status quo by asserting X11 standard to be a standard that came before anyone else. But that standard is not the other 99% of people are following. If KDE Plasma set its goal as a multi-purpose desktop environment, it only makes sense for kwin to change to help it achieve its goal. But if you decide otherwise, again, it's really your decision to make and it's totally fine. Just let use know about it.
Stupid question: is mouse at all relevant for Krita or is only (Wacom) pen relevant? KWin only grabs alt+mouse and doesn't care for pen. It's only taken as X maps it to mouse. But if pen is relevant all you need to do is to grab the xinput2 device for the pen. Afaik Krita uses low level xinput2 anyway so adding the grab should be easily doable and that should prevent KWin from getting the shortcut.
Fwiw I just merged a patch doing that in breeze qstyle in the drag from empty areas based on a comments bound made in the other thread.,,,,
(In reply to Tyson Tan from comment #18) > Just let use know about it. My priority? Improving the product and the ecosystem. But to be clear: my opinion doesn't matter any more. I stepped down as maintainer. I give my feedback as an expert in the area and I have strong opinions about features that matter to me. So why are I against just changing the default and living in the Windows future? Because it doesn't fix the problem. It doesn't make Krita work with any window manager using this shortcut. It even doesn't fix it for Plasma. It would mean two years till this gets to users (Ubuntu 20.04) and would only affect new installations. Existing users would not be migrated anyway - we never do that. And even then for any user re-enabling the feature and any distribution re-enabling the feature (especially for such hardcore X11 features that does happen) it would still be broken in Krita. The only way to get this fixed in Plasma is by removing the feature overall. And there I have to disappoint you: this feature is too useful to get dropped. It would create a major shitstorm if we would drop it and we would deserve this shitstorm. If you look around this feature is very often reported as the most missing feature in Windows. Furthermore we are at the edge to Wayland and that changes everything. Also how this feature works. This gives us the chance to improve it in ways that make it work for everyone. I already asked about the pen. On Wayland that would be the default: alt + mouse is the only way to trigger the feature. Other input devices such as touch and pen are ignored (granted we don't have pen support yet). Furthermore applications can temporarily confine the mouse pointer which would be a useful feature to use by Krita and there we can think about to ignore the modifier mouse actions (I just tested and we don't do that yet, but that's something we should change). So lets work on improving the situation and stop thinking in black and white where the feature exists or doesn't exist. We can improve and we can help you as well. You just need to ask. Just look how fast David fixed the breeze issue after it was brought to us. This is something I noticed with Krita very often. Complaints after years that things have not been working as expected, but it was never brought to us (sometimes code was forked or features of Plasma hard disabled without talking to us at all). If you need help with X11 we can help. Heck my notebook has wacom support and I bought it with the thought of being able to test Krita and help getting it to Wayland.
And I just implemented the mentioned change for Wayland (https://phabricator.kde.org/D15982 ) which btw. is my first code contribution since about half a year or so.
Git commit cefc15e573d28b27d75040d9d58323e933a4c839 by Martin Flöser. Committed on 06/10/2018 at 16:05. Pushed by graesslin into branch 'master'. Ignore modifier mouse actions when the pointer is constrained Summary: If the pointer is constrained all mouse events should go to the window. Also our Alt+click. To use Alt+click nevertheless one can just unconfine the window. Test Plan: Run the adjusted autotest before and after change Reviewers: #kwin, #plasma Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D15982 M +21 -0 autotests/integration/pointer_constraints_test.cpp M +16 -14 input.cpp https://commits.kde.org/kwin/cefc15e573d28b27d75040d9d58323e933a4c839
@Tyson: I keep supporting all your point-of-view and argument in this discussion ( ‘-’)人(ﾟ_ﾟ ) I also appreciate the feedback and time spent by David and Martin here and what Martin proposes. I read a lot of interesting things but I don't think Krita or any other apps should contain patch to be compatible running on Kwin/Muffin/Mutter/Metacity/Xfwm/etc. Maybe the switch to Wayland is a good opportunity to change the default? I'm fine waiting for Kubuntu 20.04. Another idea, why not creating a poll? ------------------------------ Do you use Alt key on Plasma? ☐ I use it to move my windows. ☐ I change the default setting, I need the Alt key for my software. ☐ I don't use it. ------------------------------ ...could help, maybe. [Also, I abuse a bit of an off-topic here to thank you David and Martin for your work around the Plasma desktop (I like the detailed post you write about the display scaling, Wayland, Kwin, etc... They are often linked on r/linux/ and also on other KDE feed I'm following). 👍 ]
We don't need polls: that feature is extremely popular. Example: https://www.reddit.com/r/kde/comments/9ldyhs/altleftclickdrag_to_move_windows/ https://www.reddit.com/r/kde/comments/9b9rts/daily_tip_you_can_drag_windows_by_holding_alt_and/ It's even ported to Windows referencing the Linux behavior: https://stefansundin.github.io/altdrag/ And btw. I doubt you really understand that feature. It's not just that you can move the window. It allows to move the window unrestricted. It ignores constraints from other windows, it ignores states. It allows to move fullscreen windows, it allows to move frozen windows. If I would have to rank KWin's feature it would be in the top 5 maybe. Removing won't happen.
I just looked at our code and what could be done in both Krita and KWin. In case you are only interested in Alt+pen KWin could be changed to use Xinput2 and only grab the pointer leaving pen using unchanged. See (https://linux.die.net/man/3/xigrabbutton ). This would mean that we would have to significantly touch our feature frozen X11 code base and risk breakage. Nevertheless I would say we could do an exception here. In case you are also need alt+mouse click this could in fact be done by Krita itself without touching KWin or any other window manager. All you need to do is perform the same passive grab as KWin does, but you need to be faster than KWin. E.g. directly after creating the window you could perform the grab and that would prevent KWin from ever being able to use Alt+mouse. Relevant API call is ftp://www.x.org/pub/X11R7.7/doc/man/man3/xcb_grab_button.3.xhtml
@Martin: The awesomeness of the feature (I don't doubt about it) or the Reddit mini featuring of the Alt key with 85 upvotes are not really valid arguments; especially when three comments in the same Reddit say they need to change this shortcut to Meta and the thread is followed only by the Plasma audience (r/kde...). I'm interested by the users who never adopted Plasma or who left it after a first try. They probably don't subscribe to this Reddit. By the way, an interesting feedback on it is from a gamer; saying Alt is required by games. Maybe the low presence of gamers and artists on GNU/Linux is also a consequences of default like that? Imagine if the operating system was designed by artists, and they would replace all the [ and ] keys by action to change brush-size system wide. "How awesome! painting on every windows and being able to change brush size!"... Of course, you could change it in the settings (assuming you are looking to change a keyboard shortcut in the less logical place for it; Windows Management>Windows behavior>Windows Actions(tabs). This ensure you need a guide and a documentation to be able to even know you can customize it). I'm sure such a default behavior would just ruins the adoption for the developers audience because devs need this keys to write code and would think this is not well thought or suited for their use. This is -of course- a humoristic reversed caricature I use to illustrate this situation with the Alt key. And again, patching Krita, or doing a specific tablet+Alt action doesn't solve the issue. It even adds less consistency and more workaround to the D.E. Alt+Mouse-click getting another behavior than Alt+Tablet-stylus-tip-click?... Well, I work with both. I don't expect they work differently and if a D.E. force me to that I would probably consider it broken and not consistent. Assuming artist use only the tablets is like imagining gamers control their PC with only joypads ;-P All in all, maybe the best way to smooth the rough edges of this Alt issue without changing the default (because I see it will be impossible) is push efforts on a cleaner and more user-friendly "System Settings" on Plasma. I would expect to setup something as important as that option on first page of the "Shortcuts" settings... But when I open it, the first thing proposed is "Standards Shortcuts" and the possibility to add shortcut for popping the windows "About Application" and "About KDE" on the top... Not really relevant xD. You can browse all the content of Shortcuts... It's long. Not finding it and then you need to search online for specific documentation to find Windows Management>Windows behavior>Windows Actions(tabs). Maybe a topic for opening another issue? What do you think about it?
Removing features won't brong us artists or gamers to linux. Gnome tried and what did they earn: a bad reputation. But no new users. No windows user will go "finally that feature is gone now I'm going to use linux". I wanted to know whether just stylus would be sufficient, given your reply I assume not. So doing that change in KWin is probably not needed. So let's look into how we can disable the feature from within Krita.
Created attachment 115467 [details] GNOME Window Action Key Setting This is how GNOME handles the Window Action Key settings, using gnome-tweak-tool which is preinstalled in almost every distro. Notice how it straight forward it is compared to KDE Plasma's. I probably wouldn't report this bug if the same setting in KDE Plasma isn't so impossible to find.
@Martin: I never proposed to remove the feature. The proposition is to change the Alt default shortcut for this feature and move it to the Meta key, or ease the way to discover how to setup it. Again, making a specific rules for Krita on Kwin doesn't fix the situation.
Now please let me share a story about how Microsoft handles a similar situation: As you all know, a keyboard has only western letters on it. So how do the non-western language speakers input their native languages? They use applets called the Input Methods (IME) under Windows. At first, (Windows 95/97/2000/XP/7) Microsoft used these hotkeys to handle the IME related businesses: [Ctrl+Shift] Toggle IME > Next IME of the same language [Alt+Shift] Next language At that time, however, the Ctrl/Shift/Alt hotkey scheme has already become a norm across almost every professional applications out there. This arrangement understandably caused huge problem. For example, in Photoshop, you need to press both the modifiers and letters all the time for shortcuts. But when a combination of [Ctrl+Shift] or [Alt+Shift] is pressed, it not only rendered that PS's shortcuts useless, but also toggle the IME, so now the letter only shortcuts wouldn't work either. The workaround at that time was to turn off IME shortcuts completely and use mouse clicks to switch. It was a huge trade-off and grief impact of productivity. It was understandable because Asian market at that time was an after-thought for Microsoft so the sloppy IME shortcuts was probably a dirty patch-on. Now you may say, this problem mainly affects only the East-Asians who use professional applications, a very small portion of their user. Those user should ask their applications to change, not Windows itself. But Microsft changed it. Starting from Windows 8, this is how they do the same thing: [Win+Space] Toggle IME > Switch between IMEs. IMEs of different languages are now grouped together, so there is no need to switch between languages anymore. The moral of the story: 1) Even something as large as Microsoft can change; 2) They changed from [Ctrl/Shift/Alt] to [Super/Meta]; 3) They changed an old way they had been used for more than a decade; 4) They changed for a very specific minority, the professional users from roughly only 3 countries; 5) When a hotkey is being used for work, for operating a tool for a professional, without which the work can't be done, it has the right to be respected; P.S. Do you remember the sorts of BlackBerry? Their physical keyboards on their smartphone surely was the standard of the past when the smartphone market was so small compared to today's. And sure, physical keyboards have their advantages. Now, remember how they reacted when iPhone was released? And where are those companies now? Beware of living in an echo-chamber, where only similar voice of yours can be heard. That's said, my words doesn't matter if you are perfectly comfortable with living in an extremely narrow niche.
We did not ask you to remove Window Action Key. I was only arguing its usefulness, and it wasn't even the point of that comment. You are focusing on the wrong place. Let me rephrase what we really asked you to consider: 1) Change Window Action Key default to Super/Meta; 2) Cleanup Window Action Key settings so people can actually find it easily; 3) Add a "None" option, so the Meta app and Alt app can co-exist under Plasma; 4) Never ask the applications to change, they are following the 99%; 5) Listen to different voices outside of your echo-chamber; 6) Make it clear: who the target users are for Plasma.
(In reply to Tyson Tan from comment #32) > We did not ask you to remove Window Action Key. I was only arguing its > usefulness, and it wasn't even the point of that comment. You are focusing > on the wrong place. > > Let me rephrase what we really asked you to consider: > > 1) Change Window Action Key default to Super/Meta; From comment 21: So why are I against just changing the default and living in the Windows future? Because it doesn't fix the problem. It doesn't make Krita work with any window manager using this shortcut. It even doesn't fix it for Plasma. It would mean two years till this gets to users (Ubuntu 20.04) and would only affect new installations. Existing users would not be migrated anyway - we never do that. And even then for any user re-enabling the feature and any distribution re-enabling the feature (especially for such hardcore X11 features that does happen) it would still be broken in Krita. > > 2) Cleanup Window Action Key settings so people can actually find it easily; There is an ongoing project to rework all of systemsettings. I'm not involved in that project. Please provide the feedback there. > > 3) Add a "None" option, so the Meta app and Alt app can co-exist under > Plasma; exists already. > > 4) Never ask the applications to change, they are following the 99%; I haven't done so. I only suggested that we work together to improve the situation. And that requires both Krita and KWin to add code. > > 5) Listen to different voices outside of your echo-chamber; says the one talking about industry standards ;-) I'm not living in an echo-chamber, I'm too smart for that. I give you one feedback to think about: one of the most often requested features in KWin is the lack of mouse actions. Especially the features Compiz supported was extremely popular and we got many complaints about us lacking it. Due to that it was one of the first new features I implemented on Wayland. In opposite this is the first time in 10 years that someone complains about the only existing mouse shortcut we have. Something to think about especially when claiming we would live in an echo chamber. Something else to think about: I no zero Krita users outside of KDE community, I know dozens of KWin users outside of KDE community and not just coders. They all know that feature... > > 6) Make it clear: who the target users are for Plasma. see: https://community.kde.org/Plasma/Workspace_Sprint/Personas though I don't know whether these personas were ever officially adopted.
1) Change Window Action Key default to Super/Meta; What you are asking us to _break_ the workflow of all of users. Most of whom are currently unaffected. That is not going to happen during 5x and is not remotely up for discussion. (only consolation point, when we do get Plasma telemetrics, I might make this one of the things tracked) 2) Cleanup Window Action Key settings so people can actually find it easily; System setting rewrites are a constant WIP, typically 1-2 every release. This will include kwin window actions at some point. I'll see what we can do. Maybe it belongs exposing in the kglobalaccel UI - even if we have to sideload it. 3) Add a "None" option, so the Meta app and Alt app can co-exist under Plasma; We can do that. 4) Never ask the applications to change, they are following the 99%; That's pretty rich, given that's exactly what you're asking. The only reason krita can't change their default under Plasma is familiarity which is the state for all our non-krita using kwin users. 5) Listen to different voices outside of your echo-chamber; And you need to do the same. 6) Make it clear: who the target users are for Plasma. Existing users of Plasma come first. We should press for option 7 7) Explore solutions that work for both of us, that is not being remotely reciprocated. This is trying my patience. If there is one more wall of text that isn't in the spirit of collaboration I will set this bug to closed.
Ok, I might move to System Settings discussions. I was not convinced by any arguments here except the protection of Plasma KDE userbase against change. This is strong and valid, I can understand if it is the philosophy of the project and I'm fine to move-on with this explanation. (Protecting Digikam userbase using Meta key was also a valid argument). On a personal notes, I was just disappointed to read the thread constantly reducing the issue to a Krita issue and the will to see in me and Tyson two users who tries to advocate something to Windowify Plasma. We are friendly GNU/Linux advocate since 7year for Tyson and 10y for me, we are not attacking Plasma or Kwin. We are both Plasma users -right now- and just wanted to improve a paper-cut we had. To conclude, love and Friendship (>'o’)> ♥; keep the hardwork you do on Kwin and thanks for your time!
@DavidR: if we find a solution which works for Krita, it's a solution all applications in this field can use. We can use Krita to experiment and easily modify for improvements.
Another idea: KWin has a feature for disabling global shortcuts. This also disables alt+mouse (see events.cpp line 871). This feature is currently only available through window rules and is a little bit too strong. What we could do: * Introduce a new feature disable mouse shortcuts * Either add a default rule to KWin to set this up for Krita * or add an X property to Krita to hint that global mouse shortcuts should be disabled This would be only X11. Wayland has the pointer confinement feature which already covers the use case since my change yesterday.
@Martin >> System Settings >> Workspace (section) >> Window Management >> * Left Column * >> Window Behavior >> * Tab * Window Actions >> Innter Window, Titlebar & Frame >> Modifier key >> * droplist* The droplist has no "Disable" option. So whether Meta or Alt is selected here, Meta/Alt + Arrow keys will still function as Window Action shortcuts. So there is no way Meta and Alt apps can coexist with our current design.
@Everybody Recently I've been asking around the programmers from a few very active groups I'm in. Their feedbacks are: 1) Yes we are using Window Action key all the time! (and yes, I'm sorry about doubting its usefulness) 2) I'm using ALT for my Window Action key. (he quickly added: But that does not represent the common choice in my workplace) 3) I'm a heavy KDE user. The first thing I do after installing the system is always changing the Window Action key from ALT to META. 4) Changing Window Action key is very easy for me to do. Why don't you change it? >> System Settings >> Workspace (section) >> Window Management >> * Left Column * >> Window Behavior >> * Tab * Window Actions >> Innter Window, Titlebar & Frame >> Modifier key >> * droplist* >> Meta (not I would call easy for normal people) 5) I think a Window Manager should not occupy ALT. A WM should use SUPER/META. That's just common sense. 6) I think modern OS/DE should strife towards practicality. 7) Kwin should release any key when an application requires it. ------------------------ So that's as far as I can go. As programmers their opinions are stilling falling on both sides. But I think that's compelling enough for me to agree that we can let Kwin stay the same as a measure to securing its current userbase. From now on I will not push changes or argue with you about this matter. I think writing a guide for normal people to adapt to KDE Plasma seems to be a better solution. When your proposed solution on Kwin's code is done, We can try to pass your proposal to Krita developers. Please remember: Me and David Revoy are not Krita developers, we are only users with heavier-than-usual involvements. I don't think we can fully understand the technicality you mentioned here. I may try to let other non-KDE projects like GIMP/Inkscape/Blender know about it, hopefully they might consider adapting to kwin too.
(In reply to Tyson Tan from comment #38) > @Martin > >> System Settings >> Workspace (section) >> Window Management >> * Left Column * >> Window Behavior >> * Tab * Window Actions >> Innter Window, Titlebar & Frame >> Modifier key >> * droplist* > > The droplist has no "Disable" option. Of course it has - just select none as action.
I'll just chime in with some use cases of alt+drag in my own experience: - A long time ago, I tried running Lunar Magic under Wine. Lunar Magic uses alt+drag to move objects around. But my DE reserved "alt+drag" to move the window. - In Firefox, alt+drag allows you to select part of a hyperlink instead of visiting that link. Since I use this from time to time, I rebind window movement to Super+Drag so it doesn't interfere with this. - In Chrome, alt+drag pretends to let you select part of a hyperlink... and as soon as you let go, it saves the link target. Partly related: Many code editors/IDEs, like Jetbrains and Visual Studio Code, have shortcuts involving F1-F12 with modifiers (other than Super). I know Xfce broke some, but I forgot if KDE did (I think alt+shift+f12 broke something, but I forgot what). And I know that Ctrl+Alt+F1 is reserved for "go to TTY1". My personal opinion is that the DE should reserve any shortcut involving the Windows key (super or meta), and ignore any shortcut not involving that key. So I dislike when WMs (like KDE) reserve shortcuts not involve Super, and dislike when applications (like ConEmu on Windows) bind shortcuts involving Super. I haven't used digiKam much, but I think it shouldn't use Super either. In my experience using Linux so far, I've never used Super in any application-level keyboard shortcut.
As of today, digiKam uses Qt::MetaModifier twice. I've attached two links that should point to to the latest commit as of today, and won't break with future commits when master moves their files around: https://invent.kde.org/kde/digikam/-/blob/b29f5dfeeac3e4f4667d47998fcfedd2766738f7/core/app/items/views/digikamitemview.cpp#L439 https://invent.kde.org/kde/digikam/-/blob/b29f5dfeeac3e4f4667d47998fcfedd2766738f7/core/app/views/tableview/tableview.cpp#L186
> I haven't used digiKam much, but I think it shouldn't use Super either. Yes, as far as I know, Super is reserved for DE so applications should use something else, e.g. Alt.
>Yes, as far as I know, Super is reserved for DE And as far as I know this is not something defined. I would be happy to be proved wrong. I would also fully support someone fixing this and defining an XDG standard. Even one that means changing kwin. See also T11520
(In reply to David Edmundson from comment #44) > I would also fully support someone fixing this and defining an XDG standard. Fair enough.
Git commit f474686a584a0f3049b3eddb8b148d3703a7148a by Noah Davis. Committed on 23/05/2020 at 02:39. Pushed by ndavis into branch 'master'. Change CommandAllKey to Meta Summary: Alt + Left Click to move windows has a tendency to conflict with creative workflow apps. While Alt can be changed to Meta in KWin's settings, Alt + Left Click shortcuts often cannot be customized in apps. Rather than making every user who runs into this problem change their settings, we should change our default settings to improve KWin's default usability. The fact that Alt + Left Click to move windows is older does not matter. We are trying to use Meta for global/shell shortcuts anyway. Test Plan: The relevant parts of the relevant tests pass. kwin-testInternalWindow fails, but for unrelated reasons that have something to do with XWayland. M +7 -7 autotests/integration/internal_window.cpp M +2 -2 autotests/integration/pointer_constraints_test.cpp M +15 -15 autotests/integration/pointer_input.cpp M +1 -1 doc/windowbehaviour/index.docbook M +2 -2 kcmkwin/kwinoptions/actions.ui M +2 -2 kcmkwin/kwinoptions/kwinoptions_settings.kcfg M +1 -1 kwin.kcfg M +2 -2 options.cpp M +1 -1 workspace.cpp https://invent.kde.org/plasma/kwin/commit/f474686a584a0f3049b3eddb8b148d3703a7148a
(In reply to Noah Davis from comment #46) > Git commit f474686a584a0f3049b3eddb8b148d3703a7148a by Noah Davis. > Committed on 23/05/2020 at 02:39. > Pushed by ndavis into branch 'master'. > > Change CommandAllKey to Meta > > Summary: Alt + Left Click to move windows has a tendency to conflict with > creative workflow apps. While Alt can be changed to Meta in KWin's settings, > Alt + Left Click shortcuts often cannot be customized in apps. Rather than > making every user who runs into this problem change their settings, we > should change our default settings to improve KWin's default usability. The > fact that Alt + Left Click to move windows is older does not matter. We are > trying to use Meta for global/shell shortcuts anyway. > > Test Plan: The relevant parts of the relevant tests pass. > kwin-testInternalWindow fails, but for unrelated reasons that have something > to do with XWayland. > > M +7 -7 autotests/integration/internal_window.cpp > M +2 -2 autotests/integration/pointer_constraints_test.cpp > M +15 -15 autotests/integration/pointer_input.cpp > M +1 -1 doc/windowbehaviour/index.docbook > M +2 -2 kcmkwin/kwinoptions/actions.ui > M +2 -2 kcmkwin/kwinoptions/kwinoptions_settings.kcfg > M +1 -1 kwin.kcfg > M +2 -2 options.cpp > M +1 -1 workspace.cpp > > https://invent.kde.org/plasma/kwin/commit/ > f474686a584a0f3049b3eddb8b148d3703a7148a Thank you Noah, and everyone who's involved in the discussion. I honestly thought this problem would stick with us forever. It was a long and educational experience, and I'm really happy that we can turn a new page at the end. Looking forward to the future where we don't have to explain to people that why Krita can't work well on KDE Plasma ("it's home platform") by default. :D
Wooww! Thank you!
Changes like these should be accompanied by a notification to the user first time they try to use the old modifier to move the window. I thought something was broken in kwin these past few days until I saw Nate's blog post. I usually just glance over the list, but fortunately I had a thorough read this time. Also, did this change go through code review as I can't find it?
@Ivan https://invent.kde.org/plasma/kwin/-/merge_requests/12
(The commit didn't get automatically linked to the merge request due to https://gitlab.com/gitlab-org/gitlab/-/issues/208344)
@David @Nate Thanks!
I've reported this long time ago: https://bugs.kde.org/show_bug.cgi?id=377722 Thank you so much!
You're welcome!
*** Bug 377722 has been marked as a duplicate of this bug. ***
I somehow found this gold thread from PowerToys discussions -- because I recently reinstalled both Arch Linux and Windows from scratch, and I need to set all things up again. And I must say, I'm really glad that Meta/Super/Whatever-you-call-it is now the default instead of Alt. I'd just wish my keyboard had a duplicating Super/Meta key on the right side of a space bar (to be able to drag with one hand on using touchpad), but I guess that can be worked around by remapping right Alt in the Keyboard preferences.