Wording suggestion for such popup:

> ### You tried to use an advanced feature
> 
> Pressing middle mouse button over an input field triggers "selection paste", which allows to paste the text you last selected. It's an unique feature that bypasses clipboard and allows for quick copy-pasting by only using your mouse. Be careful not to paste sensitive data.
> 
> Do you want to turn this off or on? If unsure, turn this off.

I think, no need to mention "primary paste" as it's an implementation detail. "Selection paste" keeps it simple.

I don't think this is a bad idea, but I'm not exactly certain how we would introduce this. We've basically never done this before (though it's a good idea to have some kind of machinery for this). I've seen this concept in other operating systems, particularly around accidental activation of accessibility features (like StickyKeys on Windows).

If this was considered it would make sense to include within the Welcome to KDE window.

In all the feedback I've seen of people not wanting middle click paste the issue has always been about how easy it is to trigger accidentally rather than an issue of not being aware of what has just happened. 
I haven't many KDE complaints since we added the option.

I've no objection to having some text / surfacing the option in plasma-welcome. I'm not especially convinced by something that happens after the fact; the already has just leaned it's pastes a load of content in their document because they can see it. If it was accidental middle click they're already annoyed and will definitely check no and remain annoyed. If it was deliberate then we don't need the message.

(In reply to David Edmundson from comment #4)
> In all the feedback I've seen of people not wanting middle click paste the
> issue has always been about how easy it is to trigger accidentally rather
> than an issue of not being aware of what has just happened. 
> I haven't many KDE complaints since we added the option.

Do you have a reference? Every complaint I saw so far (and I can give examples) that mention "accidental paste" is specifically because a user wasn't aware of the feature and not because they accidentally triggered it.

I struggle to see how you could occasionally trigger it, because doing so requires pressing middle mouse button over an input field — but there's no other functional it would conflict with, hence I can't see how to trigger it occasionally.

The reasons I created this issues are that α) some people annoyed by this functional (for whatever reason, they always cite insecurity of occasional paste), and β) it is a unique Linux feature which very few know about. For the paste months I've talked to quite a few converts from Windows on reddit mentioning to them this feature, and the feedback has been either positive or neutral. I'd be glad if I wouldn't have to reveal this cool feature to new people manually 😊

> I'm not especially convinced by something that happens after
> the fact; the already has just leaned it's pastes a load of content in their
> document because they can see it. If it was accidental middle click they're
> already annoyed and will definitely check no and remain annoyed. If it was
> deliberate then we don't need the message.

Well, the suggestion is that triggering middle-paste would not paste the content on the first use, but instead would trigger the popup. I.e. nothing was pasted and nobody gets annoyed 😊

The "Welcome Screen" idea I think is quite interesting, now that I wrote previous message and realized I don't even think many people would find out about this feature if it was done the "popup message" way.

But it needs to be a unskippable "welcome screen" message that requires to either turn it off or on, to make sure it is a conscious choice. Can this be done?

The philosophy behind plasma-welcome is to teach the user how to fish, rather than surface the fish for them. This means, instruct them in the design and structure of Plasma, what cool features are available, and where to find settings, rather than present them with a survey of individual toggles.

We do ask them about User Feedback, because it's useful to us to get eyes on such an opt-in feature. In the past Online Accounts were also presented.

