https://bugs.kde.org/show_bug.cgi?id=399600
--- Comment #14 from Maik Qualmann ---
If a collection is not online, we now have an error icon for the respective
collection in the album view.
We could also show this icon if the collection is online but not writable. For
each album individually this
https://bugs.kde.org/show_bug.cgi?id=399600
caulier.gil...@gmail.com changed:
What|Removed |Added
Version|6.0.0 |8.4.0
--
You are receiving this mail
https://bugs.kde.org/show_bug.cgi?id=399600
--- Comment #13 from MarcP ---
Hi, yes, I think this behavior has not changed.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=399600
--- Comment #12 from caulier.gil...@gmail.com ---
Hi all,
The digiKam 8.4.0 Appimage bundle pre-release is now based on last modern
frameworks Qt 6.7.0 and KDE 6.2.0.
File can be downloaded at usual place : https://files.kde.org/digikam/
Take a care :
https://bugs.kde.org/show_bug.cgi?id=399600
--- Comment #11 from caulier.gil...@gmail.com ---
Marc,
What's about this file using current 8.2.0 AppImage Linux bundle ? It's
reproducible ?
https://files.kde.org/digikam/
Note: bundle is now based on Qt 5.15.11 and KDE framework 5.110.
Thanks in
https://bugs.kde.org/show_bug.cgi?id=399600
--- Comment #10 from caulier.gil...@gmail.com ---
@MarcP,
digiKam 8.0.0 is out. This entry still valid with this release ?
Best regards
Gilles Caulier
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=399600
--- Comment #9 from MarcP ---
Behavior still present. Digikam is not aware if a file is read-only when
writing metadata and just assumes it has been written correctly.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=399600
--- Comment #8 from caulier.gil...@gmail.com ---
digiKam 7.0.0 stable release is now published and now available as FlatPak:
https://www.digikam.org/news/2020-07-19-7.0.0_release_announcement/
We need a fresh feedback on this file using this version.
https://bugs.kde.org/show_bug.cgi?id=399600
--- Comment #7 from caulier.gil...@gmail.com ---
After 3 weeks of work, i finally completed the compilation of AppImage using Qt
5.11.3 + QWebkit 5.212.
New 6.1.0 pre-release AppImage bundle can be found here (64 bits only for the
moment) :
https://fil
https://bugs.kde.org/show_bug.cgi?id=399600
--- Comment #6 from IWBR ---
Of course, re-reading the metadata from the images after changes should only
occur if the option is checked (I suppose now it only detects external changes,
right?). I actually manually re-read pictures after changes since d
https://bugs.kde.org/show_bug.cgi?id=399600
--- Comment #5 from Maik Qualmann ---
No, it does not work. For example, I have all my tags and all changes only in
the database and also changed date. Therefore, re-reading and cleaning up the
database before re-reading is also optional. And re-reading
https://bugs.kde.org/show_bug.cgi?id=399600
--- Comment #4 from IWBR ---
Well, yep, it's based on this bug, but here I focus on the fact that the
library can differ from the picture metadata because digikam (and users) thinks
these changes have been applied when they have not.
For instance, imag
https://bugs.kde.org/show_bug.cgi?id=399600
Maik Qualmann changed:
What|Removed |Added
CC||metzping...@gmail.com
--- Comment #3 from Maik
https://bugs.kde.org/show_bug.cgi?id=399600
--- Comment #2 from IWBR ---
No no, if a library is read only, of course there's no way of changing that. I
meant that at least showing a warning when a file could not be modified would
be helpful.
I understand digikam is not responsible for other peop
https://bugs.kde.org/show_bug.cgi?id=399600
caulier.gil...@gmail.com changed:
What|Removed |Added
CC||caulier.gil...@gmail.com
--- Comment
https://bugs.kde.org/show_bug.cgi?id=399600
IWBR changed:
What|Removed |Added
CC||iwannaber...@gmail.com
--
You are receiving this mail b
16 matches
Mail list logo
