Discussion:
[KPhotoAlbum] Multi-image annotation dialog annoyance
Robert Krawitz
2016-11-06 16:54:19 UTC
Permalink
When annotating multiple images (ctrl-2 in thumbnail mode, for
example), the dialog flashes each image up briefly in turn, which is
both distracting and makes the dialog unusable until I close the image
preview widget in the dialog. This started around the KDE5 cutover.
--
Robert Krawitz <***@alum.mit.edu>

*** MIT Engineers A Proud Tradition http://mitathletics.com ***
Member of the League for Programming Freedom -- http://ProgFree.org
Project lead for Gutenprint -- http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton
Tobias Leupold
2016-11-06 18:40:57 UTC
Permalink
Hi Robert!

I don't see this with the current 5.0.1 release. Can you reproduce it with
this version?

Cheers, Tobias
Post by Robert Krawitz
When annotating multiple images (ctrl-2 in thumbnail mode, for
example), the dialog flashes each image up briefly in turn, which is
both distracting and makes the dialog unusable until I close the image
preview widget in the dialog. This started around the KDE5 cutover.
Reimar Imhof
2016-11-06 19:36:02 UTC
Permalink
Hi Tobias,

I'm seeing the same problem here for example with the kphotoalbum demo
pictures.
Start demo, select all pictures (ctrl-a), annotate multiple (here all) images
(ctrl-2).

kphotoalbum 5.0.1, openSuse leap 42.2 rc2.

Cheers,
Reimar
Post by Tobias Leupold
Hi Robert!
I don't see this with the current 5.0.1 release. Can you reproduce it with
this version?
Cheers, Tobias
Post by Robert Krawitz
When annotating multiple images (ctrl-2 in thumbnail mode, for
example), the dialog flashes each image up briefly in turn, which is
both distracting and makes the dialog unusable until I close the image
preview widget in the dialog. This started around the KDE5 cutover.
_______________________________________________
KPhotoAlbum mailing list
https://mail.kdab.com/mailman/listinfo/kphotoalbum
Reimar Imhof
2016-11-06 19:44:58 UTC
Permalink
Hi Tobias,

I gave it another test with annotating single picutures (ctrl-1).
Again using the kphotoalbum demo.
Select all pictures, press Ctrl-1
Dialog opens ok. Then switching to next picture triggers flashing.

Cheers,
Reimar
Post by Reimar Imhof
Hi Tobias,
I'm seeing the same problem here for example with the kphotoalbum demo
pictures.
Start demo, select all pictures (ctrl-a), annotate multiple (here all)
images (ctrl-2).
kphotoalbum 5.0.1, openSuse leap 42.2 rc2.
Cheers,
Reimar
Post by Tobias Leupold
Hi Robert!
I don't see this with the current 5.0.1 release. Can you reproduce it with
this version?
Cheers, Tobias
Post by Robert Krawitz
When annotating multiple images (ctrl-2 in thumbnail mode, for
example), the dialog flashes each image up briefly in turn, which is
both distracting and makes the dialog unusable until I close the image
preview widget in the dialog. This started around the KDE5 cutover.
_______________________________________________
KPhotoAlbum mailing list
https://mail.kdab.com/mailman/listinfo/kphotoalbum
_______________________________________________
KPhotoAlbum mailing list
https://mail.kdab.com/mailman/listinfo/kphotoalbum
Johannes Zarl-Zierl
2016-11-06 20:18:48 UTC
Permalink
Hi,
Post by Reimar Imhof
I gave it another test with annotating single picutures (ctrl-1).
Again using the kphotoalbum demo.
Select all pictures, press Ctrl-1
Dialog opens ok. Then switching to next picture triggers flashing.
I could not reproduce this, either.

