KDE Plasma 6 Alpha Approaches Next Week With The Soft Feature Freeze

[ngraham]

I'm sure KDE is making good progress towards its 6th major release.

But I still can't figure out what's going on with Discover. Devs clearly don't want to fix it. They don''t want to kill it. But they still waste time on things like

While a simple search in Discover is still fubar (has been that way for years and it will continue to be like that for the foreseeable future):

[screenshot]

Wtf would you show me "Sweet Ambar Blue" Plasma theme when I asked about Firefox?

Is that screenshot not from the Plasma 6 Alpha? If not, you might want to give it another try, because currently you're complaining about things that have been specifically addressed for Plasma 6 (one of which you even mentioned in a quote). So if you are using Plasma 6, then things still being broken despite our efforts an intentions woul be a bug, and I'd encourage yo to submit a bug report.

[bug77]

Is that screenshot not from the Plasma 6 Alpha? If not, you might want to give it another try, because currently you're complaining about things that have been specifically addressed for Plasma 6 (one of which you even mentioned in a quote). So if you are using Plasma 6, then things still being broken despite our efforts an intentions woul be a bug, and I'd encourage yo to submit a bug report.

It's not Plasma 6, it's 5.27.9. If you really addressed this, I would be really surprised. Because I remember I once sparred over this with a developer and I was basically told it works perfectly fine.
I understand it shows up crap just because it may have something in the description (and I appreciate it, at least, puts the relevant things). And if you at least added an option for me to tell it to not look into descriptions, that would be good enough for me.

[ngraham]

What one person told you in the past may be different from what people think now, or even how things are behaving right now.

That said, it looks like for me store.kde.org items aren't appearing in searches due to a bug, and not something intentional. However we have gone back and forth on this in the past; see https://invent.kde.org/plasma/discov...a403851e43ac54 and https://invent.kde.org/plasma/discov...2babee1d372396. The problem is that if we include store.kde.org items in searches on the home page, some people complain that they're irrelevant, but if we don't include them, then people complain that they can't find that stuff when they are looking for it.

Do you have any suggestions for how we can make both groups of people happy?

[bug77]

What one person told you in the past may be different from what people think now, or even how things are behaving right now.

That said, it looks like for me store.kde.org items aren't appearing in searches due to a bug, and not something intentional. However we have gone back and forth on this in the past; see https://invent.kde.org/plasma/discov...a403851e43ac54 and https://invent.kde.org/plasma/discov...2babee1d372396. The problem is that if we include store.kde.org items in searches on the home page, some people complain that they're irrelevant, but if we don't include them, then people complain that they can't find that stuff when they are looking for it.

Do you have any suggestions for how we can make both groups of people happy?

I would say it's pretty obvious: do what KDE does best and let people select what they want to see in the results. If there's only 5 options or less, you can put some toggles right in the results window so people can see they can filter.
However, my beef isn't with seeing stuff in the store or not. It's with including stuff because some term appears in the description. I know that can be a pain even when querying from the CLI, but at least in the CLI I can get away using a regex.

[Kver]

What one person told you in the past may be different from what people think now, or even how things are behaving right now.

That said, it looks like for me store.kde.org items aren't appearing in searches due to a bug, and not something intentional. However we have gone back and forth on this in the past; see https://invent.kde.org/plasma/discov...a403851e43ac54 and https://invent.kde.org/plasma/discov...2babee1d372396. The problem is that if we include store.kde.org items in searches on the home page, some people complain that they're irrelevant, but if we don't include them, then people complain that they can't find that stuff when they are looking for it.

Do you have any suggestions for how we can make both groups of people happy?

Looking at this, the problem isn't what is being shown - it's how Discover shows it. This would make the UI code and logic more complicated, but a good way to do it would be a tiered approach based on relevance. I've worked with these sorts of things before, and while it's a PITA to get set up I've always had positive feedback.

Firstly, determine the "tiers" of search results you'll have on display. In general...

• Tier-1 results have a larger listing containing more detail. E.g. include screenshots, size, last update, etc with a massive install button. There's only ever one of these, and it's always at the top.
• Tier-2 is what we've got now.
• Tier-3 is where we group things. Header with the name of the group, 3-4 entries in a row, maybe limited to thumbnails and labels. Last entry is the "see more" button.

To determine what gets tier 1...

1. Exact name-in-title matches, like "firefox" or "kolourpaint". Covers obvious searches.
2. Next potentially goes to most matching terms in the title, with remaining terms in the tagline or category. Have a floor of ~10-20 ratings, and at least a 3-star overall score. If multiple items match, pick a winner with a formula like "sqrt(my_rating_count) > sqrt(other_rating_count) + 8", if there's no clear winner, onto step 3. Searching "paint" in this case would return kolourpaint.
3. Lastly, do #2 again, but not requiring any title match. Searching "vector program" in this case would return Inkscape in tier 1, "3d program" would return blender in the top slot, and "photo" would top GIMP.
4. It's perfectly fine if nothing gets the top spot.

