Bug 357237 - Date bar focus position and selection is lost when doing further selections
Summary: Date bar focus position and selection is lost when doing further selections
Status: RESOLVED FIXED
Alias: None
Product: kphotoalbum
Classification: Applications
Component: Datebar (show other bugs)
Version: 4.7.1
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: KPhotoAlbum Bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-12-27 23:33 UTC by Andreas Schleth
Modified: 2022-12-03 11:51 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
slo mo screenshot movie (3 sec pre frame) of the problem (601.53 KB, image/gif)
2016-04-03 20:53 UTC, Andreas Schleth
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Andreas Schleth 2015-12-27 23:33:29 UTC
This report is about two (possibly related) issues with the Date Bar:

a) The date bar has a "lens", that always resets to somewhere in the middle of the date range of the whole database (somewhere around 1993 in my case).  
I usually shift the lens to a more recent date and then drill down by expanding the date range (from year to month to week to day).  Unfortunately the lens stays always too far left, sometimes off screen.
==> the lens should stay on screen and when selecting a date range (blue range below the date bar) it should move to the beginning of this range.  (I would rate this "enhancement wish" - but it might just fit into the hunt for point b)

b) When I have a date range selected, this selection is lost after most other interactions (like selecting in the categories, displaying thumbnails, navigating with back / forward). 
As far as I remember, the date bar selection was fairly stable in former revisions and behaved more or less like a category selection (with the same back/forward - functionality).
==> The date bar selection should have more or less the same functionality and stability as a category selection and react to back/forward (and home).  It should not reset when doing other selections.

I guess, the current behavior makes the date bar not totally useless, but a lot less useful as it once was - and probably much more difficult to understand.

Reproducible: Always

Steps to Reproduce:
1. do a date bar selection of (say) two recent days
2. select a category (present in that range)
3. show thumbnails
4. hit "back" to do another category selection 


Actual Results:  
5. ==> at this moment, the date range is lost.


Expected Results:  
It should be possible to select within a date range a place and some people AND change this selection after viewing the thumbnails without loosing the date selection.

Version v4.6.2-119-gec4650f
Using KDE Development Platform 4.14.10
Comment 1 Andreas Schleth 2016-04-03 13:54:02 UTC
To make this issue somewhat clearer (tested again with KPA 4.7.1):

The behavior of the date bar is different if accessed from the start screen then from the thumbnail browser.
From the start screen: fails (somewhat)
From the thumbnail viewer: works as expected.

To reproduce:
* In fresh session of KPA on any larger database select a year (eg. 2016) below the bar.
* then enter the thumbnail viewer (the correct range of pictures appear)
* BUT: the datebar is reset to its initial state (it should stay in its selected state to make refinements easily available).

Workaround:
* start thumbnail viewer first (on all pictures)
* then manipulate the date bar
* refinements and re-selections work as expected
Comment 2 Johannes Zarl-Zierl 2016-04-03 14:25:25 UTC
Do you mean that the datebar loses its selection, but still manages to restrict the range of the images?
I couldn't reproduce anything like this, but I'm getting the feeling that I misunderstood something...

Steps I tried to reproduce (using the demo db for reference):
1. Select year 2006   -> 4 matches
2. Select "Places/USA" -> 3 matches
3. Enter thumbnailview
4. Hit "back"
5. Select "People/Jesper" -> 2 matches

My normal DB behaves analogously.

P.S.: I saw one issue with the datebar, though: Selecting one year in the datebar at the lowest "zoom level" selected that year and the next one (visible once one zooms in).
Comment 3 Andreas Schleth 2016-04-03 20:53:55 UTC
Created attachment 98226 [details]
slo mo screenshot movie (3 sec pre frame) of the problem

Hi Johannes,
watch the movie.  It takes some, maybe strange, operations to get to the point.
However, just letting the lens follow the date selection would be a nice enhancement.
Cheers, Andreas
Comment 4 Andreas Schleth 2016-04-03 20:54:34 UTC
s/pre/per/
Comment 5 Justin Zobel 2022-10-19 22:10:48 UTC
Thank you for reporting this bug in KDE software. As it has been a while since this issue was reported, can we please ask you to see if you can reproduce the issue with a recent software version?

If you can reproduce the issue, please change the status to "CONFIRMED" when replying. Thank you!
Comment 6 Bug Janitor Service 2022-11-03 05:07:01 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 7 Andreas Schleth 2022-11-06 16:44:24 UTC
Yes, I can report, that this is still as reported in the latest git master v5.8.1-115-gd77b7c1b. (see the slo mo screenshot movie)

Sorry for the delay, I had to update my system to be able to build again.
Comment 8 Johannes Zarl-Zierl 2022-11-13 18:47:47 UTC
Thanks for checking again, Andreas.
I also tried to reproduce the bug again, with some luck.

a. When the DateBar is zoomed and no "focus"/"lens" is set, the selection is usually outside of the visible range.
-> I can reproduce this.

b. DateBar selection is lost when using "show thumbnails", back/forward navigation, category selection,  etc.), even though the selection is still applied.
First of all: I finally understood what you meant - that the selection on the DateBar itself is lost, even though the images are correctly filtered. I don't know why I didn't get that before...
I could not reproduce all of these, but when trying to do so I managed to encounter the described behaviour one time. Sadly, I could not reproduce the steps to do so. Following the steps outlined in the video, or in Comment 1 did not reproduce the bug for me.

I'm happy for any additional hints since you can reproduce the bug every time but I could only do so once by sheer luck. The situation is quite frustrating...

I'm marking the bug as confirmed since I could reproduce it at least once (and part a is straighforwardly reproducible).
Comment 9 Johannes Zarl-Zierl 2022-12-03 01:23:46 UTC
Git commit c63c93c40462b492882d4c8951e02173edb33d4b by Johannes Zarl-Zierl.
Committed on 03/12/2022 at 01:23.
Pushed by johanneszarl into branch 'master'.

Center DateBar selection when zooming.

This prevents the DateBar selection from moving out of sight when
zooming in.

M  +26   -3    DateBar/DateBarWidget.cpp
M  +17   -2    DateBar/DateBarWidget.h

https://invent.kde.org/graphics/kphotoalbum/commit/c63c93c40462b492882d4c8951e02173edb33d4b
Comment 10 Andreas Schleth 2022-12-03 11:51:18 UTC
I tested with v5.9.1-99-gd3133368 and I cannot reproduce any undesirable behavior of the date bar anymore.
So, from my point of view, this little bug can be closed just a few days before its 7th birthday ;-)
Very nice! 
Thanks to Johannes for fixing it and to Justin to put it into focus again.