This leaves me a bit uneasy: two people independently having the problem, with
pretty clear and easy instructions how to reproduce it. Yet neither I nor
Tobias being able to reproduce it :(

Does your setup include anything unusual/noteworthy that might be of interest?
Did you change the default shortcuts? (Just to make a pretty wild guess)


Johannes
Tobias Leupold
2016-11-06 20:26:17 UTC
Permalink
Post by Johannes Zarl-Zierl
I could not reproduce this, either.
Okay, at least, I'm not too dumb to follow simple instructions ;-)
Post by Johannes Zarl-Zierl
This leaves me a bit uneasy
Me too ...

Perhaps something about Qt versions? I have 5.6.1 ...

Didn't we have some flickering problem at some point that was due to the
KDialog --> QDialog transition?
Reimar Imhof
2016-11-06 20:45:53 UTC
Permalink
Hi,

I've tried suse rpm from
http://download.opensuse.org/repositories/KDE:/Extra/openSUSE_Leap_42.2/x86_64/kphotoalbum-5.0.1-6.1.x86_64.rpm

I've also tried to rebuild the rpm.

And I tried to compile it in kdevelop.

Every binary has that flash problem.

I tried it within virtualbox and on a real machine using a live iso from
http://netcologne.dl.sourceforge.net/project/kamarada/distribution/leap/42.2-RC2/openSUSE-Leap-42.2-RC2-KDE-Live.x86_64-20161103.iso

Version info
KDE Frameworks 5.26.0
Qt 5.6.1 (kompiliert gegen 5.6.1)
Das xcb Fenstersystem

Cheers,
Reimar
Post by Tobias Leupold
Post by Johannes Zarl-Zierl
I could not reproduce this, either.
Okay, at least, I'm not too dumb to follow simple instructions ;-)
Post by Johannes Zarl-Zierl
This leaves me a bit uneasy
Me too ...
Perhaps something about Qt versions? I have 5.6.1 ...
Didn't we have some flickering problem at some point that was due to the
KDialog --> QDialog transition?
_______________________________________________
KPhotoAlbum mailing list
https://mail.kdab.com/mailman/listinfo/kphotoalbum
Johannes Zarl-Zierl
2016-11-06 22:24:15 UTC
Permalink
Hi,

I've tried with again with a KDE neon vm I had lying around. There is a
different bug there that causes the preview image to flicker in size, but not
the one you found.
Post by Reimar Imhof
I've tried suse rpm from
http://download.opensuse.org/repositories/KDE:/Extra/openSUSE_Leap_42.2/x86_
64/kphotoalbum-5.0.1-6.1.x86_64.rpm
I've also tried to rebuild the rpm.
And I tried to compile it in kdevelop.
Every binary has that flash problem.
I'll try it on opensuse 42.2 and see if I can reproduce it there...

Cheers,
Johannes
Robert Krawitz
2016-11-07 00:52:59 UTC
Permalink
Post by Johannes Zarl-Zierl
I've tried with again with a KDE neon vm I had lying around. There
is a different bug there that causes the preview image to flicker in
size, but not the one you found.
Post by Reimar Imhof
I've tried suse rpm from
http://download.opensuse.org/repositories/KDE:/Extra/openSUSE_Leap_42.2/x86_
64/kphotoalbum-5.0.1-6.1.x86_64.rpm
I've also tried to rebuild the rpm.
And I tried to compile it in kdevelop.
Every binary has that flash problem.
I'll try it on opensuse 42.2 and see if I can reproduce it there...
I wonder whether it's a function of particular graphics adapters. I
have a Radeon HD5870 aka Juniper/Broadway XT, using the radeon (free)
driver.
--
Robert Krawitz <***@alum.mit.edu>

*** MIT Engineers A Proud Tradition http://mitathletics.com ***
Member of the League for Programming Freedom -- http://ProgFree.org
Project lead for Gutenprint -- http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton
Tobias Leupold
2016-11-07 13:40:38 UTC
Permalink
Post by Robert Krawitz
I wonder whether it's a function of particular graphics adapters. I
have a Radeon HD5870 aka Juniper/Broadway XT, using the radeon (free)
driver.
I use my CPU's graphic chip:
Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics
Controller (rev 06)
Reimar Imhof
2016-11-07 18:20:10 UTC
Permalink
Hi,

I have that problem with an old Core2Duo intel graphic "adapter".
I also have it with an install in virtualbox.

I think, it's not related to a graphics driver.

Cheers,
Reimar
Post by Tobias Leupold
Post by Robert Krawitz
I wonder whether it's a function of particular graphics adapters. I
have a Radeon HD5870 aka Juniper/Broadway XT, using the radeon (free)
driver.
Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics
Controller (rev 06)
_______________________________________________
KPhotoAlbum mailing list
https://mail.kdab.com/mailman/listinfo/kphotoalbum
Reimar Imhof
2016-11-07 20:06:19 UTC
Permalink
Hi,

I've tried a little debugging using photos from the demo annotating all images
(ctrl-2).
I put a breakpoint in
AnnotationDialog::ImagePreview::PreviewImage::set() in
/home/<user>/kdevelop/kphotoalbum-5.0.1/AnnotationDialog/ImagePreview.cpp:229

If I do so and go from one image to the next one that breakpoint gets hit over
and over again for the same file (for example spiff_2.jpeg). I can't tell how
often, but it's very often... (a hundred times???)
Sometimes the file name somehow toggles between spiff,jpeg and spiff_2.jpeg.

#0 AnnotationDialog::ImagePreview::PreviewImage::set() in
/home/<user>/kdevelop/kphotoalbum-5.0.1/AnnotationDialog/ImagePreview.cpp:229
#1 AnnotationDialog::ImagePreview::setCurrentImage() in
/home/<user>/kdevelop/kphotoalbum-5.0.1/AnnotationDialog/ImagePreview.cpp:156
#2 AnnotationDialog::ImagePreview::pixmapLoaded() in
/home/<user>/kdevelop/kphotoalbum-5.0.1/AnnotationDialog/ImagePreview.cpp:192
#3 ImageManager::AsyncLoader::customEvent() in
/home/<user>/kdevelop/kphotoalbum-5.0.1/ImageManager/AsyncLoader.cpp:186
#4 QObject::event(QEvent*)() in /usr/lib64/libQt5Core.so.5
#5 QApplicationPrivate::notify_helper(QObject*, QEvent*)() in
/usr/lib64/libQt5Widgets.so.5
#6 QApplication::notify(QObject*, QEvent*)() in /usr/lib64/libQt5Widgets.so.5
#7 QCoreApplication::notifyInternal2(QObject*, QEvent*)() in
/usr/lib64/libQt5Core.so.5
#8 QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*)() in
/usr/lib64/libQt5Core.so.5
#9 ??() in /usr/lib64/libQt5Core.so.5
#10 g_main_context_dispatch() in /usr/lib64/libglib-2.0.so.0
#11 ??() in /usr/lib64/libglib-2.0.so.0
#12 g_main_context_iteration() in /usr/lib64/libglib-2.0.so.0
#13 QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>)
() in /usr/lib64/libQt5Core.so.5
#14 QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>)() in
/usr/lib64/libQt5Core.so.5
#15 QDialog::exec()() in /usr/lib64/libQt5Widgets.so.5
#16 AnnotationDialog::Dialog::exec() in
/home/<user>/kdevelop/kphotoalbum-5.0.1/AnnotationDialog/Dialog.cpp:927
#17 AnnotationDialog::Dialog::configure() in
/home/<user>/kdevelop/kphotoalbum-5.0.1/AnnotationDialog/Dialog.cpp:735
#18 MainWindow::Window::configImages() in
/home/<user>/kdevelop/kphotoalbum-5.0.1/MainWindow/Window.cpp:438
#19 MainWindow::Window::configureImages() in
/home/<user>/kdevelop/kphotoalbum-5.0.1/MainWindow/Window.cpp:431
#20 MainWindow::Window::configureImages() in
/home/<user>/kdevelop/kphotoalbum-5.0.1/MainWindow/Window.cpp:425

Now and again I can see the size of the preview area change.
Sometimes it's empty, sometimes it shows a photo (spiff_2.jpeg).
Sometimes that photo disappears immediately - before the debugger hits the
breakpoint the next time.

I don't know if this helps - well I hope.

Cheers,
Reimar
Post by Reimar Imhof
Hi,
I have that problem with an old Core2Duo intel graphic "adapter".
I also have it with an install in virtualbox.
I think, it's not related to a graphics driver.
Cheers,
Reimar
Post by Tobias Leupold
Post by Robert Krawitz
I wonder whether it's a function of particular graphics adapters. I
have a Radeon HD5870 aka Juniper/Broadway XT, using the radeon (free)
driver.
Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated
Graphics Controller (rev 06)
_______________________________________________
KPhotoAlbum mailing list
https://mail.kdab.com/mailman/listinfo/kphotoalbum
_______________________________________________
KPhotoAlbum mailing list
https://mail.kdab.com/mailman/listinfo/kphotoalbum
Johannes Zarl-Zierl
2016-11-08 22:15:07 UTC
Permalink
Post by Reimar Imhof
Now and again I can see the size of the preview area change.
Sometimes it's empty, sometimes it shows a photo (spiff_2.jpeg).
Sometimes that photo disappears immediately - before the debugger hits the
breakpoint the next time.
I don't know if this helps - well I hope.
Can you try setting the breakpoint a little higher in the stack, at
ImagePreview::pixmapLoaded() and look at the value of
request->m_priority ?

Is the value always ImageManager::Viewer, or does it change?

Cheers,
Johannes
Reimar Imhof
2016-11-09 20:28:43 UTC
Permalink
Post by Johannes Zarl-Zierl
Post by Reimar Imhof
Now and again I can see the size of the preview area change.
Sometimes it's empty, sometimes it shows a photo (spiff_2.jpeg).
Sometimes that photo disappears immediately - before the debugger hits the
breakpoint the next time.
I don't know if this helps - well I hope.
Can you try setting the breakpoint a little higher in the stack, at
ImagePreview::pixmapLoaded() and look at the value of
request->m_priority ?
Is the value always ImageManager::Viewer, or does it change?
I couldn't see anything else - I've just seen ImageManager::Viewer
Robert Krawitz
2016-11-20 19:30:09 UTC
Permalink
Post by Robert Krawitz
Post by Johannes Zarl-Zierl
I've tried with again with a KDE neon vm I had lying around. There
is a different bug there that causes the preview image to flicker in
size, but not the one you found.
Post by Reimar Imhof
I've tried suse rpm from
http://download.opensuse.org/repositories/KDE:/Extra/openSUSE_Leap_42.2/x86_
64/kphotoalbum-5.0.1-6.1.x86_64.rpm
I've also tried to rebuild the rpm.
And I tried to compile it in kdevelop.
Every binary has that flash problem.
I'll try it on opensuse 42.2 and see if I can reproduce it there...
I wonder whether it's a function of particular graphics adapters. I
have a Radeon HD5870 aka Juniper/Broadway XT, using the radeon (free)
driver.
So a bit more information.

It isn't flashing each image in turn; it's flashing just one image.

Also, there are two buttons at the top right of each widget. The one
on the extreme right is a close button; the other one I can't figure
out, but if I click on it, the flickering stops and it displays
normally.

But I have a few other complaints about the annotation dialog:

1) If I close one of the widgets (or turn it off in the
Options/Settings dialog), it goes away, but the next time I enter
the annotation dialog, all of the default widgets come back
(i. e. I can't get rid of them permanently). I don't use the GPS
in my camera, so the map widget's useless to me (and indeed, takes
up a lot of space to display "None of the selected images contain
geographic coordinates).

2) In the image preview window, there's a button "Train face
recognition database automatically". It's grayed out, so I can't
turn it off. I don't care about face recognition, so I don't want
it at all.

Also, to the right of the next/previous buttons below the image,
there are 5 other buttons (rotate left, right, etc) which are
grayed out in multi-image mode (the positionable tags and face
recognition aren't usable at all to me even in single image mode
since I haven't configured the requisite features in my options).
Since they're completely useless in multi-image mode, should they
even be there at all?
--
Robert Krawitz <***@alum.mit.edu>

*** MIT Engineers A Proud Tradition http://mitathletics.com ***
Member of the League for Programming Freedom -- http://ProgFree.org
Project lead for Gutenprint -- http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton
Johannes Zarl-Zierl
2016-11-20 20:23:02 UTC
Permalink
Hi Robert,
Post by Robert Krawitz
So a bit more information.
It isn't flashing each image in turn; it's flashing just one image.
Also, there are two buttons at the top right of each widget. The one
on the extreme right is a close button; the other one I can't figure
out, but if I click on it, the flickering stops and it displays
normally.
Ok, that makes a difference - that is a known (albeit nasty) bug introduced
during porting to Qt5. We had thought we had fixed it, but apparently it can
still be triggered sometimes.
I'll take another look at this regression. In contrast to the multi-image
flickering I have some idea where this problem comes from...
Post by Robert Krawitz
1) If I close one of the widgets (or turn it off in the
Options/Settings dialog), it goes away, but the next time I enter
the annotation dialog, all of the default widgets come back
You need to save the window layout to make it permanent. In the annotation
dialog, select "Options…|Configure window layout…|Save current window setup".
Post by Robert Krawitz
2) In the image preview window, there's a button "Train face
recognition database automatically". It's grayed out, so I can't
turn it off. I don't care about face recognition, so I don't want
it at all.
You should not get that button if you compile without libkface. If you really
don't want it, I think it's best to remove libkf5kface-dev (on debian-style
systems; probably libkface-devel on rpm distros).
Post by Robert Krawitz
(the positionable tags and face
recognition aren't usable at all to me even in single image mode
since I haven't configured the requisite features in my options).
To use positionable tags, you need to mark one or more categories as
positionable in the categories tab in the settings dialog. Btw. you can use
positionable tags even if you don't have face detection/recognition.
Post by Robert Krawitz
Also, to the right of the next/previous buttons below the image,
there are 5 other buttons (rotate left, right, etc) which are
grayed out in multi-image mode
Since they're completely useless in multi-image mode, should they
even be there at all?
Short answer: yes.

While it would be technically possible to remove these buttons in multi-image
and search mode, the annotation dialog is already kind of messy and that would
definitely make matters worse. Besides, we have had this situation basically
forever, even more so if you take a look at the search dialog.

Cheers,
Johannes
Robert Krawitz
2016-11-20 20:46:58 UTC
Permalink
Post by Johannes Zarl-Zierl
Hi Robert,
Post by Robert Krawitz
So a bit more information.
It isn't flashing each image in turn; it's flashing just one image.
Also, there are two buttons at the top right of each widget. The one
on the extreme right is a close button; the other one I can't figure
out, but if I click on it, the flickering stops and it displays
normally.
Ok, that makes a difference - that is a known (albeit nasty) bug
introduced during porting to Qt5. We had thought we had fixed it,
but apparently it can still be triggered sometimes. I'll take
another look at this regression. In contrast to the multi-image
flickering I have some idea where this problem comes from...
OK.
Post by Johannes Zarl-Zierl
Post by Robert Krawitz
1) If I close one of the widgets (or turn it off in the
Options/Settings dialog), it goes away, but the next time I enter
the annotation dialog, all of the default widgets come back
You need to save the window layout to make it permanent. In the
annotation dialog, select "Options…|Configure window layout…|Save
current window setup".
That's awfully unintuitive (especially since you have to go through
Configure window layout..." once for each change you want to make. It
would make more sense as an actual window (not just a menu) that would
let you make your selections and then click save (or apply/save/cancel).
Post by Johannes Zarl-Zierl
Post by Robert Krawitz
2) In the image preview window, there's a button "Train face
recognition database automatically". It's grayed out, so I can't
turn it off. I don't care about face recognition, so I don't want
it at all.
You should not get that button if you compile without libkface. If
you really don't want it, I think it's best to remove
libkf5kface-dev (on debian-style systems; probably libkface-devel on
rpm distros).
This should be a runtime option, not a compile time option.
Distributions are going to compile it with libkface; it should be
possible to disable it.
Post by Johannes Zarl-Zierl
Post by Robert Krawitz
(the positionable tags and face
recognition aren't usable at all to me even in single image mode
since I haven't configured the requisite features in my options).
To use positionable tags, you need to mark one or more categories as
positionable in the categories tab in the settings dialog. Btw. you
can use positionable tags even if you don't have face
detection/recognition.
I'm not interested in using positionable tags at all, actually.
Post by Johannes Zarl-Zierl
Post by Robert Krawitz
Also, to the right of the next/previous buttons below the image,
there are 5 other buttons (rotate left, right, etc) which are
grayed out in multi-image mode
Since they're completely useless in multi-image mode, should they
even be there at all?
Short answer: yes.
While it would be technically possible to remove these buttons in
multi-image and search mode, the annotation dialog is already kind
of messy and that would definitely make matters worse. Besides, we
have had this situation basically forever, even more so if you take
a look at the search dialog.
Well, whatever -- except that there's nothing I can do in the actual
dialog to enable them, so they're a distraction.
--
Robert Krawitz <***@alum.mit.edu>

*** MIT Engineers A Proud Tradition http://mitathletics.com ***
Member of the League for Programming Freedom -- http://ProgFree.org
Project lead for Gutenprint -- http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton
Johannes Zarl-Zierl
2016-11-20 22:02:21 UTC
Permalink
Hi,
Post by Robert Krawitz
Post by Johannes Zarl-Zierl
Post by Robert Krawitz
1) If I close one of the widgets (or turn it off in the
Options/Settings dialog), it goes away, but the next time I enter
the annotation dialog, all of the default widgets come back
You need to save the window layout to make it permanent. In the
annotation dialog, select "Options…|Configure window layout…|Save
current window setup".
That's awfully unintuitive (especially since you have to go through
Configure window layout..." once for each change you want to make. It
would make more sense as an actual window (not just a menu) that would
let you make your selections and then click save (or apply/save/cancel).
I think I don't follow you here. What's preventing you from rearranging the
dock widgets and saving once afterwards?
Post by Robert Krawitz
Post by Johannes Zarl-Zierl
You should not get that button if you compile without libkface. If
you really don't want it, I think it's best to remove
libkf5kface-dev (on debian-style systems; probably libkface-devel on
rpm distros).
This should be a runtime option, not a compile time option.
Distributions are going to compile it with libkface; it should be
possible to disable it.
That situation did not change with kphotoalbum 5.