Beyond tier 1...

• Tier 2 would go to any result with all keywords in the title/tagline.
• Tier 2 would continue, but include description matches - but would require a floor of 5-10 ratings and a 3-star overall score.
• Tier 3 is where we may only be tangential. Items should be grouped limited to 3-4 items, with "view all" letting users drill down based on the the next sub-category of whatever we're in. This would group things into stuff like "Applications", "Plasma Addons", etc. If you're already in Plasma Addons, the grouping would then be "Wallapers", "Desktop Effects", etc...

I've used this approach mainly on the web with wordpress sites and documentation search utilities. Sadly I don't have any public-facing search tools I can link to ATM.

The one thing I think might be worth differentiating might be for "new" entries. If there's a new app released in the past ~year, it might be worth exempting from score requirements - but still limiting non-exact results to tier-2 while adding a "new" badge.

Hope that helps. I don't think I'm in any position to contribute again atm (and my Qt-fu is growing weak) but I could chuck mocks your way if there's any interest.

[openminded]

What one person told you in the past may be different from what people think now, or even how things are behaving right now.

That said, it looks like for me store.kde.org items aren't appearing in searches due to a bug, and not something intentional. However we have gone back and forth on this in the past; see https://invent.kde.org/plasma/discov...a403851e43ac54 and https://invent.kde.org/plasma/discov...2babee1d372396. The problem is that if we include store.kde.org items in searches on the home page, some people complain that they're irrelevant, but if we don't include them, then people complain that they can't find that stuff when they are looking for it.

Do you have any suggestions for how we can make both groups of people happy?

I think there should be a couple of checkboxes (here come their descriptions, not suggestions how you would call them actually):
1. Search on store.kde.org
2. Search through description

The first on would look for themes, extensions, etc present on store.kde.org
The second would search for hits within descriptions on packages and, if the first one is on, descriptions of store.kde.org stuff.

[dajomu]

Looking at this, the problem isn't what is being shown - it's how Discover shows it. This would make the UI code and logic more complicated, but a good way to do it would be a tiered approach based on relevance. I've worked with these sorts of things before, and while it's a PITA to get set up I've always had positive feedback.

Firstly, determine the "tiers" of search results you'll have on display. In general...

How would that work for a search like this? This search should list only what starts with the letters "KDE". In my opinion, if I wanted anything that had KDE in its name or description an asterix should be used e.g. "*KDE*".
NB, image below is for reference only and from Plasma 5.24 I believe.
image.png

[ssokolow]

I know that can be a pain even when querying from the CLI, but at least in the CLI I can get away using a regex.

*nod* My muscle memory is `apt-cache search foo | grep foo` and I only use Discover for updating what I've installed through the CLI and this is one of the reasons.

[ssokolow]

Poke. Unapproved despite not having a single URL.

[lowflyer]

Ok, I will stop using QML. As a result you can expect me to stop contributing to Plasma, System Settings, Info Center, Discover, System Monitor, Spectacle, Elisa, NeoChat, Filelight, Skanpage, Cuttlefish, Kamoso, and all other QML-based KDE software. Hopefully this outcome matches your expectations.

Sarcasm aside, it would be a good start - although, way too late.

The following is my very personal and subjective opinion. I can only speak for Plasma, System Settings, Info Center, Discover, System Monitor and Spectacle. I'm not using the others you mentioned.

* Plasma
Before QML there was a well thought consistent "design" in everything. You could intuitively "know" where to do what. And the configurability was one of the strong points. Now it has become so much windows-like. "There must be a setting somewhere but where?" It is still quite configurable but it lacks the organization.

* System Settings
Holy Cow! A conglomeration of dozens of smallish applications that are supposed to "work together" but rarely do. Does not work on slightly older graphic cards.

* Info Center
QML is an overkill for this small application. Everything it does is simple to express in plain C++ and Qt widgets.

* Discover
... has become so bad that I switched back to use the command line for installing/upgrading. And it's not for lack of trying. I use the GUI when a usable one is available.

* System Monitor
Used to "kinda work" - no longer does. I miss the non-QML plugins

* Spectacle
Fits into the KDE landscape like a hammer on a raw egg. I'm mainly using Flameshot. The worst thing is that the start menu doesn't find it with the usual search terms like "snip", "screenshot" "snitch" etc.

There was a very noticeable cut in "snappiness" with the introduction of QML, and it has worsened over time. In hindsight I have to say that this was very foreseeable: Operate a JavaScript engine in between your applications and the desktop. I did not know this at the time. I know now. There was also a perceived "pause" of development with the move to QML. That time would have been better utilized for improvement or bug fixing.

It is very sad to see a desktop that was so well designed at first, and surprised everyone with the memory consumption, to be destroyed like this.