Might be worth learning from others' mistakes, experiences, and successes, if we can. The Linux Mint folks had the same problem a few years ago, and solves it last year, as outlined in this blog post: https://blog.linuxmint.com/?p=3199

There's a lotta good stuff in there, particularly how they handle buggy themes. I like the idea of making the development semi-open such that users could easily submit patches and KDE developers could accept and land them.

Hide all Plasma 4 content for Plasma 5 users

Other add-ons /extensions face or faced a similar issue, e.g. Firefox. They used to have a MinVersion and MaxVersion field inside the manifest (it's changed now since the'y using the WebExtensions format). Having written one extension myself, I found it a little preculiar that there was a "Max" Version field - how am I supposed to know that? However, they had some automatic testing for installing extension (installation only) that would notify authors, if the installation failed on newer version. If the installation worked, I assume that they simply adjusted the max-version field.
I've had a quick look at the metadata.desktop file spec, it seems like this is not possible to handle within that file ( unless a prefix is used (X-KDE-Plasma-Version-Min / X-KDE-Plasma-Version-Max) . It could be handled in a DB instead, of course.

Currently, with WebExtensions, it seems like there is only one version number: manifest_version (currently at "2"). However, since the content from store.kde.org is of a much greater variety, I'm not sure that this would be enough here.

Allow community moderation

Or at least an easy "report as broken" system that would trigger a review.
Maybe allow supporters to upload screenshots? Currently, 3 out of 10 Top Entries don't have a screenshot / image associated.

This is actively being worked on as we speak:
store.kde.org database already added an attribute to exclude any item from being shown via GHNS (called ghns_excluded), and we are now looking into making it available via OCS-API so those items are then easily "filterable".

It will take another estimated 2-3 weeks though before it can get LIVE, as it requires the whole workflow to be thoughtfully implemented.
Then I assume on the KDE side it can be quickly adjusted via attica or kns for those items being marked "incompatible" to be filtered out.

Well, this certainly is a very good start for those packages that never were intended to be installed through GHNS, good to hear!

Is ghns_excluded a boolean or does it also hold some kind of versioning info? Or is versioning info a completely different task? I'm also not sure that "Plasma 5" is enough, maybe it might be necessary to add the minor version (e.g. 5.12)?

It's good to know the API we need to actually implement this is already in progress, that should help a lot. I'm personally interested in having excluded 'stuff' filtered out by default and having 'disable curated results' as the optional mode for viewing results. We want to make the default experience as reliable as possible.

On the community side, I'm going to dive in and review as much stuff as I can and help other users to do so with a guided workflow so we can get as much of the broken content hidden as possible. Of course, we do want to be able to exclude content based on the Plasma version in use, so that may require some additional values, but excluding what's broken in recent Plasma releases may suffice for the moment.

Supposing for the moment that ghns_excluded is just a boolean, I think testing add-ons for the LTS release of Plasma would be the best place to start until we can accommodate more detailed metadata.

In T8126#131216, @starbuck wrote:

This is actively being worked on as we speak:
store.kde.org database already added an attribute to exclude any item from being shown via GHNS (called ghns_excluded), and we are now looking into making it available via OCS-API so those items are then easily "filterable".

It will take another estimated 2-3 weeks though before it can get LIVE, as it requires the whole workflow to be thoughtfully implemented.
Then I assume on the KDE side it can be quickly adjusted via attica or kns for those items being marked "incompatible" to be filtered out.

Hi. A year later, where are we with this?

I just started a new related poking, not knowing about this previous work:
Email thread "[RFC] store.kde.org: splitting off pre-Plasma5 Plasma themes?" https://mail.kde.org/pipermail/plasma-devel/2019-April/096572.html

Any chance the proposal to simply create separate categories for KDE4/Plasma and Plasma5 themes could be done for now, given the version flag systems seems to somehow be hard to turn into reality? Separate categories would also help people browsing the store via the Web UI, so they do not have to do extra work to filter out all the outdated KDE4-only content.
Happy to help out where I can, I would like to have this solved soonish.

Are there older plasma themes from kde4 times that do work in Plasma 5?
Or are all themes before a certain date broken?

In T8126#181152, @starbuck wrote:

Are there older plasma themes from kde4 times that do work in Plasma 5?
Or are all themes before a certain date broken?

Depends on the definition of "broken" and "work". For people who are not obsessed with pixel perfectness, some might still "work", especially if they are delegating some things like clock or notes widgets to the inherited (default) theme.

So there are a few exception where people might be happy to use what they got. But my emphasis on _exceptions_, as by design things might be broken, due to at least these incompabilities (as also listed in my email):