Johannes
Robert Krawitz
2016-11-20 22:14:47 UTC
Permalink
Post by Johannes Zarl-Zierl
Hi,
Post by Robert Krawitz
Post by Johannes Zarl-Zierl
Post by Robert Krawitz
1) If I close one of the widgets (or turn it off in the
Options/Settings dialog), it goes away, but the next time I enter
the annotation dialog, all of the default widgets come back
You need to save the window layout to make it permanent. In the
annotation dialog, select "Options…|Configure window layout…|Save
current window setup".
That's awfully unintuitive (especially since you have to go through
Configure window layout..." once for each change you want to make. It
would make more sense as an actual window (not just a menu) that would
let you make your selections and then click save (or apply/save/cancel).
I think I don't follow you here. What's preventing you from
rearranging the dock widgets and saving once afterwards?
Suppose I want to add
Post by Johannes Zarl-Zierl
Post by Robert Krawitz
Post by Johannes Zarl-Zierl
You should not get that button if you compile without libkface. If
you really don't want it, I think it's best to remove
libkf5kface-dev (on debian-style systems; probably libkface-devel on
rpm distros).
This should be a runtime option, not a compile time option.
Distributions are going to compile it with libkface; it should be
possible to disable it.
That situation did not change with kphotoalbum 5.
Didn't say it was, just my suggestion for a change.
--
Robert Krawitz <***@alum.mit.edu>

