Well, in this case, "privacy" is not really strong argument for disabling it. If you show a part of your desktop, be ready to show the rest.

I think the biggest problem with the translucency effect is that it makes windows translucent under wrong conditions. Making inactive windows translucent. Sure, makes sense*. But making moving windows translucent, don't think so.

+1

* Yet, it has one problem: if user has a bunch of inactive windows, background will be messed up.

Instead of turning off desktop effects, it would be preferable if users giving presentation would use the common sense approach of either extending their screens or using a different user for the occasion. If you're duplicating your user's screen for everyone else to see then translucency is only one of the many ways you are potentially screwing yourself over and is the least of your concerns. IMO this is a weak argument for the change. The line of thinking can lead to many more knee-jerk changes such as: let's turn off switch tab on hover in Kickoff or let's remove the History tab as a default entry because one of our guys' cursor accidentally went there during a presentation and everyone saw their p̶o̶r̶n̶ trade secrets :D

That being said, there is definitely a usability and a design discussion to be had about having translucency on for moving windows, inactive windows and resizing. Does it add functionality and does it even improve anything design-wise? I'm with Vlad here in agreeing that we can re-think this. I think it would be useful to gauge the opinions of users on this, as we may not necessarily see all the merits and the pitfalls ourselves. It would also be useful to have a look if other projects use translucency in this manner so I'd suggest not rushing it.

In D14850#309286, @filipf wrote:

I'm with Vlad here in agreeing that we can re-think this.

Well, no, I'm +1 for disabling this effect because of the reasons I wrote above. If some folks want to have translucent windows, then they just have to enable the Translucency effect and set desired opacity for inactive windows, etc. "Simple by default, powerful when needed".

I think it would be useful to gauge the opinions of users on this, as we may not necessarily see all the merits and the pitfalls ourselves. It would also be useful to have a look if other projects use translucency in this manner so I'd suggest not rushing it.

Major "players"(macOS, Windows, GNOME Shell) don't make moving windows translucent.

Well yeah I'm also personally more in favor of turning it off, I just wanted to shift the attention to a different kind of reasoning and analysis here.

And sorry for the digression but I'd want to ask a technical question though: I use Kvantum which blurs behind explicitly translucent windows so that means windows are actually blurred when moving them or resizing them. KWin (with the Breeze theme) on the other hand remains un-blurred. Is it possible from a technical point of view to also have KWin blur the titlebar while the window is being moved or resized and translucency is on?

EDIT: disregard the question, it's possible; it blurs when using the Adapta window decoration.

1. Do you want it to affect existing installs?

(please think about this before reading question 2)

2. Does it?

As it's an effect @zzag can have final say.

I used to disable that effect back in the days but now couldn't be bothered anymore. I don't particularly mind either way. :)

Do you want it to affect existing installs?

Also note that this effect can't just do "translucent on moving", there's also other conditions the user might have set this, so blatantly turning the entire thing off after an update might be undesirable.

The functional justification for translucent moving/resizing windows has always been to control its geometry in relation to windows lower in the stack ("what and how much will be covered", "where's a free area")
There may also have been references to early WMs when windows were just hinted by an outline during geometry transitions (though typically not unmapping the actual window), simply because displaying them while resizing them is resource intense (what's more of a concern when you're short on resources) - those WMs would often have presented an outline to allow controlling the initial position for the window before actually mapping it.

Turning inactive windows translucent was some cheap global dimming (w/ false positives in case of eg. video players) to stress the active window.

In D14850#309437, @luebking wrote:

The functional justification for translucent moving/resizing windows has always been to control its geometry in relation to windows lower in the stack ("what and how much will be covered", "where's a free area")

I can't imagine any real world example when one would need that. Could you please provide one such example?

I used to do that to compare layouts and metrics of different applications or images but that doesn't really justify being enabled for everyone by default

In D14850#309477, @broulik wrote:

I used to do that to compare layouts and metrics of different applications or images but that doesn't really justify being enabled for everyone by default

I think one could achieve that by taking screenshots and using gimp.

In D14850#309476, @zzag wrote:

I can't imagine any real world example when one would need that. Could you please provide one such example?

It's not a "when you need that" condition, but "to assist you doing stuff" - you get more information while taking a decision.
To be clear, I don't use KWin (or KDE) at all anymore, so I do absolutely not care what you're doing here (let alone "for a default") - I merely wanted to point out why this behavior is there itfp (and regardless of WMs or even DEs) and that this wasn't a "let's show that we've compositing" thing (unlike wobbly windows)