• "mini-*" panel-background variants got dropped, making non-full-width panels missing their sides
• clock hands rotation offset got changed from (0,width/2 to (width/2,width/2)
• notes background changed to color variants
• panel/dialog/window shadows now must be provided by theme, no longer added by windowmanager

So IMHO, from playing a lot with old themes the last weeks, a clear cut would be healthy.

So, by what I saw over the WE when I scanned and tried more themes on store.kde.org, I feel more confirmed making a difference between Plasma4 and Plasma5 themes is very needed, to fight frustration of users and theme creators.

Given that for now there are no people/resources available to introduce some properly designed supported-version/compatibility feature to store.kde.org/GHNS, I would like to ask for a primitive solution being approached then this time:

• splitting the category "Plasma Themes" into one for old themes and one for Plasma 5

That would be then the initial approach I had in my email referenced above, let me cite here to have things in one place:

When not knowning about technical details, I would have proposed to introduce a new category "Plasma 5 Themes", so the name clearly points out what target those themes are for (only). And then shift either automatically any themes uploaded to opendesktop.org over to that new category, if their upload/update timestamp is more recent, or, if possible, the metadata.desktop file could be inspected and has a "X-Plasma-API=5.0" entry. Or rely on the active theme maintainers to shift their product to that new category, at that time also showing a sign of "maintained theme".
This would allow a clean restart of the category, giving active theme creators all the proper attention and users only working themes (to what creators managed :) ), with any old cruft left in the old place, but still available there for manual download in case someone wants to pick content and e.g. port it to new Plasma5.

Though when looking at the technical details, I see plasma-themes.knsrc from plasma-desktop has "Categories=Plasma Theme" hardcoded, So existing installations will in the GHNS get feeded any content only for that category. And if the Plasma5-compatible themes get removed, the GHNS dialog will only show partially-broken ones.

Question: how grave would that be, how many people rely on that? And how quick could an updated plasma-themes.knsrc be pushed out to users, so the main transfer phase might be kept to a few weeks? Would distribution packagers be willing to do out-of-schedule patching of any supported Plasma packages to point to any new category?

Now, next to the incompatibilities for Plasme4-time themes, there also have been assumptions hard-coded into Plasma code relying on properties of the Breeze themes. Over the last weeks I have been fixing (most of) them, so upcoming Plasma 5.16 in June should allow more options for theme creators again.

So with that in mind, what about: Creating a new category "Plasma 5 Theme" right for Plasma 5.16 release?
So the fuzz about the release could also be used to spread the info about the related changes of theme support on store.kde.org. And have a one-time stir-up of theme creators, when they then can also explore the fixed features of Plasma themability.

Needed work to be done:

1. impove theme documentation, like theme porting (started at https://techbase.kde.org/Development/Tutorials/Plasma5/ThemePortingToPlasma5)
2. announce plans with the new category to theme creators, e.g. 3 weeks before switching
3. create & switch to new category:
   1. create new category "Plasma 5 Theme" on store.kde.org (some days before 5.16.0 tar creation (Thu 2019-06-06)
   2. change in plasma-desktop's plasma-themes.knsrc the entry to Categories=Plasma 5 Theme after that, before 5.16.0 tar creation
   3. backport the plasma-themes.knsrc to Plasma LTS versions, ask distributions to add a patch until the next LTS release
   4. automatically move or ask theme creators to move their respective themes to the new category
4. add related notes about theme fixing and the new category to Plasma 5.16 release notes
5. in the sidebar of store.kde.org move the old "Plasma Theme" to some subcategory, so it's not confusing (no own proposal, the current list gives me no idea for some pattern), after half a year or so, when most themes have been moved

While this means some small disruption in GHNS and Plasma themes for some weeks, themes as before are available by the web UI and existing installations of 3rd-party themes will continue to work. After that though GHNS should finally only provide working themes again, at least for a while :)

I agree this is not the perfect solution. But without the perfect solution being worked on, this seems a doable intermediate solution given the resources available, to unbreak to a good degree the current sad theme discovery situation with the otherwise so great feature of Plasma themes.

If you agree with this, who would be up to team with me on getting this done?

We can easily add a new category and make that compatible to replace the
current one. We could also sort all plasma themes newer as a certain update
date into that or leave it empty to totally cold start. I just need to get
an official confirmation whatever is decided to proceed.

on the plasma side, I think it's a good idea, as it gives the idea of good quality control going on if there will be a category guaranteed to work well with the latest and greatest.

I don't think i have time to, but it looks a kind of thing that's good for recruitment of new people, from the users or from the theme creators

I now split off a separate task T10893 for the Plasma 5 compatible Theme separation into an own category. And would be the one driving it :)

In T8126#181350, @starbuck wrote:

We can easily add a new category and make that compatible to replace the
current one. We could also sort all plasma themes newer as a certain update
date into that or leave it empty to totally cold start. I just need to get
an official confirmation whatever is decided to proceed.

Good. So for the execution plan as sketched in T10893, there are 2-3 items we would need done from opendesktop/store.kde.org side:

1. create new category "Plasma 5 Theme" on store.kde.org (some days before 5.16.0 tar creation (Thu 2019-06-06)
2. add news to store.kde.org/opendesktop.org about new category (given existing news, not sure this fits the scope? other category additions/changes also not announced there, but perhaps something nice to do)
3. automatically move or ask theme creators to move their respective themes to the new category

Who would be the person/address I can contact/poke to add the new category in the days before Plasma 5.16.0 tagging (good date possibly Monday, June 3rd)?
Any option for doing some related news on opendesktop or notifiying theme maintainers? Would then sketch a text.

I personally favour a cold start, to motivate people to give their themes some active care and filter out those which got discarded by the time.

Please best reply directly on T10893.

Wouldnt be the reverse much safer and could start right away?
That is simply add a category "Plasma 4 Themes" and move old themes there,
so the current category can stay as is, but gets potentially better and
better themes?

In T8126#184202, @starbuck wrote:

Wouldnt be the reverse much safer and could start right away?
That is simply add a category "Plasma 4 Themes" and move old themes there,
so the current category can stay as is, but gets potentially better and
better themes?

That needs somebody to go through the list and estimate themes as "old" and to be moved. If there are resources by someone to do that, surely also an option. Would break GHNS for any people still on KDE4 Plasma, but those few could fix the knsrc file for them if they needed.

Anyone up to do that manual plasma4-only filtering? :)

The other way would make it impossible for users not on the latest plasma
5.16 then to find moved themes though?
Imo this could be more important than kde4 users not finding their old
themes anymore, but one way or the other it goes when splitting.

The filtering can be done by a db update moving themes older than a certain
date into the new Plasma 4 Theme folder.

In T8126#184204, @starbuck wrote:

The other way would make it impossible for users not on the latest plasma
5.16 then to find moved themes though?

That is what the task item "backport the plasma-themes.knsrc to Plasma LTS versions, ask distributions to add a patch until the next LTS release" was planned to care for.

Given GHNS with Plasma Themes is not the most important thing of Plasma, but more a nice additional feature, where custom manual downloading also works as temporary workaround, my main interest here was to get rid of all the legacy and unmaintained themes in the category.

At least personally I'd rather push active maintainers of themes and give their content improved visibility over people having done once a dump and never returned :) So a cold start with crowd sourcing the theme moving to the active theme maintainers would be in my line.

Also, given that there have been some theme support fixes coming with Plasma 5.16, which theme maintainers might pick up, they would then update their themes anyway and that time also move to the new theme category.
But I can see how others prefer to be less radical here. I might be too much in spring-cleaning mode still :)

In T8126#184205, @starbuck wrote:

The filtering can be done by a db update moving themes older than a certain
date into the new Plasma 4 Theme folder.

Might at least help as rough pre-filtering. Not sure what date would be proper, as there also was a longer overlap between KDE4 and Plasma5 and people uploading themes, from what I remember from theme scanning.

But I see categories are already being done while I type here. Oh well, what should I think of that?

That category demonstrates how the not so radicale way would go by moving
one oldest theme to it. This theme should now in 24 hours no longer be
searchable or found via ghns. Imo the other mire radicale way of creating a
total new category would mean much more effort and potentially errors than
this non-destructive, reversible path forward.

In T8126#184208, @starbuck wrote:

That category demonstrates how the not so radicale way would go by moving
one oldest theme to it. This theme should now in 24 hours no longer be
searchable or found via ghns.

Though there was no need to demonstrate that to me, I could well imagine in my mind ;) Or would you need to demonstrate yourself as well first that the store system works for this purpose of moving things between categories? :P

So, taking that you run the site and that you seem to prefer your approach, I will not invest more into arguing for what I prefer and just step back to be happy that you provide and support this site :)
What could/should we now do to reach the actual purpose of this activity, i.e. to get move all the legacy theme packages out of the way into a separate attic category? Plasma 5.0 was released in July 15, 2014. So one first rough filter might be to move anything before 2014 to Plasma 4 Themes. And then? Have someone(tm) manually go over the themes and see whether they apply, to reach the final goal of having only Plasma5 compatible themes?

Well, we could do many approaches, i think it is important to find something that is the least disturbing, hence having split the categories might not be the best approach.
If we are fine introducing some new method in Plasma 5.16 and keep it backwards compatible for Plasma 5 and also KDE SC 4.x users, then I would rather seek to implement such a method.
It would make use of the tagging system and probably also be best to demonstrate to see and play around with it without actually breaking things or making them irreversible.

