Activity list jumps to top after some short time #594
Comments
|
Seems to be pretty much once a minute. Comments in the output of strace indicate when I observed the UI jump back to the top: $ uname -a
Linux canard 5.7.2-arch1-1 #1 SMP PREEMPT Wed, 10 Jun 2020 20:36:24 +0000 x86_64 GNU/Linux$ pacman -Ss hamster
community/hamster-time-tracker 3.0.1-1 [installed]
Time tracking application that helps you to keep track on how much time you have spent during the day on
activities you choose to trackArch linux on Dell XPS13 9370. |
|
Thanks for the trace. Could you confirm (via |
|
Do you have the shell extension running? It seems that hamster receives a "GetFactsJSON" dbus method call just before this happens. |
Nonsense, the Shell extension doesn't use that method call. It's probably rather hamster-cli itself that sends it. |
Forget it, not necessary any more. |
|
Please check out #623. |
|
Yes, that seems to solve it. I'll keep using that version for the following days to see whether something else breaks. I agree with your concern that now switching to the previous month it might be strange that the list doesn't jump to the top - but maybe that's just about getting used to. I certainly prefer no jumps to regular jumps =). |
|
No problems with using this version for my use cases. |
Right now FactTree.set_facts() is always resetting the position of the view, bringing the user back to the top but this function is called regularly to update with the latest data even when the user has not changed anything in the selection widget... which is really annoying when you are reviewing the list of facts. Let's distinguish between both cases with a "reset=True" attribute that we use when we generate an entirely new set of facts to be displayed. This makes projecthamster#623 obsolete. Thanks to @mwilck for the initial analysis. Fixes projecthamster#594
Right now FactTree.set_facts() is always resetting the position of the view, bringing the user back to the top but this function is called regularly to update with the latest data even when the user has not changed anything in the selection widget... which is really annoying when you are reviewing the list of facts. Let's distinguish between both cases with a "reset=True" attribute that we use when we generate an entirely new set of facts to be displayed. This makes projecthamster#623 obsolete. Thanks to @mwilck for the initial analysis. Fixes projecthamster#594
Right now FactTree.set_facts() is always resetting the position of the view, bringing the user back to the top but this function is called regularly to update with the latest data even when the user has not changed anything in the selection widget... which is really annoying when you are reviewing the list of facts. Let's distinguish between both cases with a "scroll_to_top=True" attribute that we use when we generate an entirely new set of facts to be displayed. This makes projecthamster#623 obsolete. Thanks to @mwilck for the initial analysis. Fixes projecthamster#594
Right now FactTree.set_facts() is always resetting the position of the view, bringing the user back to the top but this function is called regularly to update with the latest data even when the user has not changed anything in the selection widget... which is really annoying when you are reviewing the list of facts. Let's distinguish between both cases with a "scroll_to_top=True" attribute that we use when we generate an entirely new set of facts to be displayed. This makes #623 obsolete. Thanks to @mwilck for the initial analysis. Fixes #594
If I list for example all activities for a month, the list is obviously larger than one screen. When I scroll down this list some way, the list jumps back to the top on its own after some time of waiting. Sometimes its 5 seconds, sometimes a minute.
I would expect the list to stay at the scrolled to position.
This is with hamster 3.0.1 on SUSE Tumbleweed using lightdm.
Anything else I can provide to help debug this?
The text was updated successfully, but these errors were encountered: