In D15418#325341, @abetts wrote:

In D15418#325340, @acrouthamel wrote:

How about changing the volume icon for the non-playing application to audio-volume-muted.svg? Then, when it is playing audio, it reverts to low/high icons as usual, based on slider location.

Additional to that, the volume slider colors can be grayed out when not playing?

Basically +1 on the concept, but I think we need to make the appearance a bit more distinct between playing vs non-playing. I've thrown out some ideas, and I'm open to others. Reducing the opacity even further would work. Adding a little tiny piece of text that says "Not currently playing" to the right of the app name could work too, especially in conjunction with the reduced opacity.

Thanks for the patch! Please submit it using Phabricator's Differential/Code Review tools. See https://community.kde.org/Infrastructure/Phabricator for documentation. Since you already have a .patch file, it'll be as easy as pasting the contents into https://phabricator.kde.org/differential/diff/create/. Later on, you can set up arc to make the process even easier.

In D10429#324936, @romangg wrote:

It's unnecessary bling imo. And it can interfere with in-window elements (Firefox for example marks the active tab with a very similar colored line at the top). I would say let's try it out and listen for feedback in 5.14 cycle if people miss it.

Hah, yes it did!

I think all the +1s here deserve to amount to at least one green checkbox. :)

(and branching is tomorrow, per https://community.kde.org/Schedules/Plasma_5)

In D6513#324458, @leinir wrote:

In D6513#324419, @ngraham wrote:

So I see ghns_exclude over at store.kde.org, but it doesn't feel quite right to check that box next to everything KDE4. Is that what I should be doing?

That is precisely what you should be doing, yes :) You are right, it doesn't quite feel right to just outright exclude everything KDE4 from GHNS, but the reason it works is that the filtering happens clientside, and it will still show up for anybody who doesn't have this patch (or, in other words, anybody who has a less than version 5.51 Frameworks).

The gist of that article seems to be, "Use a switch for instant-apply settings, and a checkbox for everything else." Fair enough.

OK, let's do it!

This patch works well for me, FWIW.

Awesome. Since we're in a cherry-picking mood, let me pre-warn you that if we get good results during the 5.14 beta, I'd like to consider cherry-picking https://cgit.kde.org/plasma-desktop.git/commit/?id=a4c724173b5c6a59331587f2e5db746dffbabdc6 too, or else we're going to get a lot of user anger over it in Cosmic.

The beta branches tomorrow. It would be nice to get this in so that people can test and offer feedback before the release.

NIce catch. On another note, did 6597d3f35196 fix https://bugs.kde.org/show_bug.cgi?id=324597 and/or https://bugs.kde.org/show_bug.cgi?id=278661?

Did we ever figure this out? :)

Anything left to do here?

This was done, by you, in D11057! :)

Nah, I'll land this now, and bump X-KDE-PluginInfo-Version in src/desktoptheme/breeze/metadata.desktop before Frameworks 5.51 tagging.

Yes. :)

Seems to work with LO 5.1.6 for me!

A good next step might be creating a formal Phabricator group for this, to which people could add themselves. Then for example we could document that new contributors should add the group as a reviewer for their first patches, which could help make sure that those critical first patches don't get lost and always have someone available who can help. Thoughts?

Thanks for the patch! Is there an easy way I can test the failure case?

In D6513#322167, @leinir wrote:

In D6513#322078, @ngraham wrote:

So is this enough for people to start tagging KDE4 content as such? Or is anything else still required before that capability lands?

In short, this is basically enough :) When people run KNewStuff with this patch, any content which has been marked as ghns_exclude (that tick box you and the other moderators have on the store) will be hidden from the user :) For doing more "proper" filtering, changes will want to be done to either just the knsrc files, or to the clients themselves (which would be for things like "don't show wallpapers with incorrect resolutions" or "only show things with x86 binaries" or that sort of stuff).

You good with this now, @fabianr?

@muhlenpfordt, I can take point on the behavioral part of the review, but would appreciate your code expertise for the code review!

Would still be nice to get ctrl+⇧+0 to work somehow, but ctrl+alt+0 is okay too in my book.

In D15380#324312, @ach wrote:

+ 1 for Ctrl-Shift-0

Sidenote for non-konsole aka no-shift-modifier apps:
If someone feels like making Ctrl-0 for apps that know about ctrl-+/- more popular: it used is chrome and firefox, kmail and akregator. But kate okular and gwenview miss this shortcut
Consistency rules ;-)