The question is if e.g. Leinir can implement this tagging in a way to be useful in Plasma 5.16 and/or any release of Frameworks, as I am not too much into the GHNS/KNS/Attica/whatever side of things.

So I would still continue this discussion and seek more ways of what is possible, and then agree on the best way.

In T8126#184221, @kossebau wrote:

Or would you need to demonstrate yourself as well first that the store system works for this purpose of moving things between categories? :P

Yeah, I often test things to see if things propragate, if the whole logic applies and things end up through all the layers from ceator adding or editing things through ocs-api over khns in an installed Plasma (like does the product really disappear?). Otherwise theory is fine, but also maybe looking at things gets new ideas also if its good to handle, etc.

Right now there may be a much smarter way to go about your more radicale approach to clean up big, but without the drawbacks of *needing* to backport aynthing or have KDE Plasma 4 users suddenly without themes.
Will do one or two tests before putting a suggestion here to prevent me saying something that isn't correct. :)

In T8126#184224, @starbuck wrote:

Well, we could do many approaches, i think it is important to find something that is the least disturbing, hence having split the categories might not be the best approach.

Just, isn't the most disturbing right now with store.kde.org and even more when using GHNS that lots of incompatible KDE4 times themes with higher ranks are listed ,and trying them on current Plasma versions results in bad experience?

And I read this task and learn that one year ago you added an attribute "ghns_excluded". I also see this in the sources of KNewStuff. But It's not exposed in the Web UI for people uploading stuff, as of today. And indeed one often does "Install" on an item in the GHNS dialog, just to see it silently did not install. Again bad experience.

Then there seems no master plan how to support version dependencies, with the needed fine granularity. E.g. just Plasma4 vs. Plasma5 is not enough. New theming features appeared by the time, which do not work in older Plasma versions. (e.g. the new hints for clock hands only work for Plasma 5.16, result in broken clock looks with any older Plasma).

So given the pace observed here, while I usually also go for the best technical solution, given all the stakeholders in place whose work I cannot take over and influence otherwise, I favour the pragmatic solution of just adding a new category now, and getting rid of the current bad experience when trying new themes via GHNS based on proposals by ranks.

Given that GHNS is just one approach to get themes, and one still has access to any themes via the Web UI, independent of the category listed in, also people do not play with themes on a daily base, I really would rather invest into the community of now active theme maintainers and give their themes now the proper visibility and thus feedback loop, and free the GHNS users on latest Plasma versions from all the legacy and unsupported themes.

Also, given all the brokeness I encountered and had to fix throughout Plasma stack for 5.16 when trying new themes, I wonder if there really is a big number of people affected if we reduce GHNS Plasma Theme support for older Plasma installations to what would become the Plasma Theme attic. Besides, if those installations are maintained, their knsrc could just be adapted to point to the new category.

So I would rather go for a perfect GHNS experience starting with Plasma 5.16 over trying to please everyone a bit, where actually 80 % of theme-interested people will use Plasma 5.16 once available, as I'd assume. People using old versions also usually are conservative with themes, and do not need "hot new stuff" :) And if, there is the Web UI as option as before.

And if one day we have proper versioning dependency support, it would simply only be added for the "Plasma 5 Theme" category, as the old one is more or less the theme attic as it is already now, for all the old Plasma versions which also are not forward compatible to latest Plasma theme support features.

So, as before I think a new fresh "Plasma 5 Theme" category is a reasonable option, embracing the active people without hurting old installations too much. And does not block the future.

I agree and therefore looking into a way to achieve the exact same outcome,
but easier implementation and no drawbacks for older versions. Just need to
test to see if its feasable.

In T8126#184271, @starbuck wrote:

I agree and therefore looking into a way to achieve the exact same outcome,
but easier implementation and no drawbacks for older versions. Just need to
test to see if its feasable.

Okay, curious about the idea and outcome, thanks for exploring other approaches to get to the goal :)

After talking with Dan Leinir, here is another approach:

• Every file can be attached a tag, in this case "plasma-4" and "plasma-5" (or both or none).
• These tags can be set by every developer for their product files themselves
• If Dan does implement looking for the "plasma-5" tag actively set, the themes can stay in the category they are now, but only plasma-5 tagged themes will appear from Plasma 5.16 onwards, which from the end result should be like starting with an empty category.

Some Plasma themes have been tagged as examples and can be retrieved via ocs-api here:
https://api.kde-look.org/ocs/v1/content/data?categories=104&tags=plasma-5

In the backend, themes can be tagged via a multi-select dropdown when adding or editing files:

If this method is to be accepted, we need Dan Leinir to do the corresponding changes to the Plasma Themes knsrc file, test the results before live release and inform developers that this filter is going to be effective with release date of Plasma 5.16.

In T8126#184437, @starbuck wrote:

After talking with Dan Leinir, here is another approach:

• Every file can be attached a tag, in this case "plasma-4" and "plasma-5" (or both or none).
• These tags can be set by every developer for their product files themselves
• If Dan does implement looking for the "plasma-5" tag actively set, the themes can stay in the category they are now, but only plasma-5 tagged themes will appear from Plasma 5.16 onwards, which from the end result should be like starting with an empty category.

(meh, my reply got long, sorry)
My first gut reaction is that I wonder how those 2 tags will integrate with any and with which long-term strategy to support properly grained "version-supported".
Where I personally would favour a system with both author-controlled setting (known-versions-should-work) and user-reporting (existing-versions-does-work, perhaps even additionally distribution variants given integration side-effects), especially when it comes to future versions of the system using a resource when the author no longer is around (generally speaking, not just related to Plasma themes) and content is not updated. Taking into account real-world scenarios of regressions and partial backward-incompatibilities due to other forces.
Also do I wonder about duplication between version-supported metadata part of the content schema/format with the one now manually added to downloadable files by the authors. Ideally any data in the content schema/format would be extracted automatically.

Minor issue when it comes to implementation is also that the knsrc reading and respective tag handling is implemented in KDE Frameworks' KNewStuff, whose next version will only be released after Plasma 5.16.0, thus complicating the communication a bit about when the new filter system will be seen in work. Just mentioning, no showstopper.

So, I am not really thrilled about this proposal currently as I have no clue what this approach would do to some planned future proper supported-version tagging support. I see how it can work to achieve for now to filter opt-in with the GHNS system all the maintained plasma5-compatible themes (and we have to remember that this is already too coarse and should get more fine-grained), without changing anything to older released versions of Plasma software. It does not help the old released versions of Plasma to not see via GHNS all the latest themes added which might no longer work properly on them.
For now if asked I would still favour that simple splitting off into a new category, and hope for someone to sit down without pressure and invest into a proper version-support tagging filtering system, which takes away most of the try&error currently happening for users. This favouring is mainly based on my experience that theming support was rather badly maintained in previous Plasma5 versions (at least I ran into an awful lot of issues once I got serious about playing with themes).. So I doubt there is a big scene of people who will be affected if their support for Plasma Theme GHNS gets frozen to a separate attic of themes (well, the attic itself not frozen) . And after all any themes already downloaded and installed will work as before, those old Plasma versions just will not see newer themes added to the new category with GHNS.
And the reset with a fresh new category in Plasma 5.16 is the start of a slightly better experience when it comes to themes (especially when trying them out, as theme switching without restarting Plasma shell was having lots of issues (margins not updated, shadows not updated), making most themes look rather broken on first impression. There are still issues, but less now, still hoping to get the 2 last ones known sorted out before 5.16.0).

My 2 cents, as someone who is just a user of store.kde.org & knewstuff, so can only file whishes/opnions :)

In T8126#184490, @kossebau wrote:

(meh, my reply got long, sorry)

No to worry, best to get questions answered and concerns addressed - similarly long (inlined) reply incoming ;)

My first gut reaction is that I wonder how those 2 tags will integrate with any and with which long-term strategy to support properly grained "version-supported".

To make life easier, having a multi level versioning thing going on would seem to make a lot of sense. My original idea was to have the tags be standard version-strings, but the problem is that parsing them is just sort of awkward, and i'd like to keep the concept reasonably simple. So, what this does is to carve up the version tag into two, a major and a minor version (and arguably also a revision, though that might be a bit much... though we can certainly add that as well at some point). In short, what we've got here would be the major version (plasma-4, plasma-5 and a future plasma-6), defined as very simple string-match tags in the same way that ghns-exclude is. Minor versions could then be implemented using the more verbose namespacing syntax, so something like plasma##minorversion=16 for example. To equalise them, i guess we could have the tags exported from the store be plasma##version=5 or whatnot.

@starbuck: On that last comment at the end there, the search url would then become e.g. https://api.kde-look.org/ocs/v1/content/data?categories=104&tags=plasma##version=5 instead, but the user-facing options would not change from the screenshot you showed above, only thing to change serverside would be the Tag Name field would want to contain "plasma##version=5" instead of "plasma-5" in the database, which if i understood what you showed me right would be a pretty trivial change... perhaps @ronaldv would be able to confirm those suspicions? (or deny them, of course, also an option ;) )

Where I personally would favour a system with both author-controlled setting (known-versions-should-work) and user-reporting (existing-versions-does-work, perhaps even additionally distribution variants given integration side-effects), especially when it comes to future versions of the system using a resource when the author no longer is around (generally speaking, not just related to Plasma themes) and content is not updated. Taking into account real-world scenarios of regressions and partial backward-incompatibilities due to other forces.

