I'm a bit confused by the bug this is fixing. Surely this doesn't happen to all cases of crashes without autorestart enabled??
Makes sense; just two minor things.
Mark stale command as done.
- Use std::function to store a generator function for m_setXattrCmd's arguments.
Update to new Solid::Device::DisplayName
Change remove_if and copy to copy_if, per suggestion
Tue, May 26
updated libssh to use version 0.9.4 by default in Craft. We can merge this and get 🟢 for kio-extras builds. \o/
You can try to install one from your distro to check the actual content. index.theme is generated during the "configure & make".
PIM has been fully adapted meanwhile, only https://phabricator.kde.org/D29478 missing I think.
Hi @ngraham Thanks for letting me know! I've opened the PR over on gitlab: https://invent.kde.org/frameworks/kwallet/-/merge_requests/1. It must be quite a mission getting everyone over to new platforms 😓 😄
Thank you for committing! Although I recently gained push rights, I did not have time yet to dig into the details of how to create/push commit respecting the KDE standards etc. Next time, I'll try on my own :)
Here's where the spec lives, FWIW: https://gitlab.freedesktop.org/xdg/xdg-specs
Thanks for the patch! FWIW we have moved patch review to GitLab; consider abandoning this and re-submitting it as a merge request at https://invent.kde.org/frameworks/kwallet/-/merge_requests
This stack overflow answer has a more exhaustive approach to determining endianness. It may be worth extracting this code into a more appropriate header file though. Also here's the issue on the bugzilla tracker
Mon, May 25
Looking at D28915, seems you are only collecting to earn push rights so far :), so going to push for you with the author info taken from there.
How would we add the separator role to color scheme files if separator color was added to upstream Qt? Wouldn't we still need to add a separator role to KColorScheme so that we could map the color in the color scheme file to the equivalent QPalette ColorRole?
The approach makes sense then. I agree that making high DPI a part of the FDO spec would be nice, but IMO that shouldn't block this. The approach currently taken is logical and it could be submitted as an extension to the spec later.
Wait @davidedmundson to accept it.
Do I need to change anything or is this acceptable?
@meven Have you already got in contact with the other users/maintainers of he thumnbail cache spec about the idea to extend it with support for high dpi? If not, please consider to do so, so things will also work cross-toolkit/platforms in the future there, by being based on an agreed & formalized specification. Not being involved here or having full understanding of the topic, but I would guess your approach with the separate x2 should run into "make sense" responses, so the additional effort might be low for the gain of being based on an official spec.
The patch currently does not work.
Sun, May 24
Overall seems sane. Two questions though: