But if all ‘KDE Applications’ applications used the ‘KDE Applications’ version number, KPat wouldn’t have to manage its version number …

Hang on, isn't this kind of redundant with Places? At the very least they overlap a lot. Is this feature individually strong enough to warrant that overlap?

So version ‘3.6’ can mean a number of different versions, each with its own sets of bugs and features.

I don't find being part of KDE Applications releases very compelling for many of my apps. The reasons vary - some are alternatives to other apps in the bundle, some don't act in concert with anything else in the bundle, it means sharing attention with many other things (in two ways - public attention, but also dev attention: many things have to be spun up and be ready for release simultaneously, which is inconvenient), it means no ability to set my own schedule. Not getting to set my own version would actually add to that list.

Again you can't have a full list on the announcement with 215 names and version numbers, it's just not feasible.

I think then we'd have to rethink the way we promote, which could also be a solution. I.e. stop having a version number for KDE Applications entirely, instead of having a YY.MM we just make a "KDE updates apps today" announcement on some day, and the announcement includes a full list with individual versions. If we don't want it to be used, why have the number?

Looks solid to me. Is your concern re vertical spacing still valid?

My gut reaction was to agree with @ltoscano whole-heartedly, but the more I think about it that stance does have awkward unsolved problems.

I'd say let's go with Kirigami.Icon for now then, and recolor the icon to the highlight color on hover. @faridb could you take a stab at that? :)

I checked the database and it looks like you don't have a developer account yet, so I'll land this patch for you. If you keep submitting patches, feel free to apply for a developer account via identity.kde.org at some point :)

Looks pretty nice to me. I have no objections.

Thanks! Do you need help landing this?

I guess this brings us back to the old debate of a generic solution vs. patching all the UIs. I'm inclined to agree with this approach because it should probably be up to the specific UI what it wants to happen on the gesture.

rooty, your behavior in this thread has been extremely aggressive, disrespectful and uncollaborative. I'd like to ask you to stop at this point and not participate futher, as well as in any future threads related to the Task Manager applets.

In D19822#439336, @filipf wrote:

And that's why :D Your argument hinges on the idea that something trivial makes the UI cluttered (and also imposes a maintenance burden). I think that's too broad/dogmatic and can be true but it really doesn't have to be the case.

This is a specious argument.

I'm not a fan of the checkbox, I think it's a little gratuitous. If you add a small feature and need to immediately add a checkbox to disable it, it's rather a red flag to me. It means either the feature or the checkbox should probably go. Firefox gets away without the option BTW.

Yeah, this looks fine, thanks!

Looks good now!

Kicker intentionally doesn't have icons on the root level to not conflict with the favorites column and reduce visual noise.

What's the name of the .desktop file though? That's the most relevant part.

Sorry, that's too fast and loose for me.

Also, maybe we can just delete the .png files then and make the tarball smaller?

Looks great!

In D19606#429891, @ngraham wrote:

Idea to make the menu smaller: put the Configure and Alternatives items into the sub-menu, and rename it to just More Actions...:

Thoughts?

Boom! Landed it for you. Sorry this took so long!

I'm concerned that having title labels on everything could be overdoing it a bit? It makes the context menu very large and have a lot of dead space, and adds to the noise. Isn't that rather a detriment to utility on repeated use? It's sometimes important to remember new users don't stay new users for very long, and first-time use isn't the only experience to optimize for.

In D19096#427339, @trmdi wrote:

In D19096#427329, @hein wrote:

... I'll need to set some time aside to analyze what you're trying to achieve there and propose an alternative.

I just want 2 things:

1. Display 2 lines for long labels.
2. For labels need more than 2 lines -> display a tooltip that has the full label when hovering on it.
   
   That's all, no matter how you do it. Basically, I don't want to add any new feature, just want to make the existed stuff usable. (Currently it's not usable while it's existing)
   
   Thank you!

Can you explain more what this is trying to achieve / what it solves with an example?

Note: This is a very broad/community-sweeping intiative (the ideas here touch on many teams and even the e.V.), and as such it's important that it doesn't stay bottled up inside just Promo - please make sure this finds it way to the kde-community list well before concrete actions are taken on a global scale. Promotional work is just a small aspect of what's being proposed here.

I'm concerned that having title labels on everything could be overdoing it a bit? It makes the context menu very large and have a lot of dead space, and adds to the noise. Isn't that rather a detriment to utility on repeated use? It's sometimes important to remember new users don't stay new users for very long, and first-time use isn't the only experience to optimize for.

I'm sorry, but I can't accept this patch as-is - the hoverArea-related changes are just wrong, it's not OK to couple a delegate to the view by making it set tons of property on an item i its parent. I'll need to set some time aside to analyze what you're trying to achieve there and propose an alternative.

Almost! This is not going to work reliably for groups, because the order in which their children are deleted is up to the client processes. That means once a group goes from two to one and morphs into a regular task item, the window id it has might not match the winIdList[0] you previously recorded. Instead, you should store the entire winIdList, and when an item is removed check whether it's winIdList[0] is in the list you saved away. You also need to do a bounds check before you access [0] though because not every task has a window id (e.g. launchers and startup notifications), so you're causing errors ATM.

Looks good now!

Fix sorting and fallthrough for tasks on all desktops.

Sorry for the late reply, too.

SortDesktop needs to fall through to alphabetic sorting within a desktop.

I'm OK with this, but I'd like @ngraham to verify consistency on the indent issue.

Needs another revision to tackle an additonal problem, as per the bug reporter's feedback in the referenced bug#.

Does the PlasmaWindowManagement object need to be guarded in the same way?

• Open groups in popups
• Only when the Task Manager is full

I'm ready to push this to master - are you ok with realname attribution (Władysław Wokulski)?

Screenshot would indeed be nice, but it's a promising idea.

Sorry for the delay! Somehow I kept missing this. Patch looks fine, do you need help merging it or do you have write access?

What's all the unrelated code changes about mouse handling trying to achieve?

Would it be possible to also add the lineart versions as -symbolic? In my new app I rely on Kirigami's icon recoloring feature and it only works with monochrome icons, so I rely on -symbolic to request them.