*** MIT Engineers A Proud Tradition http://mitathletics.com ***
Member of the League for Programming Freedom -- http://ProgFree.org
Project lead for Gutenprint -- http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton
Johannes Zarl-Zierl
2016-11-24 00:48:02 UTC
Permalink
Hi,
Post by Robert Krawitz
It isn't flashing each image in turn; it's flashing just one image.
I'm confident that I have correctly identified and fixed the cause of the
problem.

Can you verify if the problem is solved in current master (c4fea24)?

Cheers,
Johannes
Robert Krawitz
2016-11-24 02:11:13 UTC
Permalink
Hi,
Post by Robert Krawitz
It isn't flashing each image in turn; it's flashing just one image.
I'm confident that I have correctly identified and fixed the cause of the problem.
Can you verify if the problem is solved in current master (c4fea24)?
Yes, it's solved. Thanks!
--
Robert Krawitz <***@alum.mit.edu>

*** MIT Engineers A Proud Tradition http://mitathletics.com ***
Member of the League for Programming Freedom -- http://ProgFree.org
Project lead for Gutenprint -- http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton
Reimar Imhof
2016-11-27 21:14:09 UTC
Permalink
Post by Robert Krawitz
Hi,
Post by Robert Krawitz
It isn't flashing each image in turn; it's flashing just one image.
I'm confident that I have correctly identified and fixed the cause of the problem.
Can you verify if the problem is solved in current master (c4fea24)?
Yes, it's solved. Thanks!
Hi.

