Enter key doesn't work when adding or editing transaction

Bug #292283 reported by mati
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
HomeBank
Invalid
Wishlist
Maxime DOYEN

Bug Description

Enter key is commonly used as a confirmation. When user is typing (e.g. entering an amount or listing transaction tags), it's far more easier to press Enter then move hands from the keyboard to mouse and click Add/Ok button by hand.

Revision history for this message
Maxime DOYEN (mdoyen) wrote :

What do you want exactly the enter to do? Validate the transaction dialog?

Changed in homebank:
assignee: nobody → mdoyen
Revision history for this message
mati (mati-wroc) wrote :

Exactly. Enter should act like the user clicked [Add] or [Ok] button.

When I press [Enter] on the keyboard, I confirm that i want to *enter* the data from the dialog :)

Revision history for this message
Maxime DOYEN (mdoyen) wrote :

The problem is that enter also first validate the active widget (string especially)
I have to study if this is possible or not.

Changed in homebank:
importance: Undecided → Wishlist
status: New → Confirmed
Revision history for this message
Maxime DOYEN (mdoyen) wrote :

After check (gimp, gedit) this behaviour is not possible.
The <enter> key mainly depends on the widget that have the focus and it's quite impossible to force dialog validating due to this normal gtk behaviour.

Changed in homebank:
status: Confirmed → Won't Fix
Revision history for this message
David Tombs (dgtombs) wrote :

Actually, this is possible.

gtk_entry_set_activates_default() will have entry boxes forward ENTER keypresses to the default response.
gtk_dialog_set_default_response() sets that default response.

I tried hacking up the source a bit to test it, and it worked! I can submit a patch if that would be useful, but it would be pretty hacky.

Revision history for this message
Elrond (elvenlord.elrond) wrote :

I'm also quite sure that Gtk allows this.

The important question is, if we want it. Or if people should use <Tab> until they're on the right button and press <space>/<enter> there.
One side: The later stops users from accidentally/quickly changing things.
Other side: Anything can be edited later on anyway and fixed.

Maxime: I've changed the bug to "Incomplete" as it might need some discussion. Change as you see fit.

Changed in homebank:
status: Won't Fix → Incomplete
Revision history for this message
David Tombs (dgtombs) wrote :

In my opinion, an application should never protect a user from him- or herself by getting in their way like this.

Revision history for this message
Maxime DOYEN (mdoyen) wrote :

Elrond is right, the question is if it is clever to do so or not.
My first approach on it was: No.

The reason to this is that I follow GNOME HIG. I didn't checked the hig (but I will) and thus, just tested gimp, and other application based on gtk under my ubuntu.
And there is no similar behaviour here, only ESC that close the dialog, pressing enter just do nothing, except on the widget that have the focus.

Maybe my explanation when I reject this whish was unclear.

Now, I will check again a little some more apps and check also the GNOME hig and see what to do or not.

Revision history for this message
Maxime DOYEN (mdoyen) wrote :

As checked with the gnome hig
http://library.gnome.org/devel/hig-book/stable/controls-entry.html.en

I close this one.

Changed in homebank:
status: Incomplete → Invalid
Revision history for this message
mati (mati-wroc) wrote :

Maxime, I'm confused here.

Homebank uses Tab to move focus to the next control, so probably this paragraph from Gnome HIG should be applied:
"Normally, pressing Return in a dialog should activate the dialog's default button, unless the focused control uses Return for its own purposes. You should therefore set the activates-default property of most entry fields to TRUE."

Gnome itself uses this behaviour in most dialogs where users enter data. E.g. try to add new shortcut in System/Preferences/Keyboard shortcuts.

Revision history for this message
David Tombs (dgtombs) wrote :

Agreed, the linked HIG document seems to say that return should do /something/, even if it's just moving to the next control like TAB.

With that in mind, I would suggest that at least for editing a transaction, Return should close the dialog since the user has presumably already entered all required information. The preferred action may be different when adding a transaction, but I don't care as much about that personally since I import all of mine. :)

Revision history for this message
David Tombs (dgtombs) wrote :

Can we get a response on this, please? As stated above, I think Homebank is currently /violating/ the HIG, and it gets in my way every time I use it.

Revision history for this message
David Tombs (dgtombs) wrote :

Well, I got tired of this in my own usage of Homebank, so I patched it myself so that the entries on the right ("Optional Information") will activate the OK button.

A package should be available in my PPA soon: <https://launchpad.net/~dgtombs/+archive/ppa>

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.