- User Since
- Jul 8 2015, 8:34 AM (115 w, 3 d)
Thu, Sep 21
Change the approach from performing all the magic inside Kirigami (which resulted in not entirely consistent behaviours, depending on which actions you used), pushing some of the requirements for disabling things onto the app developer.
Thu, Sep 14
Mon, Sep 4
Fri, Sep 1
Aug 24 2017
Aug 23 2017
Good call, yes - gets rid of a lump of irrelevant and technically correct but subjectively incorrect information.
Ah, yes, good catch :)
Aug 22 2017
Also, i am a silly person and closed the wrong revision.
Aug 21 2017
Hmm... LGTM - mind that i am not the maintainer here, but it does look like it's likely the needed approach.
Aug 16 2017
The StackView is complaining about some erroneous anchoring (and i don't see the visual effects it's complaining about, as far as i can tell), but apart from that, it looks to work really quite nicely :)
Aug 8 2017
Jul 23 2017
Jul 22 2017
Jul 21 2017
Jul 7 2017
Hmm... i was thinking this could cause issues, i don't see anywhere assumptions are made about page size on the consumption side (damn we're lucky this whole split thing's so new ;) ). Nothing in the API suggests you might get more than the requested number when you ask for entries, but conversely nothing says you will potentially get less, and that happens on a regular basis, so... sure, why not :)
Jul 5 2017
Jul 4 2017
Different approach, but yeah, telling people what'll actually happen works :)
derp, not accepted, my bad...
That is indeed a very good point. I think we might possibly have an issue here, though, in that since these two searches are no longer stand-alone, if the filter is not explicitly reset before attempting to perform a search we will only search installed and updateable items. I don't think it is necessarily an enormous or insurmountable issue here, as far as i can tell the only code which currently uses these two functions is in KNS' own DownloadManagers (at least, lxr suggests as much), and if we ensure those two are fixed to reset the filter before launching a search, i think we're probably ok.
Jun 27 2017
Add/fix a whole bunch of more documentation, identified as missing (or incorrect) by Aniketh
Jun 23 2017
Jun 22 2017
Looks good for the initial case of getting rid of the obviously broken looking aspect ratio at the very least, though i think exposing the property might still be good... But, at the very least, it matches the HIG so that's cool :) (i don't personally like the whole scale-and-crop thing, but i'm also not the designer and i know entirely sensible reasons exist for this choice)
Jun 15 2017
Incidentally, because KNS itself will already postpone non-cached searches by one second, the new proposed solution above (to only to this for KNS sources) is already implemented by way of using D6191
Jun 14 2017
Related bug: https://bugs.kde.org/show_bug.cgi?id=380138
Upon reviewing prior to merging, i realised that a file was missing from the most recent diff (StandardBackendUpdater did, as suggested, not listen to the resourceRemoved signal, and now does).
Jun 13 2017
Fix glaringly obvious over-complication spotted by David :)
Adapted code as suggested. Note that this now depends on D6190 getting merged (as that contains the code that's iffed out).
Jun 12 2017
Don't const & an int, that's just silly.
As far as i can gather, it was simply never added because, well, it was never used in a lot of places... This really is more a case of equalising some features between requestData and other parts of the engine (so they can all be paginated by the size they really want to be).