Thank you so much! Don't let me rush you and make your studies suffer, though. :)

Thanks, much better! Just a few more UI nitpicks. And one more thing: What does "Stored" mean in this context? As a non-Thunderbolt expert, I don't know what this means, and I suspect most users wouln't, either.

In D19214#417185, @rooty wrote:

Issues unresolved so far:
(1) Should this be done at all?

I think so!

+1 for this design as well. It's much better-looking overall.

@rominf, are you planning to come back and work on this at all?

"Activation Key" ?

This introduces a new warning:

Looks great now! One final thing: can you see about reading the configuration to find the keyboard shortcut rather than always assuming it's PrintScreen?

Uh-oh, something went wrong with the layout in this latest version:

In D14583#382850, @anthonyfieroni wrote:

If someone steal events it's not problem of the patch, similar patch as D15612 should be applied for that view.

Great! Now what happens if a user sets the focus option on X11, logs into a Wayland session, and tries to use it? :)

Excellent. Can you make the focus option not appear on Wayland? Then I think we'll be good to go.

Correct awkward string

In D19186#416850, @aacid wrote:

-0.2 from my side, the thing is called suspend not sleep, if you look for "linux sleep" in a search engine you get references to the sleep (3) and sleep (1) man pages, which would only confuse the users.

All right, let's do this. In final testing, I just found some blockers:

In D19209#416946, @rooty wrote:

Also, should we ditch the heading "Customize theme"? It doesn't seem necessary seeing as there's nothing to customize... aside from the wallpaper

No problem, I'll take care of this for you!

Thanks, much better. Putting the DolphinTabPlacement class in dolphintabwidget makes sense to me, but make sure @elvisangelaccio agrees. :)

Thanks for sending a follow-up patch so quickly!

Thanks @steffenh. I went back and re-tested everything and it all works *flawlessly* for me. Very impressive work. I really hope we can get it in for KDE Applications 19.04. I'll start on the code review:

In T8177#176789, @dos wrote:

Small glitch I noticed: when using PLASMA_USE_QT_SCALING=1 on X11 and minimizing window with a KWin effect, Plasma reports unscaled iconGeometry (in logical coordinates instead of real pixels, like 200x850 instead of 400x1700 on 2x screen), resulting in wrong animations. This doesn't happen on Wayland.

Other than that, I've been using it for months now and seems to work fine.

In D19183#416862, @aacid wrote:

Personally i don't like it given than it is a very horizontal layout.

To me, the mental image here is page turning.

LGTM. @cfeck, are you happy now?

Works great on my 1920x1080 screen BTW.

In D19153#416773, @davidedmundson wrote:

My general rule is that you should only ever use it if you have no other feasible option and in response to an explicit user action.

You meet both those criteria, but it would definitely be worth looking at moving this to be activated via kglobalaccel directly.

Ok, so let's do this for now @davidre:

On Wayland we should just forget about the feature? That seems... less that ideal. What's the plan to fix this?

In D19153#416515, @zzag wrote:

I urge you not to deal with focus. On X11, applications usually abuse such power, so it led to things like fsp. For what it's worth, clients can't activate by themselves on Wayland \o/.

I always miss these when they're not there. :) +1

Thank you for the patch! You did great, and on the first try, too!

With the default System Settings window size (and default font & size), the URLs now get cut off at the bottom nearly all the time. Also, having all the metadata in a stacked list of strings isn't as nice as I think it could be. We could save a lot of space by combining things, like this:

Neato, getting there...

In D19185#416355, @davidedmundson wrote:

Even if we do change it, krunner should still match for search queries "suspend" and "sleep"

Yeah, I think Take a new screenshot makes sense as the default option.

Hmm, you might have to keep the hardcoded height, given that the QWidgets container expects the QML view to have a certain size.

Makes sense to me. Seems to make more sense when using an RTL layout too. Okular folks, are you good with this?

Use font metrics

Then again there's an argument to be made for consistency. I would be okay with using clickable icons instead of toolbuttons as long as we make sure to use a pointing hand cursor when hovered.

In D19153#416016, @davidre wrote:

However in our case we would call this only if configured by the user to do so and explicitly requested by the user by pressing the Print key. Also if spectacle isn't running and the Print key is pressed , currently Spectacle will open and steal the focus even if I'm typing in another application for example Konsole. Considering these two points I think it's reasonable to argue that this behavior would be acceptable.

Oh no, you didn't do anything wrong at all. It's a Phabricator bug that your authorship information gets discarded when if you use git format-patch (Phab wants everyone to use arc; see https://community.kde.org/Infrastructure/Phabricator#Using_Arcanist).

Even though we use clickable icons rather than toolbuttons in the QWidgets version, I think we should use ToolButtons if the visual style isn't too bad. People complained about the lack of pressed and hover states when the SwipeListItem used clickable icons instead of toolbuttons.

Not being a user of Activities myself, I have a hard time commenting on whether it's really necessary or not, but I suspect it is just a nice-to-have since the Desktop Toolbox only fulfills this function when it's been deliberately dragged out of the corner.

Add context

Now that's what I'm talkin' about!!! I love these!

Add context

Add context

Thanks. Can you please provide your real name and email address so I can land your patch with correct authorship information?

Currently the only place that we use long press (to my knowledge) is to enter the Widget's own private edit mode. I'm not real thrilled about that TBH, but I could accept it as a secondary, touch-centric UI once we have a better desktop-specific UI for it (See T10190: (Re)define modes when editing panels and widgets)

...Looks better on my non-cheap display, too. :)

Nice job, @shubham. Wanna do the same thing for Okular next? https://bugs.kde.org/show_bug.cgi?id=361756. Probably doesn't need an option there.

Friendly ping!

Thanks for that very valuable information, @anemeth. It's great to hear from someone in the trenches, so to speak. Your reasoning is exactly why I wanted to put the power- and user-related buttons front and center. Sometimes we forget just how confusing it can be for normal users when something commonly-used isn't front-and-center, and how unlabeled icons-only ToolButtons can cause problems even when they use a nearly universal icon.

This is much better. I think this is a visual improvement. Please make sure @zzag is good with the code before landing, and also let's maybe wait for a few more VDG opinions. :)

I have wanted this for so long!

I don't personally use a dark theme, so I'll leave this to you guys. :) But I think editing the colors to be more modern and visually appealing makes sense.

I don't have a very strong opinion but I kind of like the idea of each one being its own plugin. That way you could see and choose a POTD provider in one step rather than two (1. choose POTD plugin -> 2. then go through list of POTD options)

Also as @mart pointed out in D19044, it might make sense to do all the styling in the qqc2 desktop style theme for this control, rather than here in Kirigami itself.

I'm not in favor of this at all in its current form. Any tinting of the text with the background color under it reduces legibility. I'm as in favor of aesthetically appealing user interfaces as anyone, but not at the expense of usability.

@feverfew, are you still around to work on these issues?

Maybe we should just update the Breeze Dark color scheme instead? People who want something dark want something dark, if you know what I mean.

@hindenburg?

Nice! So now the only problem I can still find is that the "Return focus to Spectacle" option doesn't work, just like you said. I don't know enough about how Spectacle interacts with the window manager to help with that, but maybe @zzag or @davidedmundson can offer some insight here?