I think the setting is too granular for inclusion in Welcome Center (we don't even ask about dark mode).

A popup is also probably intrusive, and has no precedent in Plasma. I could think of more choices that could deserve such a popup, but if the user experience when first using Plasma is to be presented with popup after popup for choosing settings… well, I don't think it would be received well.

What I believe we should do, is make it off-by-default, as there's more risk to an unexpected paste than not pasting when intended. It's an unexpected feature for users without prior Linux desktop experience, and something that existing users do disable. From those who spoke about it on Matrix, a few of our developers do disable this, myself included. This is a crap sample from which no real conclusions can be drawn.

It would be helpful to have real telemetry about the setting. It wouldn't tell the full story, because users can leave it enabled and not use it or be aware of it (especially as this is the default), but it would give some idea. If we find 30-40% are opting-out, then we might have a case to change the default. As it stands, our telemetry cannot collect such information even if we want, which has come up every once in a while for individual settings discussions like double-click to open.

I am aware that Neal intends to revive a proposal to make it off-by-default in Fedora KDE, and we might first see if this is a not unpopular decision before adopting it more widely.

I cannot foresee internal support for a popup, and as the developer of Welcome Center would prefer not to see such a setting advertised there.

I hope this has been helpful.

(In reply to Oliver Beard from comment #7)
> A popup is also probably intrusive, and has no precedent in Plasma. I could
> think of more choices that could deserve such a popup, but if the user
> experience when first using Plasma is to be presented with popup after popup
> for choosing settings… well, I don't think it would be received well.
Yes, I feel similarly.

There are many things we can do with respect to middle-click paste (including remaining with the status quo) but I don't believe a popup on first use would be well-received by our users.

S, thanks for the idea, but I don't think this is in the cards.

(In reply to Oliver Beard from comment #7)
> What I believe we should do, is make it off-by-default, as there's more risk
> to an unexpected paste than not pasting when intended. It's an unexpected
> feature for users without prior Linux desktop experience, and something that
> existing users do disable. From those who spoke about it on Matrix, a few of
> our developers do disable this, myself included. This is a crap sample from
> which no real conclusions can be drawn.

Well, then I believe we're at impasso. Making if "off by default" is a breaking change with a lot of opposition. "Primary selection" at this point isn't just for advanced users, it's been advocated on Reddit, and people converting from Windows are happy to use it, here's an example https://www.reddit.com/r/linux_gaming/comments/1p5wo3g/comment/nqmwz0a/

Whole purpose of this RFE is a sane compromise for both parties. What you ask for here is again pulling one of the sides, and it's been a flamewar topic ever since Wayland didn't include protocol for "primary selection", but then they did because of the push.

I don't think there's a need for compromise here, and I don't really see any flamewars, either.

People who use it can use it, and people who don't can… not use it. :) People who hate it for some reason can turn it off; that's why we have an option to do so.

(In reply to Nate Graham from comment #10)
> I don't think there's a need for compromise here, and I don't really see any
> flamewars, either.
> 
> People who use it can use it, and people who don't can… not use it. :)
> People who hate it for some reason can turn it off; that's why we have an
> option to do so.

That's fair. But just a few comments ago Oliver voted for tuning it off by default. I say it's a breaking change (as mentioned, new non-advanced users use it as well). That's the problem I am referring here. Whether you leave it off or on — someone will be unsatisfied. That's why I suggested a compromise solution.

I see Oliver is against having it in Welcom Screen, but how about at least making it a popup on the first use, as originally suggested? It wouldn't break this way anyone's workflow.

"Popup on first use" is the kind of thing that drives people crazy. I don't think it's a good idea, sorry.

(In reply to Nate Graham from comment #12)
> "Popup on first use" is the kind of thing that drives people crazy. I don't
> think it's a good idea, sorry.

Okay, here's a more general question: how can we make it being less of an easter egg? People in this thread came up with 2 solutions: welcome screen and a popup. You say it is too intrusive. Okay. Changing the default is intrusive as well. Leaving the default is frowned upon by some other people.

What do you suggest?

(In reply to Konstantin Kharlamov from comment #13)
> What do you suggest?
Do nothing, because the status quo is okay and any alternative we've thought up so far would be worse.

For the time being we would continue to do what we are doing currently.

When picking a default, we tend to go with what works best for "simple by default, powerful when needed".

Unfortunately picking a default can be seen as 'picking a side', but if we do make a change, we certainly won't do so without keeping the option, and we won't do so arbitrarily or flippantly.

Importantly, it is likely that if we do change the default, we make this change without being retroactively effective: only new users would see the new default, and existing users would be left with a changed setting (away from the new default).

—

Sometimes a compromise is unsatisfactory for everyone, which I believe a popup would be — an unexpected and instrusive window that appears asking a question without explicitly being prompted.

We could do a passive notification, but it would be kind-of clippy-like ("You just did <blank>. Did you mean to do <blank>?"). We know from history that this sort of interaction is obnoxious.

With Welcome Center, we are explicitly careful that we do not force the user to explicitly skip or finish it. If they close the window (i.e. we are told to 'f' off), that's it. It won't show again.

Yeah, the HIG doesn't specifically mention a PassiveNotification for this, but in https://develop.kde.org/hig/status_changes it suggests against "task completed" type popups:

> Indicate success by visually changing something on the screen related to the task that succeeded,
> not by sending a message saying “Task completed.”

However that gives me an idea: instead we could make the Clipboard icon in the system tray do a little wiggle or other animation when something is copied. That would fulfill the "visually changing something on the screen related to the task that succeeded" criterion.

Regardless, that's an idea for somewhere else, since this Bugzilla ticket was specifically about a popup to notify the user about the existence of the feature.

(In reply to Oliver Beard from comment #15)
> With Welcome Center, we are explicitly careful that we do not force the user
> to explicitly skip or finish it. If they close the window (i.e. we are told
> to 'f' off), that's it. It won't show again.

Would you accept a contribution of adding simply adding an information about this feature to the Welcome center?

(In reply to Nate Graham from comment #16)
> However that gives me an idea: instead we could make the Clipboard icon in
> the system tray do a little wiggle or other animation when something is
> copied. That would fulfill the "visually changing something on the screen
> related to the task that succeeded" criterion.
> 
> Regardless, that's an idea for somewhere else, since this Bugzilla ticket
> was specifically about a popup to notify the user about the existence of the
> feature.

Thanks! If you create such an issue, can you please link it here? I am not thoroughly clear how would it work, but I am curious 😊

>Would you accept a contribution of adding simply adding an information about this feature to the Welcome center?

I think it's too niche to mention. There's nowhere where it fits currently, so the only way to do it would be a new page somewhere, and it would have to include more than a single thing. Even then, a page about 'odd quirks and interactions you might want to change' just isn't a great page.

(In reply to Oliver Beard from comment #18)
> >Would you accept a contribution of adding simply adding an information about this feature to the Welcome center?
> 
> I think it's too niche to mention. There's nowhere where it fits currently,
> so the only way to do it would be a new page somewhere, and it would have to
> include more than a single thing. 

Well, I presume Welcome Screen doesn't mention Compose key? "Compose key" and "Primary selection" are the two obscure features I always introduce new people to, so I guess they could fit on such page.

> Even then, a page about 'odd quirks and
> interactions you might want to change' just isn't a great page.

Well, if it was just an odd quirk, it wouldn't be such a hot topic 😊 It's a very convenient tool for those who use it, and I was to word a page about it, I'd present it as such.

So far, Welcome Center introduces only Plasma-specific stuff. It doesn't talk about general Linux/FreeDesktop features.

That could be changed if we re-conceptualize the app to include "people 100% new to FOSS" and not just "people who are at least somewhat familiar with FOSS but new to Plasma".

Surfacing these kinds of hidden non-Plasma-specific quality-of-life features somewhere does feel like a good idea to me overall. Somehow! Now sure how.

I do not think notification is good for this, but we could show this "middle click buffer" with explanation tooltip in the clipboard widget. I think it could be useful for newcomers and pro-users alike.

I'll make a VDG gitlab issue about it at some point and can link it here.

I think we'll want to think about the UX of discovering "easter egg" features for both accidental and intentional activation. As we implement more default-on features that have counterintuitive or unintuitive behaviors, this is going to crop up more and more. The biggest class of these are all the accessibility features, because none of them are discoverable by design and need messaging when activated accidentally.

For the accessibility features, I think it makes more sense since you're activating persistent modes you might not know how to turn off/get out of.

But that's a different situation from middle-click-paste, which is a discrete one-time action.

I see a very good reason to disable middle-click paste on trackpads by default. It's way too easy to mistakenly use middle click on them by default. On a mouse it would be good to expose the setting but have it on by default.

Here's my 2 cents for how we should approach this, as someone who used to hate this but has recently started using it unironically:

1. Move 'middle click scroll' from mouse settings to General Behaviour, assuming Middle Click Paste is already there (I forgot and can't check for sure currently)
2. Now middle click scroll is there, combine it and Middle Click Paste into a radio trifecta, something along the lines of:

Middle-clicking:
- ( ) Initiates scrolling
- (o) Pastes the last selection or copied text
- ( ) Does nothing

Alternatively:
Middle-clicking:
- ( ) Initiates scrolling
- (o) Pastes the latest clipboard text
.    [x] Paste the last text selection if newer than clipboard text
- ( ) Does nothing

As for the default setting, given it'll be inevitably be discussed if distros set it universally to scrolling instead:
1. Change the default, obviously
2. Provide a page in Tour to change it back for older users?

I think the behavior in Firefox without middle click scrolling enabled in  KDE Plasma settings and auotoscrolling enabled in Firefox settings is ideal because middle click pastes when the cursor is over text input but it enables the auto scrolling when the cursor is not over the text.

(In reply to The Feren OS Dev from comment #25)
> 2. Now middle click scroll is there, combine it and Middle Click Paste into
> a radio trifecta, something along the lines of:
> 
> Middle-clicking:
> - ( ) Initiates scrolling
> - (o) Pastes the last selection or copied text
> - ( ) Does nothing

But these are not conflicting features - libinput is smart enough to send scroll events if you move the mouse while pressing the button, and to send middle click if you don't move the mouse. I use both every day, without having to change any setting to go from one to the other. 

There's also a bunch of caveats - the scrolling option will interfere with everything that needs middle click drag (various content creation apps and games), and people confuse it with Windows-style auto-scroll which it is not supposed to be - it's mainly for emulating scroll wheels on devices that don't have any, like pointing sticks/trackpoints and some types of trackballs. (Though some people, including me, have found it convenient also on devices with actual scroll wheels.)

This is also why it has to be a per-device sand not global setting - people may want it on their devices without wheel, but not on their mouse that has one, so they can middle-drag with it.

I feel like every possible solution to this involves UX sinning, so some breakage of UX guidelines is unavoidable.

My take is that, leaving it on will confuse more users than will make use of this, _but_ I am not advocating for it to be switched off. I expect that users who expect this functionality are more likely to be in a focused "flow" state when they invoke this action, and any form of interruption, or it not doing what they expect would be very frustrating, and that users who are not expecting this and accidentally invoking it will be more likely to go "whoops, won't do that again" and not get too sidetracked. 

I think the best solution is to have it on by default - don't distract the power user, but be very obvious to what just happened, if a user does it for the first time in a while, send a standard notification to say "You just did this, click here to turn off, or here to never remind me again". It should disappear after a few seconds to not get in the way, but remain in the notification history panel so if someone saw it, but didn't want to actually read it at the time, they know where to look. 

While, I acknowledge doing this for everything would get very obnoxious very fast, I justify it as it's a very niche & unaffordable feature, that I think the majority of users _would_ prefer it off, so an offer to turn it off at the point of use will be regarded as a thoughtful UX detail, and is the least intrusive to the users that expect it to work, other than how it works today.

I didn't know this functionality existed, but due to sudden interest from people into primary paste in last week I get to knew(Streisand Effect).  This functionality is **not** popular because OS/DE never presented to end user. I appreciate this functionality and Wish it remains in KDE and Wayland. I hope If Devs decide to change it, It should be opt-out.