I'm sorry, here the problem is not fixed...
I've taken 5.0.1 + patch "Make ImagePreview size hint more stable".
System is KDE apps 16.08.2, KDE Frameworks 5.26.0, Qt 5.6.1 (openSuse Leap
42.2).
How can I provide information to analyze the problem?

Reimar
Andreas Schleth
2016-11-27 22:57:27 UTC
Permalink
Hi Reimar,

this weekend I updated to leap 42.2 on 3 machines without any tweaking.

On two of them KPA is installed (compiled from git-sources): Version
v5.0.1-16-gacef49e
I do not experience this type of flickering. One i7-6700 with Intel
Graphics and an older i5-whatever.
Did you try the latest git-master revision?
How about all the other libs?
Are they the standard set that get installed by default?

Regards, Andreas
Post by Reimar Imhof
Post by Robert Krawitz
Hi,
Post by Robert Krawitz
It isn't flashing each image in turn; it's flashing just one image.
I'm confident that I have correctly identified and fixed the cause of the problem.
Can you verify if the problem is solved in current master (c4fea24)?
Yes, it's solved. Thanks!
Hi.
I'm sorry, here the problem is not fixed...
I've taken 5.0.1 + patch "Make ImagePreview size hint more stable".
System is KDE apps 16.08.2, KDE Frameworks 5.26.0, Qt 5.6.1 (openSuse Leap
42.2).
How can I provide information to analyze the problem?
Reimar
_______________________________________________
KPhotoAlbum mailing list
https://mail.kdab.com/mailman/listinfo/kphotoalbum
Reimar Imhof
2016-11-28 21:01:52 UTC
Permalink
Hi Andreas,

the strange thing is: The flickering is occurring only with the kphotoalbum
demo. It does not occur with my real pictures - better then the other way
round ;-).
Software: Leap 42.2, plain install incl. all updates without any additional
repositories in VirtualBox.
Second install: a real machine with some additional repos.

Recompiling from git did not help.

Steps to reproduce:
Start demo
Select all pictures
Press Ctrl-2
Step through pictures
-> preview starts flickering

Reimar
Post by Andreas Schleth
Hi Reimar,
this weekend I updated to leap 42.2 on 3 machines without any tweaking.
On two of them KPA is installed (compiled from git-sources): Version
v5.0.1-16-gacef49e
I do not experience this type of flickering. One i7-6700 with Intel
Graphics and an older i5-whatever.
Did you try the latest git-master revision?
How about all the other libs?
Are they the standard set that get installed by default?
Regards, Andreas
Post by Reimar Imhof
Post by Robert Krawitz
Post by Johannes Zarl-Zierl
Hi,
Post by Robert Krawitz
It isn't flashing each image in turn; it's flashing just one image.
I'm confident that I have correctly identified and fixed the cause of
the
problem.
Can you verify if the problem is solved in current master (c4fea24)?
Yes, it's solved. Thanks!
Hi.
I'm sorry, here the problem is not fixed...
I've taken 5.0.1 + patch "Make ImagePreview size hint more stable".
System is KDE apps 16.08.2, KDE Frameworks 5.26.0, Qt 5.6.1 (openSuse Leap
42.2).
How can I provide information to analyze the problem?
Reimar
_______________________________________________
KPhotoAlbum mailing list
https://mail.kdab.com/mailman/listinfo/kphotoalbum
Johannes Zarl-Zierl
2016-11-28 21:19:07 UTC
Permalink
Are we still talking about the preview automatically switching between
different images, or is it the same image flickering (probably because it is
reloaded)?
Post by Reimar Imhof
the strange thing is: The flickering is occurring only with the kphotoalbum
demo. It does not occur with my real pictures - better then the other way
round ;-).
The (other) flickering bug was very sensitive to the dockwidget-layout of the
annotation dialog - maybe the difference between these two situations is the
window layout? Does changing the dock widgets affect the bug in any way?
Post by Reimar Imhof
Start demo
Select all pictures
Press Ctrl-2
Step through pictures
-> preview starts flickering
Oh, <insert expletive here>. I swear I tried that before and could not trigger
the bug. I'm seeing the bug now...

