KDE Plasma has the ability to increase/decrease opacity of windows via shortcuts however by default, for some reason, it doesn't use these shortcuts at all. I personally use this feature a lot, at least a few times a week so having it as a default for discoverability is something I think KDE themselves should do but might be something Fedora would be interested in doing.
Increase Opacity=Meta*+Alt+= Decrease Opacity=Meta+Alt+-
Note * - "Meta" is the term KDE uses to refer to Super aka "Windows" key.
This is the setting I use for my workflow and I use it often when podcasting so others might find it useful and it doesn't negatively affect anything as those shortcuts I'm suggesting are not utilized for anything in Plasma/KWin at the moment.
Video Demo: https://youtu.be/c5S7uOLHClw
Metadata Update from @ngompa: - Issue tagged with: experience
@rdieter, this seems like a fairly straightforward default we could incorporate. Is there any reason we wouldn't want to add this to our defaults?
Is there any specific reason that would prevent this from happening in KDE upstream? If no, could you report that there too? Thanks
@siosm KDE upstream doesn't seem to make changes here unless they start happening in distros first.
Any source for that? Changes to default values happen from time to time and the discussion happen upstream (see the neverending discussion about window borders). It also depends on each project.
I follow the weekly updates from https://pointieststick.com/ and it feels like there are changes similar to the ones I responded to here that happen regularly. If KDE upstream is unwilling to do the change for any reason then we can consider carrying it downstream but suggesting upstream feels easier.
I have attempted to contribute many things to KDE directly and this is one of those things. They have shot down most of them including this one for very weak reasons. This is a standard thing in my experience, KDE is ran by chaos so getting them to do something is almost not even worth trying.
With that said, I have tried on this one and they said no; reasoning was "This is a very niche feature, and adding global shortcuts takes potential global shortcuts away from other places. I don't see a need to set a default."
Changes to default values happen from time to time and the discussion happen upstream (see the neverending discussion about window borders). It also depends on each project.
Defaults change at random for random reasons . . . often they either take forever to do something or the flat out refuse to do it. There was one instance it took me 7 years to get them to make a simple change due to the insistent stubbornness of one developer. Contributing to KDE is painful.
I follow the weekly updates from https://pointieststick.com/ and it feels like there are changes similar to the ones I responded to here that happen regularly.
The same website also recently posted an article talking about how KDE is chaotic and referred to it as anarchy. They also made this blog post to brag about how poorly structured it is as if it was a good thing.
KDE makes bad decisions, the fact that they felt the need to brag about how it's chaotic as if that is a good thing shows how painful it is to deal with that project.
If KDE upstream is unwilling to do the change for any reason then we can consider carrying it downstream but suggesting upstream feels easier.
Almost everything I ever suggest to a distro has been suggested and shot down by KDE at some point. I say almost because at this point I have learned suggesting anything to KDE is a waste of my time. I have about 5%-10% success rate when suggesting changes to KDE. Their system of structure is easily one of the worst I've experienced.
I follow the weekly updates from https://pointieststick.com/ and it feels like there are changes similar to the ones I responded to here that happen regularly. The same website also recently posted an article talking about how KDE is chaotic and referred to it as anarchy. They also made this blog post to brag about how poorly structured it is as if it was a good thing. KDE makes bad decisions, the fact that they felt the need to brag about how it's chaotic as if that is a good thing shows how painful it is to deal with that project.
I suggest re-reading that article, because the conclusion is a bit different from the one your draw here. In fact it wasn't to brag about.
If KDE upstream is unwilling to do the change for any reason then we can consider carrying it downstream but suggesting upstream feels easier. Almost everything I ever suggest to a distro has been suggested and shot down by KDE at some point. I say almost because at this point I have learned suggesting anything to KDE is a waste of my time. I have about 5%-10% success rate when suggesting changes to KDE. Their system of structure is easily one of the worst I've experienced.
Except that "KDE" is not a monolithic thing. Are you talking specifically abut Plasma here?
"the conclusion" is your interpretation. This is not a definitive conclusion, this is how you perceived it. The way I perceived it is trying to justify an unorganized structure and making claims that it works when it most certainly does not. They referred to their own structure as anarchy and to me this is definitive reason why KDE in every aspect has always sat in mid-tier relevance.
No I am referring to KDE as a whole. I have attempted to change things in apps, in Plasma, in KWin, in widgets/plasmoids, and practically every experience is painful. Even the times I am successful are often painful.
I was able to make a change in Dolphin to implement Ctrl+H as the shortcut to show hidden files, this is the universal shortcut used in all file managers. After convincing them of the change, KDE decided that adopting a universal standard fully was not necessary so they insist on having the shortcut listing for what it is be the old shortcut so while Ctrl+H does in fact work now, it is secondary and not stating anywhere that it does thus ignoring what is already universal.
I was also able to make a simple change (not even for default) in KWin regarding Present Windows. This took me 6 years badgering many developers in KDE and also took the lead maintainer of KWin to step down before it even had a chance to succeed. This took 6 years to get fixed and only because that maintainer stepped down. This example is likely one of the worst I have because of how long it took and the amount of effort needed to get it to be changed but this is a perfect example how anarchy is a terrible method of structure for a software project because that one maintainer had ultimate power on KWin so anything he didn't want to do would not be done.
I suggest re-reading that article, because the conclusion is a bit different from the one your draw here. In fact it wasn't to brag about. "the conclusion" is your interpretation. This is not a definitive conclusion, this is how you perceived it. The way I perceived it is trying to justify an unorganized structure and making claims that it works when it most certainly does not. They referred to their own structure as anarchy and to me this is definitive reason why KDE in every aspect has always sat in mid-tier relevance.
I may say this is your interpretation as well. As long-term insider I read that differently. There are in fact people who decide, the problem here is the decision didn't match your request.
Except that "KDE" is not a monolithic thing. Are you talking specifically abut Plasma here? No I am referring to KDE as a whole. I have attempted to change things in apps, in Plasma, in KWin, in widgets/plasmoids, and practically every experience is painful. Even the times I am successful are often painful.
Again, it depends on the component.
I don't follow: the change was implemented, both shortcuts are supported now. Is it a big issue if the primary stays the one that Dolphin users have used for ages?
I may say this is your interpretation as well.
I said that myself.
As long-term insider I read that differently. There are in fact people who decide, the problem here is the decision didn't match your request.
My opinion of anarchy being a terrible structure has nothing to do with my requests. There are people who make decisions and they are done so via committee of anyone who wants to participate in said discussion making every thing take a very long time.
Icons Only task manager is being added in as a default, it has been asked to be default for a decade now and finally it has been considered.
The Visual Design Group is another example of "decision by committee" because there are over 260 people in that group and they all have the same amount of sway in the discussions. There is no way to be efficient with that many voices.
of course, and a policy where every component is managed in random policies is inefficient and might as well not even being inside of an organization.
I said it is an example of how even when I am successful, it is still painful. I convince them to institute something universal which is great and then they refuse to fully implement it.
This is not a complaint of the decision but an example that even with success there is a level of frustration.
the other example with KWin was absolute pain though
I'm in favour of carrying this downstream as it sounds like a useful shortcut but also requesting upstream.
Metadata Update from @timaeos: - Issue close_status updated to: Deferred to upstream - Issue status updated to: Closed (was: Open)