! In D14850#309479, @zzag wrote:
I think one could achieve that by taking screenshots and using gimp.

Sure but just moving two windows on top of each other is a lot quicker to do and doesn't require any additional setup steps

I think the point is that people who do like this effect and benefit in some way from its characteristics can register that preference by turning it on. Nobody is proposing getting rid of it, just that it isn't really an appropriate default for most people.

Do we have any documentation for these? I've never written one before.

• otherwise, if there is Effect-kwin4_effect_translucency config group, set kwin4_effect_translucencyEnabled=true.

Wouldn't this turn it on for people who had previously turned it off?

In D14850#309544, @ngraham wrote:

Do we have any documentation for these? I've never written one before.

https://techbase.kde.org/Development/Tutorials/Updating_KConfig_Files

Also, take a look at KMail.

In D14850#309545, @ngraham wrote:

Wouldn't this turn it on for people who had previously turned it off?

No, it will not. kwin4_effect_tranlslucencyEnabled would be already set to false.

Anyway, here's content of upd file:

Version=5

# Make the Translucency effect disabled by default.
Id=make-translucency-effect-disabled-by-default
File=kwinrc
Group=Plugins
Script=kwin-5.14-disable-translucency-effect.sh,sh

kwin-5.14-disable-translucency-effect.sh:

#!/bin/sh

HAS_ENABLED_KEY=''
HAS_CUSTOM_CONFIG=''

kwinrcname=`qtpaths --locate-file GenericConfigLocation kwinrc`
if [ -f "$kwinrcname" ]; then
    if grep -q "\[Effect-kwin4_effect_translucency\]" "$kwinrcname"; then
        HAS_CUSTOM_CONFIG=1
    fi
fi

while read -r line; do
    KEY="${line%=*}"
    if [ "$KEY" == "kwin4_effect_translucencyEnabled" ]; then
        HAS_ENABLED_KEY=1
    fi
    echo "$line"
done

if [ -n "$HAS_CUSTOM_CONFIG" ] && [ -z "$HAS_ENABLED_KEY" ]; then
    echo "kwin4_effect_translucencyEnabled=true"
fi

Not sure if grep -q "\[Effect-kwin4_effect_translucency\]" "$kwinrcname" is right thing to do.

Also, maybe "Make the Translucency effect disabled by default." is not quite right description.

Thanks for doing all the work. :p

Let me see if I understand this.

If the rc file has kwin4_effect_translucencyEnabled=false in it, that means the user previously turned it off, so we can just remove the line entirely because off is the new default.

Otherwise, the user did not explicitly turn it off so write kwin4_effect_translucencyEnabled=true inside the [Plugins] Section to turn it back on.

Is that correct?

In D14850#309626, @ngraham wrote:

Thanks for doing all the work. :p

Let me see if I understand this.

If the rc file has kwin4_effect_translucencyEnabled=false in it, that means the user previously turned it off, so we can just remove the line entirely because off is the new default.

We don't remove that line (yet, I guess KConfig will do this for us).

Otherwise, the user did not explicitly turn it off so write kwin4_effect_translucencyEnabled=true inside the [Plugins] Section to turn it back on.

Is that correct?

Yes, that's correct.

EDIT: It will set kwin4_effect_translucencyEnabled=true, only if user changed config (and had the translucency effect implicitly enabled), e.g. set different opacity for inactive windows.

Otherwise, we think that he or she uses defaults, so we're free to change them.

OK, so that will have the effect of turning translucency off in Plasma 5.14 for the 95+% of people who don't manually turn the effect off or fiddle with its settings. I'm okay with this, but I want to make sure everyone else is too before we do that.

In D14850#311057, @graesslin wrote:

Someone was giving a presentation during the KDE e.V. meeting and resized a Dolphin window to make it bigger. The act of doing this made the window translucent and revealed the content of the window beneath it. This was a significant privacy violation, and could have had damaging consequences.

I must say that I consider the privacy argument hardly convincing. If we follow that thinking we have to disable:

• minimize window
• close window
• present windows
• desktop grid
• resizing of window to smaller than window underneath
• moving of window to uncover other windows and especially we need to forbid applications to crash.
  
  Sorry we cannot make everything secure. User's need to use their brain. E.g. ensure that you extend the screen and put your trade secrets on the internal screen.
  
  So I don't buy the privacy argument and I wouldn't use this in the justification of the change - especially not when going to public with that. Users are not stupid and won't buy it.
  
  Personally I would recommend against this change from a change management perspective. The next KWin release has many, many user visible changes. Much more than the releases over the last years. From a change management perspective this is dangerous as we might ask for too much from our users. If we do too many changes users have difficulties to follow that and might disapprove the whole release as too many things changed. As an especially negative contributing factor for change management this release is the change in maintainer. This could backfire badly if we do too many changes ("that would not have happened with Martin as maintainer...").
  
  On another note I want to express my dislike to the changes which flip defaults. I think these are the "easy" changes which don't understand the larger picture. I especially mentioned this in the discussion about the no border change that I dislike these changes which just flip defaults. In that regard I'm disappointed to see (again) a change which just flips defaults. If we follow the logic of the mentioned privacy reason the proper reaction would have been to come up with a presentation mode in the window manager which ensures privacy by addressing all the obvious points.
  
  Also the change would break several unit tests and do to that I request changes to the revision.

These arguments are also not very convincing to me. In fact, during Akademy, it was applauded that we asked to change defaults to more sensible ones. Sorry, not seeing the picture. I would still move forward.

In D14850#311170, @abetts wrote:

These arguments are also not very convincing to me. In fact, during Akademy, it was applauded that we asked to change defaults to more sensible ones. Sorry, not seeing the picture. I would still move forward.

Disabling the feature is not the right thing to do. Let's face it how it is. There is something you dislike about translucency when moving windows. And you address a problem by turning off the feature. That's nothing we would have done in the past. Instead we would have tried to figure out what the issue is and improve it. As I said: switching defaults is the easy way to address issues. But it's not addressing the issue. The translucency effect - if turned on - is still showing all the issues which are the reason to disable it by default.

If you think the translucency effect is so bad that one should not use it the answer would be to remove it completely. If you think the translucency effect has issues, those must be fixed. Switching the default isn't and cannot be the answer.

And that's something I dislike. You don't think about what the issues are, just switching defaults. It's not thinking the thing through. I find this disappointing as we move backwards instead of improving the situation.

What I also dislike is that false arguments are brought up. You just admitted in your reply that privacy is not the reason for the change. Why do you bring it up then? Yes, I totally understand it. Because just switching the default is getting opposition. So you dislike it and search for a reason - something at all - which could justify the removal. Sorry, if I see a pattern like that, I'll speak up. If you don't like the effect, just say so. That would be honest and we don't need to fool around.

Now to make some things clear: I don't care whether it's on or off. I just don't think we should easily flip defaults we had for 10 years. If you think the effect has problems, let's address the problems and not just disable it. To me there are two possibilities: drop the effect or improve the effect. Turning off by default is not the solution I see, because it's just the same as removing (no user will find it - that's experience), just not going it through. If you really think the effect is bad, it must be removed.

In D14850#311057, @graesslin wrote:

Someone was giving a presentation during the KDE e.V. meeting and resized a Dolphin window to make it bigger. The act of doing this made the window translucent and revealed the content of the window beneath it. This was a significant privacy violation, and could have had damaging consequences.

I must say that I consider the privacy argument hardly convincing. If we follow that thinking we have to disable:

• minimize window
• close window
• present windows
• desktop grid
• resizing of window to smaller than window underneath
• moving of window to uncover other windows and especially we need to forbid applications to crash.
  
  Sorry we cannot make everything secure. User's need to use their brain. E.g. ensure that you extend the screen and put your trade secrets on the internal screen.

I agree with martin, it's up to the user to prepare for a presentation and I think the privacy argument in this case is very weak.

What I do not like about the translucency effect is, that the background is not blurred. In my opinion, all semi transparent surfaces in breeze should be blurred. And the blurred background would solve the privacy problem too.

And the blurred background would solve the privacy problem too.

It would also defeat the purpose of that effect which is to actually see what's underneath.

Yeah, if adding blurring it should be a toggle. Kvantum can already blur everything and it looks nice so it would be cool to have, but yes there is not much usability to it, just aesthetics. The Breeze window decoration would also need to gain support for this, however.

Will you still work on this? I'd love to see this progress.

In D14850#541353, @GB_2 wrote:

Will you still work on this? I'd love to see this progress.

yeah I just need to psych myself up yo write the kconf update script. Last time I had a go I was not successful. Help would be appreciated.