This sounds good to me, although we'll need to handle some (literal) corner cases like having two panels at a right angle to each other without a sufficient gap to avoid the panel configurator UIs overlapping. And probably some similar space issue with "zll widgets visibly show their widget-specific options (remove, configure, rotate, resize, etc).".

You can do it for Dash, though -- check that isDash check where it already adds some runners to the Dash it doesn't add to App Menu.

Let's only do it for Kickoff and the Dash? The Kicker UI is really not made for arbitrary runners.

I'm not super happy with hardcoding directory separators and schemas, judicious use of QUrl::fromLocalFile or QUrl::fromUserInput would probably be better to norm behavior.

Ironically quite similar to a DDoS vector on the Task Manager. Apps suck :)

In D21978#483972, @hein wrote:

That's wrong, sorry - I'm uploading a different patch that fixes the underlying cause.

That's wrong, sorry - I'm uploading a different patch that fixes the underlying cause.

As the Task Manager maintainer I agree with @mart's take -- it's strange to have this (and have this be popular) as an option in the Task Manager but not a UI that serves a similar purpose, and also gets invoked from the TM.

I'm in principle quite OK with this minus that other patch I need to be written first to move DragHelper out into the lib (see other comment). Pitch: If you do that, it'll make it much easier to make the other menus (and other things) act similarly later, with much smaller patches and cleaner code there.

In D21954#483133, @ngraham wrote:

Could this go to the stable branch?

In D21954#483114, @ngraham wrote:

Can we also pre-emptively add 2.12 as well? :)

Currently on airports, will do from the Plasma sprint :)

Thanks for restoring my sanity & faith in panels, this annoyed me for weeks :)

The work Geon and I did in GSoC had an fcitc5 backend with plans to add a second one.

In the hybrid approach, we can also get more ambitious than a widget list: System Settings could totally have a minimap version of your entire system that shows the screens with panels and a little config icon on each element that brings up the respective master dialog. The part shown in SysSe can get a little more free form if it doesn't have to show every widget.

I understand the motivation here, and it's worth entertaining as a thought experiment, but I think as-is it has problems.

• Fix typo
• Rebase

As the comment on Youtube points out the slides are not readable. Can you upload them somewhere and link here or in the video, so one can follow your talk better. I would also like to get an overview on current state on X11 in particular.

I submitted the same goal last year:

I'm still a bit grumpy about this and dragging my feet! My gut still says it's both option clutter and UI noise :-)

I'm not sold on this. "Display" fonts typically have spacing and metrics optimized for large sizes and use cases like signage. The FAQ entry quoted in the task you linked talks about Noto Sans UI. I'd like some more solid documentation on how Display relates to this "UI" cut or something from upstream.

Why?

I wouldn't call this implementation ready for frameworks, though - it just resets all the time, which is very slow as it forces views to destroy and recreate delegates instead of just updating them. A better implementation would just (re)filter source rows corresponding to the current page. This could be done as a subclass of QSortFilterProxyModel or custom; KItemModels' KRearrangeColumnsProxyModel can serve as inspiration to some degree. As it stands I wouldn't actually use this if it was in the framework.

It's not that easy I'm afraid.

I'd say it's up to the Breeze maintainers. From my end I'm very interested in the app having a Breeze-compatible icon, because I'd like it to integrate well with KDE's workspaces and other apps. Review by the Breeze community is very appreciated to help with that. Application code needs to ship the icon anyway though for systems that don't have the theme and can't be reasonably expected to provide every app icon, so it's not vital to be included with the theme.

@trickyricky26 It's great! What do you think about adding the detailed SVG as 256 version?

Looks great to me. Subtle visual refreshs like this are very appreciated, especially when they improve consistency, too.

LGTM.

Personally I'm not a big fan. I think the square OSD has more character and visual flair. The change proposed here looks rather cramped and removes some identity from the system.

Works here now, thx!

I think it would be safer to Math.floor() rather than Math.round().

Fix refcounting

In D20237#443594, @davidedmundson wrote:

Personally I tend to prefer just readable, explicit code for simple cases.

Now the timing of my comment becomes awkward :/

In D19874#443917, @filipf wrote:

@hein what's your opinion on reducing the margins?

Do some cleanups suggested by Kai.

Fix up qDeleteAll usage, thanks David

Suuper good question that I also don't have a really good answer to :( But it's always super good when a project figures out how to answer it (e.g. Krita took off after it made a call to be a painting app).

I'm not sure the "Konqueror had it and people are asking
for it back" argument is strong. Because Konqueror was also unpopular enough to get replaced by Dolphin and to end up largely unmaintained (although it is still released and available). To me that indicates that becoming more like Konqueror may actually be the wrong direction.

About the icon issue, IconItem by default uses the icon theme overlay from the Plasma theme, Kirigami.Icon will use the regular Plasma icons. That's kind of tricky - with Breeze we could totally make them match, but other Plasma themes would have issues.

Sure, why would the release team bump an individual app version if it wants to follow a random scheme?

Or the QPA could look at the LnF in the first place instead of kdeglobals?

In T10755#180964, @aspotashev wrote:

In T10755#180963, @hein wrote:

That just seems to describe how you can make your app follow the KDE Apps YY.MM version number, not how Release Team can bump an individual app version number.

Looks like we have a subtask: Make sure all apps in "KDE Applications" store version numbers in a unified place, even if the version is not being bumped by script.

In T10755#180961, @aacid wrote:

In T10755#180958, @hein wrote:

But bumping version numbers is a technical problem that can have a technical solution.

It's not a problem. we've been doing that for years https://community.kde.org/Guidelines_and_HOWTOs/Application_Versioning

The Places panel is really for frequent and immediate access whereas bookmarks are more for long-term organization.

On the other hand, having the release team take care of all of this stuff automatically and on a predictable schedule is really nice.