After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 344451 - Return focus to account list after making acct hidden
Return focus to account list after making acct hidden
Status: RESOLVED OBSOLETE
Product: GnuCash
Classification: Other
Component: User Interface General
2.2.x
Other All
: Normal minor
: ---
Assigned To: David Hampton
Chris Shoemaker
Depends on:
Blocks:
 
 
Reported: 2006-06-10 02:17 UTC by jlquinn
Modified: 2018-06-29 21:07 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description jlquinn 2006-06-10 02:17:00 UTC
Please describe the problem:
If focus is on the account list, you can use C-E to edit the account.  If you mark the account as hidden (which can't be done with the keyboard because tabbing gets stuck in the Notes field), the focus is no longer on the account list once you save your change.


Steps to reproduce:
1. Click on the account list and scroll to an account
2. C-E, click on hidden, hit enter
3. 


Actual results:
Focus isn't on the account list anymore

Expected results:
Focus to return to the account list so you can use arrow keys to scroll to another account.

Does this happen every time?
yes

Other information:
Comment 1 David Hampton 2006-06-12 21:33:34 UTC
As far as I can tell, the focus is still in the account tree widget.  There's no row selected (since the selected row was hidden) so nothing is highlighted, but pressing the down arrow consistently highlights the second line of the account tree for me.

BTW, you can use Ctrl-TAB to tab out of the notes field.  You can also select the hidden checkbox directly by using the access (underlined) character for that field.  For that checkbox its Alt-i.
Comment 2 jlquinn 2006-07-03 17:00:11 UTC
It may not be a bug exactly, but it is surprising from a UI standpoint, and I would argue not desirable.

I'd suggest that when this happens, the selected row move to the next non-hidden account, or the previous nonhidden account if there aren't any more afterwards.
Comment 3 Rolf Leggewie 2008-06-20 21:49:06 UTC
still a problem in the latest 2.2.x versions?
Comment 4 John Peach 2008-10-13 06:38:38 UTC
In the problem description, the submitter wrote "If you
mark the account as hidden (which can't be done with the keyboard because
tabbing gets stuck in the Notes field)"

This can be undone from the keyboard by pressing ctrl-tab in the Notes field.  That will set the focus outside the Notes field and then tab can be used to change the focus to "Hidden"
Comment 5 John Peach 2008-10-13 06:41:09 UTC
I confirm that this is still a problem in V2.2.4
Comment 6 jlquinn 2009-03-14 15:46:06 UTC
(In reply to comment #5)
> I confirm that this is still a problem in V2.2.4

Also present in V2.2.6 (latest in Debian)
Comment 7 Phil Longstaff 2009-06-22 01:30:45 UTC
I'm not sure what the problem is considered to be.  The original problem statement (loss of focus) is not a problem, and the other one (can't leave notes field) is also not a problem.
Comment 8 jlquinn 2009-06-22 02:36:47 UTC
On 2.2.6, use the arrow keys navigate to, say, the middle of the account list, edit an account and mark it hidden.  Before editing the account, the cursor is sitting on the hidden account.  Once the editing dialog closes, the cursor is no longer in the list of accounts.  It turns out it's back on the tab and if you press a down-arrow, it will be at the very first visible account.

I find this surprising.  I would expect the cursor to be on the next or previous visible account, having made the one I was on disappear.


The tabbing issue is also one of surprise.  You can use Tab to move through the fields but once you end up in the Notes field, Tab inserts white space.  C-Tab will get you out of it, but I was unaware of that at the time I reported this.  It's not very discoverable and surprised me, and I've been using gnome and various Unix interfaces for 20 years.

Interestingly gnucash and firefox have different behaviors in this respect.  As I'm adding comments to this bugzilla entry, Tab advances to the Save Changes button, so expecting Tab to do so in Gnucash isn't entirely unreasonable.

If the GNOME UI guidelines say that C-Tab is correct, I'm obviously not going to get very far with this issue.  However, I do think the position of the accounts cursor should be corrected.
Comment 9 Christian Stimming 2011-02-07 10:11:52 UTC
Thank you for taking the time to report this bug. However, you are using a version that is too old and not supported anymore. The GnuCash developers are no longer working on that version, so either this bug has already been fixed or unfortunately there will not be any bug fixes for the version that you use. The current stable version of gnucash is 2.4.0 now.

In the (hopefully unlikely) case you discover the same bug in the very latest stable version, do not hesitate to REOPEN it again. Also, feel free to file other bugs or enhancement requests that you find. Thank you very much!
Comment 10 John Ralls 2018-06-29 21:07:36 UTC
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=344451. Please update any external references or bookmarks.