That does sound like something that'd be terribly useful to have. A bit outside the scope here, as it'd be more a case of moderating the content, and having a tag-suggestion feature built... Very useful, mind, perhaps worth popping a task into the workboard so it doesn't get lost? :)

Also do I wonder about duplication between version-supported metadata part of the content schema/format with the one now manually added to downloadable files by the authors. Ideally any data in the content schema/format would be extracted automatically.

Not entirely sure what you're asking there... The content version field is a piece of metadata for the entire content item, and the downloaditems don't have version fields themselves. The dependency system suggested by OCS was was not particularly well thought through, i'm afraid, and extremely monolithic (not only was it awkward in use, it was also explicitly server-defined, and also not by category). It also was never supposed to be used for filtering, which is why, well... it just isn't really used any great amount.

Minor issue when it comes to implementation is also that the knsrc reading and respective tag handling is implemented in KDE Frameworks' KNewStuff, whose next version will only be released after Plasma 5.16.0, thus complicating the communication a bit about when the new filter system will be seen in work. Just mentioning, no showstopper.

The tagging support is several frameworks releases old, and we've already been using it actively to filter out any item marked ghns-exclude on the server (this happens automatically in any category, as it is the default filter). It's also used in Discover's appimage support (which i think we talked about briefly last week?) to filter out any content item which has no binaries which will run on the current machine's architecture. In short, it's already there and working, all we need to do is use it :)

So, I am not really thrilled about this proposal currently as I have no clue what this approach would do to some planned future proper supported-version tagging support. I see how it can work to achieve for now to filter opt-in with the GHNS system all the maintained plasma5-compatible themes (and we have to remember that this is already too coarse and should get more fine-grained), without changing anything to older released versions of Plasma software. It does not help the old released versions of Plasma to not see via GHNS all the latest themes added which might no longer work properly on them.

Not entirely sure how retaining the status quo for people on older versions of our software is a bad thing, though... Yes, we could split up categories, but given that doesn't solve the problem you're actually trying to solve here (which would be the major/minor version dependency thing) i'm just not sure what it'd achieve, other than suddenly leaving people in Plasmas 5.0 to 5.16 at something of a disadvantage they did not suffer from before...

For now if asked I would still favour that simple splitting off into a new category, and hope for someone to sit down without pressure and invest into a proper version-support tagging filtering system, which takes away most of the try&error currently happening for users. This favouring is mainly based on my experience that theming support was rather badly maintained in previous Plasma5 versions (at least I ran into an awful lot of issues once I got serious about playing with themes).. So I doubt there is a big scene of people who will be affected if their support for Plasma Theme GHNS gets frozen to a separate attic of themes (well, the attic itself not frozen) . And after all any themes already downloaded and installed will work as before, those old Plasma versions just will not see newer themes added to the new category with GHNS.
And the reset with a fresh new category in Plasma 5.16 is the start of a slightly better experience when it comes to themes (especially when trying them out, as theme switching without restarting Plasma shell was having lots of issues (margins not updated, shadows not updated), making most themes look rather broken on first impression. There are still issues, but less now, still hoping to get the 2 last ones known sorted out before 5.16.0).

My 2 cents, as someone who is just a user of store.kde.org & knewstuff, so can only file whishes/opnions :)

And finally, a touch of productiveness in the word salad ;)

To apply filtering using the two tags which currently exist in the store, add the following line to your plasmathemes.knsrc file:

DownloadTagFilter=plasma-4!=1,plasma-5==1

What that means is that it will accept only items which have at least one downloaditem which has been tagged as suitable for Plasma 5, and reject any downloaditem which has plasma-4 set (the logic for DownloadItem tag filters is that as long as at least one DownloadItem is marked as accepted, the entire item will be accepted (unless the contentitem itself is filtered out, at which point the downloaditems aren't checked anyway)). If we end up using the more verbose, granular versioning tags i suggested above, that line would be:

DownloadTagFilter=plasma##version!=4,plasma##version==5

What is currently missing is a tag filter checker for greater and lesser than checks, but if we decide that we want to proceed with such a thing, then that could be defined now, and then once implemented in KNewStuff, they will simply start working. So then it becomes something like

DownloadTagFilter=plasma##version!=4,plasma##version==5,plasma##minorversion>15

Which would logically then say we require plasma version 5.16 or newer, but reject plasma 4

(Sigh, another long thingie, just no way found to cut short. I appreciate your efforts in still reading this :) Sorry, no cookie hidden in the end as reward)

The tagging support already available in KNewStuff is good news, was not aware :) (no, not talked about stuff recently)

