If the checkbox is activated, the control widget in the upper right corner shows that it is in play mode. Pressing the play/pause button does not change anything.
What should happen if the user clicks on the play/pause button when the checkbox is activated?
Since the user doesn't want the animations, I think the control widget should be in pause mode or are there any other functionality to implement?
Patch works but we still have to polish something.
Please use if (... not if(...
NUM_CHANNELS == 5, look again at line 1158 of imagecurves.cpp
As I wrote here (https://bugs.kde.org/show_bug.cgi?id=124788#c5) I find the solution with the CheckBox not so good.
PS: I just now found the same in core/dplugins/generic/webservices/unified/wizard/wsauthenticationpage.cpp, but that isn't compiled currently.
Fix applied with commit : https://commits.kde.org/digikam/dbc7b17f4d61fda327f273e30a85c8d59c913a16
Ok, thank you, I confused the review board and phabricator.
In D17276#369354, @mqualmann wrote:Close with REVIEW: D17276 was not successful.
remote: https://commits.kde.org/digikam/60721615dd9af2b81dacce06adaa7e31d56eee32
remote: ERROR - Communication problem with Reviewboard. Please contact the KDE sysadmins.
remote: INFO - Please report the following:
remote: INFO - Request URL: https://git.reviewboard.kde.org/api/review-requests/17276/
remote: INFO - Status code: 404Maik
Close with REVIEW: D17276 was not successful.
In D17276#369265, @cgilles wrote:No, welcome page view is not present in Showfoto. Only the geolocation view. So the patch must be applied too to Showfoto::main().
Apply the same change to showfoto as well.
In Showfoto the problem may not occur well, but I will try to solve the problem in another way.
No, welcome page view is not present in Showfoto. Only the geolocation view. So the patch must be applied too to Showfoto::main().
I can reproduce the problem, although I always use QWebEngine, I had never noticed it before.
The patch works fine, also with the geolocation.
In D17276#369166, @cgilles wrote:Did you test this king of patch with the geolocation view, in GoogleMaps mode which use also QWebEngine ?
Note : you patch the digiKam main(). Showfoto main() need also to be patched as it can show the Geolocation view in GoogleMaps mode.
Did you test this king of patch with the geolocation view, in GoogleMaps mode which use also QWebEngine ?
Removed dependency on QStringView
Updated diff to the newest master
In T9226#151961, @rkflx wrote:@nicolasfella Speaking for Gwenview: That sounds just like an idea I had a couple of months ago (I might even have mentioned it here and there). However, in the meantime I read more of the codebase and realized it's not as easy as it sounds.
From a high-level view it makes sense, but once you dig into the interaction details and also how tightly this integrates with the rest of the codebase (thumbnailing, custom sorting and filtering models, optimized image grid, integration with the data models used in other parts, reuse for the thumbnail strip etc.), you'll find that there are features unique to Gwenview. It's not just Dolphin with thumbnails turned on and a darker background.
@nicolasfella Speaking for Gwenview: That sounds just like an idea I had a couple of months ago (I might even have mentioned it here and there). However, in the meantime I read more of the codebase and realized it's not as easy as it sounds.
You can have a situation where name.tif has tag A and name.dng tag B. With name.xmp scheme the information in the database will then be inconsistent with the information in the file. It is essentially a race which is written to xmp first, i.e. when writing information from db to file metadata, whether name.xmp ends up with tag A or B is random. I don't know whether it will create problems with the execution, but I wouldn't be surprised.
A simple way to minimize this risk would be to only allow "name.xmp" scheme when the option to write to xmp for raw formats only is checked. Unless someone converts from native raw to dng it is rather unlikely, that there will be a naming conflict.
Do we have to handle/prevent/... that case? As a user, I'm totally fine with having to handle that myself, if that means I get a pretty straightforward way to interact with the programs that I use.
As far as I see this does not handle/prevent/... the case where there is two different files with the same name but different extensions (e.g. name.dng and name.tif) - am I missing something?
Thanks!
Was committed by R482:0c7e25df54de.
Thanks Ben. It's my fault (:=)))
You can spread http://download.kde.org/stable/digikam/digikam-5.6.0-01-i386.appimage.mirrorlist as soon as it shows some mirrors.
You can spread http://download.kde.org/stable/digikam/digikam-5.6.0-01-x86-64.appimage.mirrorlist as soon as it shows some mirrors.
You can spread http://download.kde.org/stable/digikam/digiKam-5.6.0-01-MacOS-x86-64.pkg.mirrorlist as soon as it shows some mirrors.
You can spread http://download.kde.org/stable/digikam/digiKam-5.6.0-01-Win64.exe.mirrorlist as soon as it shows some mirrors.
You can spread http://download.kde.org/stable/digikam/digiKam-5.6.0-01-Win32.exe.mirrorlist as soon as it shows some mirrors.
Please use "New Sysadmin Task" to enter tasks for Sysadmin.
This task was not seen as a result.
Please use "New Sysadmin Task" to enter tasks for Sysadmin.
This task was not seen as a result.
Please use "New Sysadmin Task" to enter tasks for Sysadmin.
This task was not seen as a result.
Please use "New Sysadmin Task" to enter tasks for Sysadmin.
This task was not seen as a result.
Please use "New Sysadmin Task" to enter tasks for Sysadmin.
This task was not seen as a result.
This request was posted few day ago and it's not yet published. Why ? We need to release 5.6.0 now...
This request was posted few day ago and it's not yet published. Why ? We need to release 5.6.0 now...
This request was posted few day ago and it's not yet published. Why ? We need to release 5.6.0 now...
This request was posted few day ago and it's not yet published. Why ? We need to release 5.6.0 now...
This request was posted few day ago and it's not yet published. Why ? We need to release 5.6.0 now...
As you may have noted, the digiKam project isn't (yet?) active on Phabricator. To get feedback, open an issue in bugzilla (maybe linking here).
I don't know anything about QML and almost nothing about KIPI, so can't really be of help.