User Details
- User Since
- Jul 8 2015, 8:34 AM (455 w, 1 d)
- Availability
- Available
Feb 10 2023
Yeah, whatever else we do with KNS, KMoreTools wants its own home. The reason it lives there is just that it wasn't caught during the de-monolithifying work, and then we were kind of stuck with, so... yup :)
Jan 27 2023
As long as we can still "market" KNewStuffCore as a tier 2 framework, having the three of them in the same repository is fine by me, really :) And thanks for volunteering for that one! :D
Jan 25 2023
Right, so this is kind of hiding a further big one - we essentially want to split KNewStuff into four: KNewStuffCore, KNewStuffWidgets (which is what's currently called KNewStuff3), KNewStuffQuick (the Qt Quick components), and KMoreTools.
Jan 11 2022
We couldn't do it at the time, primarily because of how some things in KNSQuick is wrapping Core things, and it'd end up terribly confusing if some things were actually the literal things from Core, and some things were things that wrapped things from Core but wasn't actually those things. Still think that that logic is fairly sound, and it's perhaps also important to note that turning EntryInternal into a QObject has some pretty wide-reaching consequences. Not that it's not something we should do, but it's not at all trivial... Mostly to warn you, making it happen would be great, but don't want you trying to dig into that without having enough headache tablets in stock ;)
Nov 30 2021
i fully support this idea, and the plan as well. It will create a bit of temporary mess, but will also massively ease the transition come KF6 time, so yes, definitely let's do this :)
Sep 13 2021
It feels a lot like KMoreTools becoming its own framework really needs to happen, it's always felt out of place in KNewStuff, and it really more... parallel in functionality than anything else.
Jun 29 2021
Not done yet (obviously), but i've made a start and will continue tomorrow: https://invent.kde.org/frameworks/knewstuff/-/merge_requests/132
It's less a care of deprecation and more a case of replacing it (and then deprecating certain functions which will not make sense any longer when it's just a dialog that gives some information to the user and does not in fact contain the upload functionality itself). I'll do that after lunch today (which basically means shortly) and get the MR pushed soon as possible - haven't looked super close, but given the nature of the effort, i don't expect it'll be overly awkward to do. In-source documentation does sound like a good idea as well, i'll add those in as i go along :)
Jun 25 2021
Jun 24 2021
It really should be, yeah - KMoreTools feels super out of place, and i guess it was put into KNewStuff back in the kdelibs days because it was kind of a way to get some new stuff, conceptually, even if it was entirely unrelated to how the rest of the get hot new stuff system worked...
Jun 21 2021
Primarily for AppImages i guess, but also for source uploads, as well as flatpakref and snap uploads. Basically, this would tie into the whole "we need to be able to provide specific assistance for specific categories" thing, like linting of for example kpackage uploads (like plasma applets, which require a specific internal layout). Essentially helping people to correctly fill out their store listings. The first part is more work, but the second can be just sort of... done, i guess, by adding it manually (which would be something like appstream##id=org.freedesktop.ocstester as suggested in the tags proposal in T6133)
The image should be cached on the client, so the a point should at least be heavily mitigated. But, yes, adding a mechanism to knewstuff to use the current icon theme's "no image here sorry" icon when that default image is returned would likely make sense anyway, i'll see what we can do about that :)
Jun 19 2021
Yup, looks like just the one 651 now in the /content/categories output :)
Jun 17 2021
Hey there - this /should/ be doable yes. We have a couple of things to care for here to fully handle this on our side (which currently does not really know how to do the parent/child relationship the server returns right now, because it's outside of the OCS specification, but also that is something we should fix). That said, this only really affects some basics of the display, and since you're wanting to show them in two different locations anyway, you'll not need to worry about that part (and i guess i'm only really saying it here to have it on record that i need to get that done ;) )
May 11 2021
Just thought i'd mention, this is now worked on on https://invent.kde.org/frameworks/kxmlgui/-/merge_requests/57
Apr 30 2021
There we go - had to do some surgery to make it work, since of course kxmlgui has moved on since this patch was first made, but i've got an MR under way on https://invent.kde.org/frameworks/kxmlgui/-/merge_requests/57 (currently WIP because i want to add in functionality to not force onlineness until people allow it) which implements the most important part of this diff, being the part about removing the hard(ish) dependency on Attica.
Apr 21 2021
Right! Only a mere tiny short while later, the store has as of now got support for that avatar thing based on just the username - in a neat variety of ways, as well :) See Alexander's comment here for details: https://phabricator.kde.org/T10138#254182 (and i'll need to do some not-some-random-comment documentation for that somewhere useful)
@alexanderschmidt If you will pardon my excessive use of the English language here: Awesome :D That covers pretty much every reasonable base, i feel, and gives us plenty to work with.
Apr 13 2021
Feb 3 2021
To me, this sounds like... pardon my Look Around You commentary here, but: An experiment was conducted, based upon the hypothesis that more frequent announcements would be advantageous. The results gathered during the experiment show that this hypothesis was not true, and a reversal to the previous approach would be advantageous. So, in short, yeah, a Quarterly App Catch-up or whatever it ends up being called seems a good idea. It also seems like this would make it perhaps a little easier for single-app highlights to show through a little easier, with an occasional big release announcement type thing. We could then call that approach a follow-up experiment ;)
Jan 5 2021
Yes, i would be more comfortable with just getting rid of DownloadManager (and... i suspect we might very well be able to just mark it as deprecated, though... a quick glance through does point me to e.g. yakuake, which uses it for that simplistic convenience thing i was talking about above... not sure)
i have a use case in mind specifically for the cache (in short, this is the only way we can create links between content and the fact that it's a kns originated thing, without initialising an engine (that is, without phoning home first)). The models we might need to consider, but if they're not exported, we can't easily wrap them in the qtquick components (for example).
Dec 14 2020
The knewstuff bits are still in progress (taking way longer than i wanted, but... well, fires needed fighting and sidetracking happened, but i'm back on it shortly)
Dec 8 2020
i've no problem either way (and also lean towards unique_ptr), but would like to see this done sweeping on a per-framework basis (that is. until a framework is moved wholesale to using that, it would be nice not to have two different styles of dptr implementation in the same framework, it's a bit jarring to come across).
Sep 8 2020
Jun 8 2020
May 22 2020
May 19 2020
May 13 2020
Address comment by @ngraham
Yay consistency! Good idea (and timely ;) )
Incidentally, while this was committed before i could test it, i can confirm that it works fine with Calligra Gemini
May 12 2020
May 7 2020
Sorted, nicely done :) Makes the code just a touch simpler as well, which is always good :)
Thank you :D Land away :)
(oops, mistakenly marked as accepted, sorry...)
May 6 2020
Apart from these couple of details, it looks pretty good :) (i'd say just fix and commit, but one of them's a tiny bit larger than just a typo fix ;) )
Sorry about missing that bic issue before...
A bit nitpicky, that first one, the second's more serious (i'd like to avoid that in new code), but looks good otherwise :)
May 5 2020
Thanks for making me realise that it doesn't have to be quite so elaborate, @alex ;)
As @alex suggests, just use qlist::contains, it is supposed to be
reasonably cheap, so... yup, trust the framework! ;)
Address comment by @alex
May 4 2020
Since we have had a new Frameworks release while this is waiting
for the thumbs up, increase the @since to the next version.
Apr 30 2020
Apr 28 2020
Ping team framework and such? (i realise we're all a tiny bit more stressy than usual...)
That's well spotted. Thanks for taking that one on :)
i believe Carl's been doing some stuff already, and as we had a bit of a chat about it on the promo chat last week, i'll tag promo in as well :)
Thanks @ngraham, learn me to add debug information and then forget to commit it :P
Apr 27 2020
Apr 24 2020
On a related note, i'm waiting on reviews on D28701 at the moment... which i'm afraid might wreck some havoc with your patch, as they touch some of the same bits of the codebase.
Apr 23 2020
Was /just/ about to be all "nooo, widgets in core, crying forever" but this isn't core, so go for it ;)
(and now i've done it myself, terribly sorry about that, missed the WIP at the start of the title! Hope some of my comments were useful, though :) )
The reporting side of this seems based on a misunderstanding of what the UI-less Core is supposed to be doing... The conceptual intention in general isn't bad, but it needs a bit of work. Thanks for spotting it, too :)
Apr 22 2020
Some documentation and whitespace fixes for Frameworksiness
Nice! Got a few places where this could be very handy :)
Apr 21 2020
Apr 20 2020
Thank you to @ngraham for noticing this one! It only really pokes its head
out if you have multiple things installed and then try and uninstall one of
them - if you only have the one thing installed, it looks very much like
as though it's just cleaning up after itself and removing the containing
folder... Easy enough fix, though :)
As i thought, i was indeed holding the KPackage APi incorrectly ;) The culprit is hinted at in the line
Apr 17 2020
Tagging in a couple of people who were in the original chat about doing this integration... :)
Apr 16 2020
Address @ngraham's (and my own) worry about the synchronous behaviour exhibited by KPackage... Something a bit like this probably wants to go into KPackage itself, perhaps we can consider this after we've done a bit of testing of its solidity here...
Apr 15 2020
Tagging in those active in the referenced bug, except for the reporter who doesn't have a phabricator account
Think we're at the point where testing would be good, now. This update
means we now attempt to adopt already installed kpackages if you try and
install the package from knewstuff, and removal of entries installed
using the previous implementation should now also happen during a fallback
step, intended to make life a bit simpler for those who have used this
before...
(the fallback handling needs some more work, but also progress)
Apr 14 2020
- Make a touch of noise when encountering the fallback