When it comes to the described supported-version tagging, I sense this might need some more elaboration first to model more possible real world scenarios. Right now this appears to me (by what I see, no idea about your big plans) being a bit ad-hoc just taking Plasma Themes into account :) So let me try to brainstorm (partially speaking to myself here then):

Resources, like e.g. Plasma Theme bundles, are implementing at least one certain resource specification. The specification changes by the time, so has different versions, with backward-compatible ones and non-backward compatible. Now, implementations might not cover the whole specification or the format might allow built-in variants, so their content can often be compatible across a range of otherwise incompatible specification versions.
Then there are resource consumers, which implementing support for one or multiple versions of the specification, with consumers again having different versions where some versions extend support for newer specification versions, while others cut support for some. On top of that some consumer versions might have accidentally broken or incomplete support for some versions of the specifications. Or only some variants of the consumer, due to side-effects from their integration with some system (think distribution). Or some content in a given version of a resource triggers a bug. Or some version of a consumer trips over a bug in a resource, where other consumer versions ignore it or work-around.
Most of the time, there is only one consumer, like with Plasma Themes, so the versioning of the specification matches the versioning of the consumer.
But some resource specifications, like icon themes or cursor themes, are cross-product specifications. So there the version of the specification (if existing) would be good to have with the resource. next to having as well with the consumer the list of supported versions of the specifications.
And for real world shit happening, one would also like to know in which cases simple theory & reality do not match and one better skips a certain resource (or variant of a resource).
The resource itself might not (want to) know about all its consumers (i.e. not baked into the resource data), as well as the consumer itself not (want to) know about all its potential resources (not baked into the code), so there might be the need for a separate database, e.g. at the trader of a resource product (like store.kde.org).
Also can there be multiple current variants of a resource each implementing a different version of a specifications (or multiple). To support those existing consumers not supporting the latest resource specification (e.g. a few Plasma Themes have bundles to download for Plasma4, Plasma <=5.x, Plasma >5.x, ...).

Next, while most version schemes use semantic versioning, not all do. And we also have seen so-called epochs of versions, where a version system was reset/switched (see https://en.wikipedia.org/wiki/Software_versioning for some zoo of variants).

About the duplication between version-supported metadata part of the content schema/format with the one now manually added to downloadable files:
I mean that the resource format itself might have a entry scheme where the supported versions of the resource specification are noted. Something like the proposed X-KDE-Plasma-Version-Min / X-KDE-Plasma-Version-Max in the metadata.desktop file of a Plasma Theme bundle. Or the android:minSdkVersion with Android apks. Ideally such information can be extracted per resource type, so the author has not to specify this manually in store.kde.org again,

So, if there is a documented complete concept of versioning support using tags, with some real world examples across the current supported resource types on stores.kde.org/opendesktop.org covering certain types of versioning schemes (also future potentially supported resource types), as well as concepts for workflows/UX both for resource creators/providers & resource consumers/deployers , I would feel more confident with the tag system as proposed above. Right now I wonder if it really will match the real world sufficiently. It might, but I have not walked it through, given I have no worldview here :)

With all that written, I start to think that what I/we want here is this, does this match your idea?

• a way to specify for the (current) variants of a resource product the compatibility, both in theory (specification versions compatible) as well as in reality (consumer versions compatible)
• versions would be either explicit lists of version specifiers, or open/closed version ranges, if the type of ids can be automatically ordered matching version sequence (like with semantic versioning)
• for a given variant of a resource, the bundle file to download has all the versions of the specifications it is compatible to set (proper resource formats have data for supported spec versions baked into, and the store would just extract them, for the rest the uploader/provider has to manually set them)
• the downloading tool would compare against the specifications supported by the consumer(s) it was asked by to download resources for
• nice to have: there might be a user-driven database on the store to query where users could give feedback about for which consumers (in which integrations) the given resource variant version really works well or where which issues might be expected.

If we see tags as otherwise untyped generic strings where any further semantic is only done by human readers, expressing e.g. multiple spans of supported specification versions by matching tags set against tags to filter is a big challenge, if possible at all?

By example of a Plasma Theme which has 3 variants:

• supporting Plasma 4.12...Plasma 4.last & Plasma 5.0...Plasma5.15
• supporting Plasma5.16...5.18
• supporting Plasma5.18...

what tags should those both have set?
What should be the tag filter for a Plasma system that is 5.18, and what the tag filter for a system that is 5.20?

As sketched so far, it seems to me this tag system might help with 80 % of the cases as they are simple enough, but keep the other 20 % unsolved, and make the path to a more sophisticated system harder, as mapping to such tags to support then old Plasma versions might be extra work as well as incomplete. Sp, not yet sold so far.