Oh darn, you're right.

Looks good to me, and doesn't regress anything in any of the other locales I tried. I'll let @hein do a final review.

Thanks, that helps!

Hmm. Here's another idea: we could badge the app icon with player-volume-muted, maybe.

@acrouthamel, could you test this patch to make sure it doesn't regress anything for High DPI users?

Thanks again for this patch! Sorry it's taken so long for you to get a review.

Before-and-after screenshots can make a big difference in the reviewability of a patch like this. :)

Never mind, this patch depends on changes in master, so into 18.12 it goes.

I find that people tend to repeatedly press Esc in "computer is scaring me" panic mode, so I don't think it would need to be documented the way "long press Esc for 5 seconds" currently needs to be. It's theoretically possible that some client would want to listen for a long-press of the Esc key as well, but we're talking about corner cases of corner cases here. :)

Better now, thanks! And sorry for the extended review time.

You need a contributor account to push your own changes. If you keep submitting nice patches, you should eventually apply for one! But in the meantime, I will land this for you.

Thanks Roman! I agree that changing focus with alt-tab (or anything else) should disable the pointer lock, that the notification message is annoying and should go, and that "long press esc for 5 seconds" is not very obvious and probably should go too. I find myself agreeing with @hein that pointer lock should return if the client regains focus: if I alt-tab out of my FPS game to check my email, when I alt-tab back, it should work again (provided I haven't been killed during the email break lol).

Cool. I have one general formatting suggestion: please respect the soft per-line 80 character limit. Some of your edits make each line really long, and it's deliberate that lines be artificially limited to about 80 characters.

That dimming effect might be too subtle on a brightly colored app icon. How about dimming the black volume icon instead of or in addition to the app icon?

In D15341#323715, @smithjd wrote:

KRunner as a standalone application does much more than search for files. Therefore adding independent shortcut configurability isn't so hard to justify. Kicker/Kickoff and dolphin search text input shortcuts on the other hand are configurable globally already, and only perform a subset of what KRunner does.

Adjust message string

Awesome. Tested it out, and this definitely helps for 1366x768. Doesn't regress the 1920x1090 or larger case, either.

In T8711#159319, @acrouthamel wrote:

What where the difficulties you came across?

• The introductory process of reading Wiki pages. Even with the improvements to Get Involved, there is no easy 1-2-3, here is how you get started. For example, to get started as a developer, you are pointed to an article, which has lots of information, sure, but is not a set procedure really. I was looking for something like:
  1. Create a Bugzilla account, do this.
  2. Create a KDE Identity account, do this.
  3. Create a Phabricator account, do this.
  4. Get your dev environment setup, follow these steps.
  5. Pull down this Git repo (say, a tutorial repo), create a branch
  6. Edit this file, commit it, and create a diff via Arcanist.
  7. Once approved, land your commit like this.
  8. You have now followed the basic process and can contribute!

In D15341#323672, @smithjd wrote:

Kicker/Kickoff and the dolphin search aren't full-fledged launchers like KRunner, only search fields for Baloo.

Implement first pass at some user-friendly error checking

Thanks, this looks like it'll be a nice improvement! I'll review soon.

"Solid" is one of the big reasons why I keep trying to do D14850: [effects] Turn off Translucency by default. Our software can't feel solid when it literally becomes transparent when you move a window. :)

Will continue working on this once I have a day to dig into the kconfig script some more. I put some hours into it at Akademy but didn't succeed.

If we leave it for 19.04, hopefully things will Just Work™ since Global Menu support was still a tech demo in Plasma 5.13.

I'm not that familiar with the intention and basis for the pointer constraint feature in the first place, so before I offer any UX opinions, can someone tell me why it exists? What's it needed for? Since it exists on Wayland but not X, is this a purely technical matter, or is there a good reason for having it but it was unimplementable in X?

• Don't show the unnecessary and annoying overwrite dialog
• Make a note of the validation steps I need to implement

I like this word.

Wanna do the honors, @fabianr?

Let's finally land this. :)

Much better! One more request: can we disable the menu item when the current font size matches the profile's default font size?

No new instances of Q_FOREACH, please. See https://www.kdab.com/goodbye-q_foreach/

I did this in 68cf360fe700c199a76ea6e050198c380b109bc3. If anything is still unclear or inconsistent, we can improve it in subsequent patches.

In T8712#142246, @simgunz wrote:

The link to the Mentoring page is literally the last word of the Getting involved page.