Bug 457640 - Allow KmyMoney to stay on selected transaction even when switching between Virtual Desktops
Summary: Allow KmyMoney to stay on selected transaction even when switching between Vi...
Status: REPORTED
Alias: None
Product: kmymoney
Classification: Applications
Component: general (show other bugs)
Version: 5.1.2
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: KMyMoney Devel Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-08-08 17:56 UTC by jesse
Modified: 2022-09-27 13:33 UTC (History)
0 users

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description jesse 2022-08-08 17:56:57 UTC
SUMMARY
I am a Fedora Gnome users. Sometimes I use Plasma as well. I have noticed a small inconvenience with Gnome. I am not 100% sure if this is present with Plasma. 
The inconvenience is related to switching between virtual desktops. I usually have more than one virtual desktop open and more often I have KMY open in one desktop and my PDFs open in another. I switch virtual desktops using keyboard shortcuts. When using KMY, I noticed that if I select a transaction and then switch virtual desktops, it loses the focus on that transaction. If that transaction was from a while ago, say two months, it will scroll to the bottom of the ledger, past many dozens of transactions, when I return to the virtual desktop from reviewing my bank statements. This forces me to have to scroll back to find the transaction I was researching. 


STEPS TO REPRODUCE
1. Open a kmy file and ledger with many transaction.  
2. scroll up to a transaction and highlight it by clicking it. 
3. switch virtual desktops 
4. switch back to the virtual desktop KMY is opened on


OBSERVED RESULT
The selected transaction is no longer selected and the view scrolls down to the latest transaction in the ledger. 

EXPECTED RESULT
The ledger view should stay focused on the selected transaction. 


SOFTWARE/OS VERSIONS
Using app image. KMyMoney
Version 5.1.2-db4223684

Linux/Gnome: 42.3- fedora 36
KDE Plasma Version: n/a 
KDE Frameworks Version: KDE Frameworks 
Version 5.95.0
Qt Version: Qt 
Version 5.15.2 (built against 5.15.2)

ADDITIONAL INFORMATION: 
I believe this happens as a result of losing focus on the window or window component. I do not know how this could be changed or if this is a Gnome only type of issues due to the QT working on Gnome(gtk based). maybe there is a way for the KMY software to hold in memory the last used transaction when it loses focus on the ledger. Then, when it regains the focus, read the variable to see where it left off? I have no idea.. just guessing to be honest.
Comment 1 Thomas Baumgart 2022-08-10 05:58:04 UTC
I tried to duplicate this on a KDE desktop (Plasma) and was unable to do so. Here are a couple of questions:

- Does this behavior also show up when you switch to a different application on the same virtual desktop? KMyMoney loses and regains focus in this case already.
- How do you switch virtual desktops (keyboard sequence)? Does this behavior also happens when you switch virtual desktops using the mouse (don't know if this is possible at all)
- What happens if you switch to another application on the same desktop, then switch desktops, come back and select KMyMoney again? In case the transaction selection changes it would be interesting to know when this happens.
Comment 2 jesse 2022-08-11 17:34:52 UTC
(In reply to Thomas Baumgart from comment #1)
> I tried to duplicate this on a KDE desktop (Plasma) and was unable to do so.
> Here are a couple of questions:
> 
> - Does this behavior also show up when you switch to a different application
> on the same virtual desktop? KMyMoney loses and regains focus in this case
> already.
 JV : It does not happen if I change to a different application on the same virtual desktop. 

> - How do you switch virtual desktops (keyboard sequence)? 
JV: I use the ctrl-alt-arrowkeys to move

>Does this behavior
> also happens when you switch virtual desktops using the mouse (don't know if
> this is possible at all)
JV: yes, if I switch using the mouse click/mouse touchpad gestures, it still occurs

> - What happens if you switch to another application on the same desktop,
> then switch desktops, come back and select KMyMoney again? In case the
> transaction selection changes it would be interesting to know when this
> happens.
JV: It gets reset after I switch to the next virtual desktop. Switching to the other app on the same virtual desktop as KMY, does not cause this. It seems to be when I switch virtual desktops only. There is a way in Gnome where you can see all the virtual desktops at once, and as soon as I select a different virtual warehouse, KMY scrolls to the bottom of the ledger. 

Hopefully this helps. I am using the app image. I can try to install the distribution's version (Fedora's repo in this case) to test if it helps. I know a lot of things look different, and maybe work different, depending on the app image vs local install version.
Comment 3 jesse 2022-08-11 17:37:03 UTC
(In reply to Thomas Baumgart from comment #1)
> I tried to duplicate this on a KDE desktop (Plasma) and was unable to do so.
> Here are a couple of questions:
> 
> - Does this behavior also show up when you switch to a different application
> on the same virtual desktop? KMyMoney loses and regains focus in this case
> already.
> - How do you switch virtual desktops (keyboard sequence)? Does this behavior
> also happens when you switch virtual desktops using the mouse (don't know if
> this is possible at all)
> - What happens if you switch to another application on the same desktop,
> then switch desktops, come back and select KMyMoney again? In case the
> transaction selection changes it would be interesting to know when this
> happens.

Also wanted to add that, I do not remember this occurring when I had Plasma installed. (I had to change to gnome for some multi-display support reasons).
Comment 4 Bug Janitor Service 2022-08-26 04:35:42 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 5 jesse 2022-08-26 14:02:32 UTC
Hello, 

Is there anything else I can provide to help with this bug?

Thanks
Comment 6 Jack 2022-08-26 16:52:23 UTC
Jesse - when you respond to questions, you can change the status from NEEDSINFO back to REPORTED.  That will stop the (automated) Bug Janitor from getting involved.

A few additional questions:
- Is this with Xorg or with Wayland?
- Please confirm that it only happens when using Gnome and not when using KDE/Plasma.

Thanks.
Comment 7 jesse 2022-08-26 21:02:45 UTC
(In reply to Jack from comment #6)
> Jesse - when you respond to questions, you can change the status from
> NEEDSINFO back to REPORTED.  That will stop the (automated) Bug Janitor from
> getting involved.
> 
> A few additional questions:
> - Is this with Xorg or with Wayland?
> - Please confirm that it only happens when using Gnome and not when using
> KDE/Plasma.
> 
> Thanks.

Hi Jack.

Sure thing. 

Right now I will leave it as is because I am not home to provide the information requested. 

At this time I was using Gnome w/Wayland. Under Plasma, I do not recall this happening. Anyone else have Plasma installed that can test the Plasma path?  

Thanks!
Comment 8 Jack 2022-08-26 23:01:02 UTC
That actually make me suspect Wayland more than Gnome, although that's only a guess.  Remember, Thomas was unable to reproduce, and I'm pretty sure he uses KDE/Plasma with Xorg, not Wayland.  I also run Xorg, but can test Wayland at some point to see if I can reproduce the problem.
Comment 9 jesse 2022-08-26 23:42:57 UTC
Yes. It could be. 

Thanks Jack! 

I am on vacation in Mexico right now so i will not be able to test anything late next week. 

Thanks again! 

Jesse
Comment 10 Bug Janitor Service 2022-09-10 04:36:50 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 11 jesse 2022-09-10 18:46:22 UTC
From what I can tell this problem is there for Gnome on Wayland, xOrg and classic. 

I opened KMY, same app image on all three, opened a ledger, clicked on a transaction, used the keyboard keys to switch virtual desktops (nothing opened on the second virtual desktop), and switched back. The focus was lost on the selected transaction. 

Hopefully this helps. 

FYI.. another thing that I noted on version: KMyMoney Version 5.1.80-06ee79919... (master) this behavior did not occur. There it keeps the focus. 

thanks. I am updating the Status to Reported.
Comment 12 Jack 2022-09-12 22:14:36 UTC
It does not happen for me with Plasma and Xorg with either git master (compiled) or 5.1.2 (appimage.)  That makes me wonder if it might be something in Gnome's window manager or virtual desktop implementation.  However, didn't you say there have been particular combinations of setup and version where this did not happen?  Can anyone think of any other application that could provide a similar situation to test?  Perhaps LibreOffice Calc with focus on a specific cell?
Comment 13 Bug Janitor Service 2022-09-27 04:48:17 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 14 jesse 2022-09-27 12:41:25 UTC
Hi all, 

(In reply to Jack from comment #12)
> However, didn't you say there have been particular combinations of setup and
> version where this did not happen?  
Not really. I had mentioned in comment #2 " JV : It does not happen if I change to a different application on the same virtual desktop. ". There I just meant that alt-tab to another application or clicking on another application within the same virtual desktop did not show the same behavior. 

Alt-tab to an application on a different virtual desktop, still showed the same behavior. 

> Can anyone think of any other application that could provide a similar situation to test?  Perhaps
> LibreOffice Calc with focus on a specific cell?
I tested this scenario with LibreOffice Calc. I clicked on a Cell and then switched virtual desktops. It retained focus on the cell.

From what I compiled on Master, it does not seem to happen there. However, not sure what to do with this bug. This is still an issue on the current version but maybe, just maybe, it will be fixed when the new release is out. (not sure when that will be though)

What is the right thing to do in these situations? 

thanks, 

Jesse
Comment 15 Jack 2022-09-27 13:33:25 UTC
The WAITINGFORINFO state is so that if the original poster never answers any questions about more details, the bug eventually gets closed automatically by the Bug Janitor.  Once you answer, you should change the status back to REPORTED (which I'm doing now.)  It can just sit in that state until someone else confirms it, or there is further confirmation that it is fixed in Master.  In that latter case, it might get closed as FIXED, although there is still no timeline for release of Master as a production version.