Here some corner cases which I have seen happening and which a perfect system would handle for users, instead of letting them run into troubles otherwise preventable due to knowledge existing. All of which would need proper information about versions supported both by resource & consumer.

Use case:
some version RV of a ressouce R supports the versions SV1..SV2 as well as SV4..SV8 of specification S (as newer specifications added backward-compat mode). That versiom RV of R should be only shown in installation managers of consumers which support any of the same specification versions.

Use case:
some version CV of a resource consumer product C breaks support for a resource specification S. A resource author creates a version of a resource R just for this broken version of C. In the resource installation manager with C at version CV only this special variant of R should be available. But not in other versions of C, where the non-special variant(s) of R should be available.

Use case:
some version CV of a resource consumer product C breaks support for older versions of a resource specification. When switching to that version CV of C, all installed resources which are broken due to this should be disabled or, if possible, proposed for update to a non-broken variant if existing.

Use case:
some version CV of a resource consumer product C only supports a new non-backward-compatible version SV of the resource specification. When switching to that version CV of C, all installed resources not compatible with SV should be disabled or, if possible, proposed for update to a compatible variant if existing.

With a few more days of partially more thinking about all this, by what was said and tried I fear I do not see us agreeing on a solution soonish, and given I have already spent more of my free time on this than I planned, I have to drop out now of this discussion, to return to the other items on my personal todo list.

Hope I inspired at least some more thoughts with you about how modelling the known world might be needed to be done to cover 99 % when it comes to resource compatibility... in any case, thanks again for spending your resources on store.kde.org and GHNS as service to us all :)

In T8126#184640, @kossebau wrote:

By example of a Plasma Theme which has 3 variants:

• supporting Plasma 4.12...Plasma 4.last & Plasma 5.0...Plasma5.15
• supporting Plasma5.16...5.18
• supporting Plasma5.18... what tags should those both have set? What should be the tag filter for a Plasma system that is 5.18, and what the tag filter for a system that is 5.20?

<also snip other bits>

To cover this more properly, we are going to need a more elaborate comparison system than what currently exists, and that's definitely a thing that's worth spending both the time to get right and the effort to implement. Good rundown of requirements as well :)

So, for now:

@ronaldv if you can adjust the output that currently happens for those two specific tags for Plasma 4 and Plasma 5 so that the ocs output is plasma##majorversion=4 and plasma##majorversion=5 respectively (rather than plasma-4 and plasma-5) that would be great, and we can then use that to filter now. Thank you :)

@leinir I have changed the output for the plasma tags. Please try, if it works for you now.

In T8126#185748, @ronaldv wrote:

@leinir I have changed the output for the plasma tags. Please try, if it works for you now.

Only seeing the one (A Pimp Named Slickback) entry with the tag set, but at any rate, using that i can confirm that it looks as expected, thanks! :) (that was only on page one, of course, there are other entries further in - thanks!)

it is true what is said above:

is earning store.kde.org a very negative reputation

this comes from inadequate censorship on top of it all.

Hello zachus,

can you explain what you mean by inadequate censorship? Any suggestions how to improve are also welcome.

people publish a simple servicemenu , do nothing else besides and their accounts and contribution gets censored and destroyed, without notice of course.

store.kde.org is highly unreliable as a repo and NOT RECOMMENDED AT ALL. just one of thousands of such incidents.

its just the people behind store.kde.org - they are highly irresponsible and no one has oversight over their abuses.

incidentally:

Do more curation; reach out to content authors and help them fix bugs and ensure that their content actually works properly

one user did just that, but his helpful good-faithed account was censored and destroyed and as a result the broken content is still current of course. This abuse has to stop right now!

and while that user in good faith fixed the original content after an API change, he will never ever upload anything onto store.kde.org again. So the others will have to live with that broken content forever. Those who flock to abusive sites deserve their fate.

There could be many reasons for this, e.g. other users marking a product wrongly as spam like in this case:
https://forum.opendesktop.org/t/product-cannot-be-found-by-searching-for-it/18379

If you open a topic in the forums section there, we can certainly look into why or what happened.

This phab ticket here is not about censorship, but ways to improving the overall quality of the content people see from the GHNS/KDE Plasma side of things.

are you trying to censor me? My point is that in order to improve GNHS you must improve store.kde.org and you must improve the quality of censorship by the proprietors of store.kde.org . Otherwise, there is little hope for change to the better.

But in the case quoted above, the account was not destroyed by the owners of store.KDE.org.
Doing that is a conscious decision by those owners, which in dubious cases sends a message of disrespect to the contributor. Those who are after disrespect can always go to MS-github for it.

The other contributors will just quit store.KDE.org and never look back.

This ticket is about improving the overall quality so that people don't have those kinds of negative experiences. :) Constructive suggestions are welcome.