Bright side: I can debug what I can see...

Cheers,
Johannes
Johannes Zarl-Zierl
2016-11-28 21:56:07 UTC
Permalink
So....

I decided not to try and outsmart myself with the ImagePreview size. So far,
it seems very promising:

https://commits.kde.org/kphotoalbum/fec5cc9b7183fc1448e51056e8117dd7539c02e4

The new code removes all guessing (and possible cyclic data dependencies) from
the game. It is simpler, easier to understand and (most important of all) does
what it is supposed to do.

The only downside (and the reason I initially tried to be smart) is that by
default, the preview wants to be as big as the image. That should be no
problem, though, because the actual size is dependent on other factors as
well...

How does this work for you?

Cheers,
Johannes
Robert Krawitz
2016-11-29 03:23:23 UTC
Permalink
Post by Johannes Zarl-Zierl
So....
https://commits.kde.org/kphotoalbum/fec5cc9b7183fc1448e51056e8117dd7539c02e4
The new code removes all guessing (and possible cyclic data dependencies) from the game. It is simpler, easier to understand and (most important of all) does what it is supposed to do.
The only downside (and the reason I initially tried to be smart) is that by default, the preview wants to be as big as the image. That should be no problem, though, because the actual size is dependent on other factors as well...
How does this work for you?
Worked fine for me (and eliminated some other problems with the dialog
changing when it received/lost focus).
--
Robert Krawitz <***@alum.mit.edu>

*** MIT Engineers A Proud Tradition http://mitathletics.com ***
Member of the League for Programming Freedom -- http://ProgFree.org
Project lead for Gutenprint -- http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton
Reimar Imhof
2016-11-29 19:03:46 UTC
Permalink
Post by Robert Krawitz
Post by Johannes Zarl-Zierl
So....
I decided not to try and outsmart myself with the ImagePreview size. So
https://commits.kde.org/kphotoalbum/fec5cc9b7183fc1448e51056e8117dd7539c02
e4
The new code removes all guessing (and possible cyclic data dependencies)
from the game. It is simpler, easier to understand and (most important of
all) does what it is supposed to do.
The only downside (and the reason I initially tried to be smart) is that
by default, the preview wants to be as big as the image. That should be
no problem, though, because the actual size is dependent on other factors
as well...
How does this work for you?
Worked fine for me (and eliminated some other problems with the dialog
changing when it received/lost focus).
Hi,
it's very strange - why does it work every where but not here? Just compiled
latest version from git - no luck.
Reimar
Andreas Schleth
2016-11-29 19:51:21 UTC
Permalink
Post by Reimar Imhof
Post by Robert Krawitz
Post by Johannes Zarl-Zierl
So....
I decided not to try and outsmart myself with the ImagePreview size. So
https://commits.kde.org/kphotoalbum/fec5cc9b7183fc1448e51056e8117dd7539c02
e4
The new code removes all guessing (and possible cyclic data dependencies)
from the game. It is simpler, easier to understand and (most important of
all) does what it is supposed to do.
The only downside (and the reason I initially tried to be smart) is that
by default, the preview wants to be as big as the image. That should be
no problem, though, because the actual size is dependent on other factors
as well...
How does this work for you?
Worked fine for me (and eliminated some other problems with the dialog
changing when it received/lost focus).
Hi,
it's very strange - why does it work every where but not here? Just compiled
latest version from git - no luck.
Reimar
_______________________________________________
KPhotoAlbum mailing list
https://mail.kdab.com/mailman/listinfo/kphotoalbum
Hi Reimar & Johannes,

just now, I tested the flickering issue on the demo Database with my
previous git build (v5.0.1-16-gacef49e) and - tataa - I have seen the
flicker! Reimar, you are not alone.

* start a new KPA with a wholly new Demo Database (say "delete" after an
earlier test).

* select all thumbnails

* hit crtl-2

* young blackie flickers. Sometimes, when hovering the mouse above, the
separator bar below the preview flickers too.

* resize the preview just a tiny bit and the flicker is gone and cannot
be restored.

So I pulled the latest version (v5.0.1.-20-...) and there we have the
flicker gone, but some odd resizing behavior. The image scales in steps.
Sometimes it gets cropped.

--> Without looking at the code (using pure telepathy ;-): The original
issue most probably is a coincidence, where a certain thumbnail size (as
in the demo) combined with a certain window layout (default) triggers
one of the most beloved > vs. >= or < vs. <= errors or something along
the lines (0-255 = 256) vs. 255. As the internal window frames take
part in the flickering, I would not search this in KPA but somewhere
deeper in the KDE/QT cellars.

