digikam 4.1 bugs
Locked
 
|
Hi,
I finally got an update to digikam 4.1, and it feels fast and nice. However, within the editor, some bugs resist, notacibly the problem with preview sizes seems to persist.' This problem is very odd, it does not affect all tools, and the behavior is not consistent, sometimes the order of tools used affects the behavior. After conversion from RAW, using the curve tool, the initial preview is missized, on my screen it is set to 12%, which may be the preview size in the album view, with two sidebars visible. In my opinion, if the size in the editor is "fit to window size", this setting should be sticky when activating tools (whatever setting in the editor window should stick, in fact). Another problem is with the preview of the effect of a tool. I use consequently "mouse over" type preview, and Since 4.0, I have to move the mouse into the preview and out again to see the preview, which was not the case in 3.6 - a regression :0 Let me know, if I should rather file explicit bugs than explaining here! -- kindly, Anders _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
2014-07-21 16:07 GMT+02:00 Anders Lund <[hidden email]>:
> Hi, > > I finally got an update to digikam 4.1, and it feels fast and nice. > > However, within the editor, some bugs resist, notacibly the problem with > preview sizes seems to persist.' > > This problem is very odd, it does not affect all tools, and the behavior is not > consistent, sometimes the order of tools used affects the behavior. > > After conversion from RAW, using the curve tool, the initial preview is > missized, on my screen it is set to 12%, which may be the preview size in the > album view, with two sidebars visible. > > In my opinion, if the size in the editor is "fit to window size", this setting > should be sticky when activating tools (whatever setting in the editor window > should stick, in fact). It must and it work as expected here. I suspect a race condition with signals and slots when code if compile in final release. I supose that you install digiKam using a pre-compiled package. Right ? Here, i'm in full debug mode, which introduce some small time latencies. which is enough to mask this kind of problem. > > Another problem is with the preview of the effect of a tool. I use consequently > "mouse over" type preview, and Since 4.0, I have to move the mouse into the > preview and out again to see the preview, which was not the case in 3.6 - a > regression :0 > Yes, fully reproducible here. I use always this mode. It's in my TODO list. > Let me know, if I should rather file explicit bugs than explaining here! Look how is compile digiKam. Go to help/About dialog. Gilles Caulier _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
On Mandag den 21. juli 2014 18:19:52, Gilles Caulier wrote:
> 2014-07-21 16:07 GMT+02:00 Anders Lund <[hidden email]>: > > Hi, > > > > I finally got an update to digikam 4.1, and it feels fast and nice. > > > > However, within the editor, some bugs resist, notacibly the problem with > > preview sizes seems to persist.' > > > > This problem is very odd, it does not affect all tools, and the behavior > > is not consistent, sometimes the order of tools used affects the > > behavior. > > > > After conversion from RAW, using the curve tool, the initial preview is > > missized, on my screen it is set to 12%, which may be the preview size in > > the album view, with two sidebars visible. > > > > In my opinion, if the size in the editor is "fit to window size", this > > setting should be sticky when activating tools (whatever setting in the > > editor window should stick, in fact). > > It must and it work as expected here. Well, it does not here. Several tools shows a wrong size initially. Some corrects the size after a moment, some does not, some inflicts the wrong size on the main editor window. Sometimes, as said, the displayed size depends on order of tools. How can this depend on signals and slots??? Doesn't it just get the size from the main editor window? Right now, my editor window claims that a "fit to window" image is at 14%, but the editor tools still appears to prefer 12%. Can some configuration value affect this? > I suspect a race condition with signals and slots when code if compile > in final release. I supose that you install digiKam using a > pre-compiled package. Right ? I'm using chakra packages compiled against kde 4.13.2 "optimized by the chakra team". > Here, i'm in full debug mode, which introduce some small time > latencies. which is enough to mask this kind of problem. > > > Another problem is with the preview of the effect of a tool. I use > > consequently "mouse over" type preview, and Since 4.0, I have to move the > > mouse into the preview and out again to see the preview, which was not > > the case in 3.6 - a regression :0 > > Yes, fully reproducible here. I use always this mode. It's in my TODO list. Wonderful, I look forward to seing that one go away :-) > > Let me know, if I should rather file explicit bugs than explaining here! > > Look how is compile digiKam. Go to help/About dialog. See above. Kindly, Anders > Gilles Caulier > _______________________________________________ > Digikam-users mailing list > [hidden email] > https://mail.kde.org/mailman/listinfo/digikam-users -- Anders _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
In reply to this post by Gilles Caulier-4
On Mandag den 21. juli 2014 18:19:52, Gilles Caulier wrote:
> It must and it work as expected here. Typical situation, difficult to make this go away :-( If you mean that it must work, you are simply wrong. Somewhere, there is a bug in the code, allowing it to NOT work. http://owncloud.alweb.dk/public.php?service=files&t=542a34aa8b77ff74ac2b2043ef3c2693 -- Anders _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
In reply to this post by Gilles Caulier-4
On Mandag den 21. juli 2014 18:19:52, Gilles Caulier wrote:
> Here, i'm in full debug mode, which introduce some small time > latencies. which is enough to mask this kind of problem. I don't think it is smart to require digikam being compiled in full debug mode to work correctly! -- Anders _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
On Monday 28 July 2014 11:03:49 Anders Lund wrote:
> On Mandag den 21. juli 2014 18:19:52, Gilles Caulier wrote: > > Here, i'm in full debug mode, which introduce some small time > > latencies. which is enough to mask this kind of problem. > > I don't think it is smart to require digikam being compiled in full debug mode > to work correctly! > > Gilles is not saying that you are required to build digikam in full debug mode, just that that is what he does, and that the build mode could change timings enough so that certain race conditions don't become visible (or much less often). That does not mean the races aren't there, just that they don't become visible. And that's typically the kind of bugs that you can get when switching to multithreaded, and they are particularly hard to debug... _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
On Mandag den 28. juli 2014 11:51:55, Remco Viëtor wrote:
> On Monday 28 July 2014 11:03:49 Anders Lund wrote: > > On Mandag den 21. juli 2014 18:19:52, Gilles Caulier wrote: > > > Here, i'm in full debug mode, which introduce some small time > > > latencies. which is enough to mask this kind of problem. > > > > I don't think it is smart to require digikam being compiled in full debug > > mode > > > to work correctly! > > Gilles is not saying that you are required to build digikam in full debug > mode, just that that is what he does, and that the build mode could change > timings enough so that certain race conditions don't become visible (or > much less often). That does not mean the races aren't there, just that they > don't become visible. > > And that's typically the kind of bugs that you can get when switching to > multithreaded, and they are particularly hard to debug... If I can do anything to help, I will. I can install debug package etc, or even try to build digikam locally, if it can help :) -- Anders _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
I haven't followed the thread completely but my question is whether the preview bug has been satisfactorily fixed in 4.1. I gave up on using 4.x because of this problem. No offense intended but this is a 'major' bug to have in a stable release and still in an update to the stable release. For me it made the application more or less unusable.
I had the problem with 4.0 on Gentoo Linux, compiling against the latest unstable kde and opencv libraries, which included opencv 2.4.9. I still had the problem after I built my own package for 4.1 and built against the same libraries. On Fedora I had the same problem with Digikam 4.0. I used another repository to install 4.1 and the problem still persists. Fedora developers are trying to get opencv 2.9 into the repository and indicating this will fix the problem. I'm not sure I've really seen that explained here. Is this really a fix for the preview problem? Thanks, Vern ________________________________________ From: [hidden email] [[hidden email]] on behalf of Anders Lund [[hidden email]] Sent: Monday, July 28, 2014 5:56 AM To: digiKam - Home Manage your photographs as a professional with the power of open source Subject: Re: [Digikam-users] digikam 4.1 bugs On Mandag den 28. juli 2014 11:51:55, Remco Viëtor wrote: > On Monday 28 July 2014 11:03:49 Anders Lund wrote: > > On Mandag den 21. juli 2014 18:19:52, Gilles Caulier wrote: > > > Here, i'm in full debug mode, which introduce some small time > > > latencies. which is enough to mask this kind of problem. > > > > I don't think it is smart to require digikam being compiled in full debug > > mode > > > to work correctly! > > Gilles is not saying that you are required to build digikam in full debug > mode, just that that is what he does, and that the build mode could change > timings enough so that certain race conditions don't become visible (or > much less often). That does not mean the races aren't there, just that they > don't become visible. > > And that's typically the kind of bugs that you can get when switching to > multithreaded, and they are particularly hard to debug... If I can do anything to help, I will. I can install debug package etc, or even try to build digikam locally, if it can help :) -- Anders _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
On Mandag den 28. juli 2014 12:39:00, Wilkins, Vern W wrote:
> I haven't followed the thread completely but my question is whether the > preview bug has been satisfactorily fixed in 4.1. I gave up on using 4.x > because of this problem. No offense intended but this is a 'major' bug to > have in a stable release and still in an update to the stable release. For > me it made the application more or less unusable. The preview problems are about the same in 4.1. > I had the problem with 4.0 on Gentoo Linux, compiling against the latest > unstable kde and opencv libraries, which included opencv 2.4.9. I still > had the problem after I built my own package for 4.1 and built against the > same libraries. > > On Fedora I had the same problem with Digikam 4.0. I used another > repository to install 4.1 and the problem still persists. Fedora > developers are trying to get opencv 2.9 into the repository and indicating > this will fix the problem. I'm not sure I've really seen that explained > here. Is this really a fix for the preview problem? > > Thanks, > Vern > ________________________________________ > From: [hidden email] [[hidden email]] on > behalf of Anders Lund [[hidden email]] Sent: Monday, July 28, 2014 5:56 AM > To: digiKam - Home Manage your photographs as a professional with the power > of open source Subject: Re: [Digikam-users] digikam 4.1 bugs > > On Mandag den 28. juli 2014 11:51:55, Remco Viëtor wrote: > > On Monday 28 July 2014 11:03:49 Anders Lund wrote: > > > On Mandag den 21. juli 2014 18:19:52, Gilles Caulier wrote: > > > > Here, i'm in full debug mode, which introduce some small time > > > > latencies. which is enough to mask this kind of problem. > > > > > > I don't think it is smart to require digikam being compiled in full > > > debug > > > > mode > > > > > to work correctly! > > > > Gilles is not saying that you are required to build digikam in full debug > > mode, just that that is what he does, and that the build mode could change > > timings enough so that certain race conditions don't become visible (or > > much less often). That does not mean the races aren't there, just that > > they > > don't become visible. > > > > And that's typically the kind of bugs that you can get when switching to > > multithreaded, and they are particularly hard to debug... > > If I can do anything to help, I will. I can install debug package etc, or > even try to build digikam locally, if it can help :) > > > -- > Anders > _______________________________________________ > Digikam-users mailing list > [hidden email] > https://mail.kde.org/mailman/listinfo/digikam-users > _______________________________________________ > Digikam-users mailing list > [hidden email] > https://mail.kde.org/mailman/listinfo/digikam-users -- Anders _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
Am 28.07.2014 14:42, schrieb Anders Lund: > On Mandag den 28. juli 2014 12:39:00, Wilkins, Vern W wrote: >> I haven't followed the thread completely but my question is whether the >> preview bug has been satisfactorily fixed in 4.1. I gave up on using 4.x >> because of this problem. No offense intended but this is a 'major' bug to >> have in a stable release and still in an update to the stable release. For >> me it made the application more or less unusable. > > The preview problems are about the same in 4.1. > >> I had the problem with 4.0 on Gentoo Linux, compiling against the latest >> unstable kde and opencv libraries, which included opencv 2.4.9. I still >> had the problem after I built my own package for 4.1 and built against the >> same libraries. >> >> On Fedora I had the same problem with Digikam 4.0. I used another >> repository to install 4.1 and the problem still persists. Fedora >> developers are trying to get opencv 2.9 into the repository and indicating >> this will fix the problem. I'm not sure I've really seen that explained >> here. Is this really a fix for the preview problem? >> >> Thanks, >> Vern Just to add a "me too" for opensuse 12.3 rpm. I had to go back to 3.2 (the last rpm I found) because 4.x was not usable for me... Daniel -- Daniel Bauer photographer Basel Barcelona professional photography: http://www.daniel-bauer.com google+: https://plus.google.com/109534388657020287386 _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
Hi
I'm back to this entry. I recompiled whole digiKam 4.2.0 in 'release with debug symbol'. It's usually used to package binary. The problem is not reproducible here. Can you : 1/ Look in Help/About dialog. There is a "Build Date" info where target compilation option is printed. Which one do you have (mine is "relwithdebinfo") 2/ Use a cellular and record a video sequence from screen with all actions done to reproduce the problem 3/ Share files used to reproduce the problem in editor. Gilles Caulier 2014-07-28 17:34 GMT+02:00 Daniel Bauer <[hidden email]>: > > > Am 28.07.2014 14:42, schrieb Anders Lund: > >> On Mandag den 28. juli 2014 12:39:00, Wilkins, Vern W wrote: >>> >>> I haven't followed the thread completely but my question is whether the >>> preview bug has been satisfactorily fixed in 4.1. I gave up on using 4.x >>> because of this problem. No offense intended but this is a 'major' bug >>> to >>> have in a stable release and still in an update to the stable release. >>> For >>> me it made the application more or less unusable. >> >> >> The preview problems are about the same in 4.1. >> >>> I had the problem with 4.0 on Gentoo Linux, compiling against the latest >>> unstable kde and opencv libraries, which included opencv 2.4.9. I still >>> had the problem after I built my own package for 4.1 and built against >>> the >>> same libraries. >>> >>> On Fedora I had the same problem with Digikam 4.0. I used another >>> repository to install 4.1 and the problem still persists. Fedora >>> developers are trying to get opencv 2.9 into the repository and >>> indicating >>> this will fix the problem. I'm not sure I've really seen that explained >>> here. Is this really a fix for the preview problem? >>> >>> Thanks, >>> Vern > > > Just to add a "me too" for opensuse 12.3 rpm. > > I had to go back to 3.2 (the last rpm I found) because 4.x was not usable > for me... > > Daniel > -- > Daniel Bauer photographer Basel Barcelona > professional photography: http://www.daniel-bauer.com > google+: https://plus.google.com/109534388657020287386 > > _______________________________________________ > Digikam-users mailing list > [hidden email] > https://mail.kde.org/mailman/listinfo/digikam-users Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
Note : i tried to compile in "release" mode where all debugs symbols
are dropped. digiKam is more faster. Problem is not reproducible. Gilles Caulier 2014-08-05 18:02 GMT+02:00 Gilles Caulier <[hidden email]>: > Hi > > I'm back to this entry. > > I recompiled whole digiKam 4.2.0 in 'release with debug symbol'. It's > usually used to package binary. > > The problem is not reproducible here. > > Can you : > > 1/ Look in Help/About dialog. There is a "Build Date" info where > target compilation option is printed. Which one do you have (mine is > "relwithdebinfo") > > 2/ Use a cellular and record a video sequence from screen with all > actions done to reproduce the problem > > 3/ Share files used to reproduce the problem in editor. > > Gilles Caulier > > 2014-07-28 17:34 GMT+02:00 Daniel Bauer <[hidden email]>: >> >> >> Am 28.07.2014 14:42, schrieb Anders Lund: >> >>> On Mandag den 28. juli 2014 12:39:00, Wilkins, Vern W wrote: >>>> >>>> I haven't followed the thread completely but my question is whether the >>>> preview bug has been satisfactorily fixed in 4.1. I gave up on using 4.x >>>> because of this problem. No offense intended but this is a 'major' bug >>>> to >>>> have in a stable release and still in an update to the stable release. >>>> For >>>> me it made the application more or less unusable. >>> >>> >>> The preview problems are about the same in 4.1. >>> >>>> I had the problem with 4.0 on Gentoo Linux, compiling against the latest >>>> unstable kde and opencv libraries, which included opencv 2.4.9. I still >>>> had the problem after I built my own package for 4.1 and built against >>>> the >>>> same libraries. >>>> >>>> On Fedora I had the same problem with Digikam 4.0. I used another >>>> repository to install 4.1 and the problem still persists. Fedora >>>> developers are trying to get opencv 2.9 into the repository and >>>> indicating >>>> this will fix the problem. I'm not sure I've really seen that explained >>>> here. Is this really a fix for the preview problem? >>>> >>>> Thanks, >>>> Vern >> >> >> Just to add a "me too" for opensuse 12.3 rpm. >> >> I had to go back to 3.2 (the last rpm I found) because 4.x was not usable >> for me... >> >> Daniel >> -- >> Daniel Bauer photographer Basel Barcelona >> professional photography: http://www.daniel-bauer.com >> google+: https://plus.google.com/109534388657020287386 >> >> _______________________________________________ >> Digikam-users mailing list >> [hidden email] >> https://mail.kde.org/mailman/listinfo/digikam-users Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
«
Return to digikam-users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |