Should be all fixed now.
- Queries
- All Stories
- Search
- Advanced Search
Advanced Search
May 16 2022
Oct 1 2021
Jun 3 2021
May 27 2021
I'll put this on resolved for now, we can create new tasks for the rest :)
There's still quite a bit we can do, but yes, you can now browse an opds catalog and download the open-access items.
With https://invent.kde.org/frameworks/knewstuff/-/merge_requests/95 being merged, is this fully implemented now?
Jan 3 2021
This was tracked in https://bugs.kde.org/show_bug.cgi?id=415606 and has already been fixed. Please use https://bugs.kde.org for bug reporting :)
I also want to mention that it has not very much in common with the rest of KNewStuff, other than that it is on the same repo. Maybe it should be split up in a small, separate lib.
Oct 30 2020
In D19338#676682, @kossebau wrote:In D19338#676680, @asturmlechner wrote:Hm, why was this new variable KDE_INSTALL_KNSRCDIR not put into KDEInstallDirs?
On the other hand it makes sense that module-specific variables are provided by the CMake config file of the respective module. Which allows projects to use the module without having to use KDEInstallDirs, but e.g. GnuInstallDirs.
In D19338#676680, @asturmlechner wrote:Hm, why was this new variable KDE_INSTALL_KNSRCDIR not put into KDEInstallDirs?
Hm, why was this new variable KDE_INSTALL_KNSRCDIR not put into KDEInstallDirs?
May 6 2020
May 5 2020
No problem, always happy to help 😃
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
Jan 30 2020
Jan 19 2020
KDE Unstable at this point is 5.17.80
KDE Frameworks is version 5.67.0
Qt Version: 5.13.2
Dec 28 2019
Oct 6 2019
Because I am unsure if you can interrupt a loop in a different function, I tried to figure out what KIO does. KIO seems to have a tiny jungle of jobs calling subjobs telling workers to suspend, and eventually the whole thing ends up at ConnectionBackend, which seems (TCP) Socket based. (With a local and remote modes, much like our download jobs).
Oct 5 2019
Sep 29 2019
Apr 25 2019
That does indeed look good, and not a huge departure from what we have already, which i'm sure will make people feel quite at home in the new version :) I do wonder if we'd want to, at some point, make it look closer to Discover, but certainly for now this seems a much more sensible direction.
Will be good see how it looks in dark theme, especially dark pictures.
Apr 24 2019
Looks great, though I would put the search field on top. It's a lot like the new GridView KCMs; maybe we can even use that template for it. The current Colors KCM looks a lot like that.
@ngraham: Fo sure, I will add my post from the forum here for better reference.
In D20693#455251, @leinir wrote:
In D20693#454874, @ngraham wrote:To show that a thumbnail clickable, switching to the pointing hand cursor when hovering over a thumbnail could work.
However I notice that the actual list delegates in the browse view seem to add frames and shadows to the thumbnails there, and they look okay. The frame's proportions even perfectly match the aspect ratio of the thumbnail:
Why doesn't any of that work here?
Apr 23 2019
To show that a thumbnail is clickable, switching to the pointing hand cursor when hovering over a thumbnail could work.
In D20693#454799, @sitter wrote:In D20693#454750, @leinir wrote:So yes, in principle i'd certainly like there to be some kind of background or outline to suggest clickability, but the current state (and any other generic rectangular background we might come up with, higher resolution or not) would yield the same suboptimal result...
QGraphicsDropShadowEffect via QWidget::setGraphicsEffect may work for that?
Another approach would likely be to write a custom blur implementation since we fiddle with qpainter anyway, TBH I think finding a way to use the effect is likely the wise use of time though.
In D20693#454750, @leinir wrote:So yes, in principle i'd certainly like there to be some kind of background or outline to suggest clickability, but the current state (and any other generic rectangular background we might come up with, higher resolution or not) would yield the same suboptimal result...
In D20693#454783, @sitter wrote:LGTM on a technical level. On a visual level also +1 because I hate that drop shadow with a fierce passion.
@leinir lxr says a similar thumb is also used for some of the KAboutPerson stuff in kxmlgui. it may be prudent to also remove the thumb there, I expect it looks equally dated.
LGTM on a technical level. On a visual level also +1 because I hate that drop shadow with a fierce passion.
In D20693#454733, @ndavis wrote:+1 for the change to the large thumbnail, but I think the smaller thumbnails need something to show that they can be clicked.
+1 for the change to the large thumbnail, but I think the smaller thumbnails need something to show that they can be clicked.
Adding VDG because this is a visual change. To the visual commenters: This is intended as a first step, removing the old drop-shadow method (see also the related bug for a more severe version of that drop-shadow being shown very incorrectly). If we decide we do want a drop shadow, then that will want to be done separately. Note also that as we cannot guarantee the image will not have any translucent areas (which is the cause of the highly nasty look in the bug report, rather than just the basic nastiness shown in the screenshots here), we will need to do something considerably more clever than just putting a 9-slice drop image around the image (for example), which might well be a fair bit more expensive computationally than we'd probably want.
In D20693#454173, @ngraham wrote:This patch doesn't apply:
INFO Base commit is not in local repository; trying to fetch. Created and checked out branch arcpatch-D20693. Checking patch src/ui/imagepreviewwidget_p.h... Checking patch src/ui/imagepreviewwidget.cpp... Checking patch data/thumb_frame.png... error: the patch applies to 'data/thumb_frame.png' (afaf432793864e1fb3f1fc27aa1d53689f2243b5), which does not match the current contents. error: data/thumb_frame.png: patch does not apply Checking patch data/CMakeLists.txt... Applied patch src/ui/imagepreviewwidget_p.h cleanly. Applied patch src/ui/imagepreviewwidget.cpp cleanly. Applied patch data/CMakeLists.txt cleanly. Patch Failed! Usage Exception: Unable to apply patch!Also it would be helpful if you used arc for your patches, since then you can see the context here in the web UI: https://community.kde.org/Infrastructure/Phabricator#Using_Arcanist_to_post_patches
Attempt to use arcanist, hopefully with less data loss this time
Apr 22 2019
This patch doesn't apply:
Apr 20 2019
Mar 28 2019
Mar 27 2019
LGTM
Just accept any informational status as benign, rather than the specifically picked ones.
In D20077#439290, @apol wrote:And why are 101 and 102 bad?
Should we just accept between 100 and 200?
And why are 101 and 102 bad?
Should we just accept between 100 and 200?
Mar 20 2019
We'll see I guess.
Mar 19 2019
Mar 18 2019
In D19858#433788, @ngraham wrote:Thanks! Makes sense, and fixes the bug. :)
Of course the underlying issue is still present. If you can't vote from the GHNS dialogs, there shouldn't be a UI for let you try; it should be strictly read-only. I suppose that's a separate matter though.
Thanks! Makes sense, and fixes the bug. :)
Copypasta error... thanks Nate :)
Mar 14 2019
Mar 13 2019
Works great, thanks.
Quick ping, be good to get this in sometime before it becomes late again... :)
Mar 4 2019
Since 5.57, not 5.56
Feb 27 2019
In D19338#420303, @apol wrote:+1 cool stuff!
this opens the possibility for files being both in /usr and /etc, can you make sure hell doesn't break loose when that happens?
Was these files look up was delegated entirely to KConfig?
Feb 26 2019
+1 cool stuff!
Feb 12 2019
Feb 8 2019
Conceptually this makes sense, provided we can rely on content.isValid() returning valid results. :)
Swap the logic around a bit, makes for an easier to read patch and whatnot.
I guess the patch makes sense overall.
Feb 7 2019
Jan 12 2019
In D18038#391684, @ngraham wrote:Thanks, in addition to the testing tool working, this patch seems to actually fix the issue in production (e.g. "Tree on Island" is no longer visible in the wallpaper downloader), and as far as I can tell the code is sane. Thanks for the additional documentation and commenting too.
Should this be marked as actually fixing 402888? If so, it should be BUG: 402888
Jan 11 2019
Thanks, in addition to the testing tool working, this patch seems to actually fix the issue in production (e.g. "Tree on Island" is no longer visible in the wallpaper downloader), and as far as I can tell the code is sane. Thanks for the additional documentation and commenting too.
In D18038#390748, @ngraham wrote:What is the test tool? Can you help a total n00b like me learn how to test KNewStuff patches like these?
Jan 10 2019
What is the test tool? Can you help a total n00b like me learn how to test KNewStuff patches like these?