--> Therefore, you might find it easier to change the default window
layout by a few percent and be done, than to hunt the bug in KPA (or
KDE/QT). Maybe a canned, flickering version might help someone at
KDE/QT to hunt down this issue from their side (revision -16- ... might do).

@Johannes: As you are just touching the rescaling of the preview:

* I do not think the current state is satisfactory. Much too jumpy and
not responsive. I prefer the old state.

* I would greatly appreciate, if the current scaling of the preview
could be saved with a custom window layout. I think, I even filed a bug
(yes in 2014: https://bugs.kde.org/show_bug.cgi?id=340121). In the
earlier versions (4.1.1 and before) that was a feature in KPA, that
seemingly dropped out after a QT interface change.

Happy debugging, Andreas

"...

The small girl smiles. One eyelid flickers.

She whips a pistol from her knickers.

..." giyf
Tobias Leupold
2016-11-29 20:12:43 UTC
Permalink
Hi all,

I can confirm the not-so nice preview image scaling behavior (sometimes it's
cropped, and it scales not so nice anymore). This should probably be reverted
(I didn't look into the code and the changes Johannes did yet, but I also fear
I can't contribute much expertise in making this better ;-)

I can't see the flickering though ... I could actually reproduce it before
Johannes' last commit, with the demo db, but not with current git master.
Probably, this is really due to some odd coincidence? I couldn't produce it
with my testing or real collection, also not before the latest changes.

This seems to be really hard to debug ...

Cheers, Tobias
Johannes Zarl-Zierl
2016-12-02 01:50:57 UTC
Permalink
Post by Andreas Schleth
* I do not think the current state is satisfactory. Much too jumpy and
not responsive. I prefer the old state.
I'm kind of between a rock and a hard place here: the flickering seems to be a
major issue in some annotation dialog layouts. This affects some people all of
the time. The resizing jumpiness affects more people, but only some of the
time (i.e. only when the dialog is resized).

I've not yet found the root cause of the jumpiness, but the dockwidgets may
play some part: when I closed all dockwidgets except the preview, smoothness
increased.
Post by Andreas Schleth
* I would greatly appreciate, if the current scaling of the preview
could be saved with a custom window layout. I think, I even filed a bug
(yes in 2014: https://bugs.kde.org/show_bug.cgi?id=340121). In the
earlier versions (4.1.1 and before) that was a feature in KPA, that
seemingly dropped out after a QT interface change.
I agree, this is annoying...

Cheers,
Johannes

Robert Krawitz
2016-11-06 21:23:49 UTC
Permalink
Post by Johannes Zarl-Zierl
Hi,
Post by Reimar Imhof
I gave it another test with annotating single picutures (ctrl-1).
Again using the kphotoalbum demo.
Select all pictures, press Ctrl-1
Dialog opens ok. Then switching to next picture triggers flashing.
I could not reproduce this, either.
This leaves me a bit uneasy: two people independently having the problem, with pretty clear and easy instructions how to reproduce it. Yet neither I nor Tobias being able to reproduce it :(
Does your setup include anything unusual/noteworthy that might be of interest? Did you change the default shortcuts? (Just to make a pretty wild guess)
I've changed the default _global_ shortcuts (in KDE). I haven't
changed the kph ones.
--
Robert Krawitz <***@alum.mit.edu>

*** MIT Engineers A Proud Tradition http://mitathletics.com ***
Member of the League for Programming Freedom -- http://ProgFree.org
Project lead for Gutenprint -- http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton
Tobias Leupold
2016-11-06 19:48:56 UTC
Permalink
I can't reproduce it ...
Post by Reimar Imhof
Hi Tobias,
I'm seeing the same problem here for example with the kphotoalbum demo
pictures.
Start demo, select all pictures (ctrl-a), annotate multiple (here all)
images (ctrl-2).
kphotoalbum 5.0.1, openSuse leap 42.2 rc2.
Cheers,
Reimar
Robert Krawitz
2016-11-06 19:47:49 UTC
Permalink
Post by Tobias Leupold
Hi Robert!
I don't see this with the current 5.0.1 release. Can you reproduce
it with this version?
This was with current master, but it has been present (for me) for
quite a while. I'm presently using the latest KDE and Qt bits in the
openSUSE 42.1 RPMs.

To reproduce:

Select a set of images (my common use case is several hundred images).

Type ctrl-2

Dialog pops up, it tries to flash each image in turn near the top right.
Post by Tobias Leupold
Post by Robert Krawitz
When annotating multiple images (ctrl-2 in thumbnail mode, for
example), the dialog flashes each image up briefly in turn, which is
both distracting and makes the dialog unusable until I close the image
preview widget in the dialog. This started around the KDE5 cutover.
--
Robert Krawitz <***@alum.mit.edu>

*** MIT Engineers A Proud Tradition http://mitathletics.com ***
Member of the League for Programming Freedom -- http://ProgFree.org
Project lead for Gutenprint -- http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton
Loading...