GNOME Bugzilla – Bug 794976
Context Menu looks like it's from GTK, no GnuCash functions in it.
Last modified: 2018-06-30 00:07:09 UTC
It seems the move to Gtk3 has left me without a stable proper right-click menu. (this could be part of why I couldn't delete bill line items in https://bugzilla.gnome.org/show_bug.cgi?id=794936) The only options in the limited menu are: Cut Copy Paste Delete ----- Select All Insert Emojii Often, most of these are inactive so they are useless anyway. However, I just discovered the menu is correct when I first click away from the GnuCash window to change focus then RIGHT-CLICK on the spot I want the menu. If I instead left-click to raise the window and then right-click, I still get the limited menu. If I ever left click on the spot I want in the window, in order to get the proper context-menu again, I have to change focus and again, right-click where I want the context-menu. I can also trigger the loss of the proper menu by tabbing through memo lines in splits. So a left-click then right-click generates what appears to be a generic menu. Changing focus from the GnuCash window then back via a right-click where desired produces the correct menu. As long as you keep right-clicking, you can keep getting the proper menu. A left-click first requires the change-focus work around to get the proper right-click menu back. I'm testing this as I write this up, and behavior seems very inconsistent. All of the above steps are repeatable, but it seems there are several ways to trigger the menu change to the limited menu and to recover the proper GnuCash version. As well, it seems when the GnuCash menu displays the hover/highlight is sometimes delayed and even if it is responsive right away, in particular the Delete Split option seems to want to be the last to respond to a user click. (or allow itself to be highlighted on hover) I marked this as major because it makes using the register extremely cumbersome especially when transactions are auto-filled and you have to edit them via the menu. Not sure if this is a GTK issue, or something with the GnuCash menu.
Sorry, I submitted that a bit too soon. A little more playing around and I think I see what's happening. Left-clicking in a text-input field generates the (apparently Gtk) limited menu which seems to be for the purpose of text editing. Right-clicking on any field directly before selecting it, both select the field/split-line and provides the proper context-menu. It seems the text-editing menu is taking precedence over the GnuCash menu if you left-click to select the field first. (I guess the presumption is that you want to edit the text rather than operate on the split or the whole transaction) So not sure if this is a bug, or intended behavior (by Gtk or GnuCash, or both) but users who are well trained with muscle-memory to select an item and then right-click will have to re-learn that sequence to simply point and right-click. I'll re-set this to normal.
I think there is even more to it and haven't quite worked out what is happening yet. Recipe: right click on a tx *before* the red line [1] Q: do you get a context menu with Duplicate, Delete, etc A: I do right click on a tx *after* the red line [1] Q: do you get a context menu with Duplicate, Delete, etc A: I don't [1] the red line is File / Properties / Accounts / nn days bit puzzling to me why a mechanism set to protect unwanted changes to past data is having an affect on the UI
my last msg is only partially correct. I can get the right click context menu to appear on tx after the red line if I right click on some fields but not others (my previous muscle memory was right clicking on the Description field). fuck, that isn't right either, the red line has something to do with it but isn't looking like the important bit. maybe it is the blue line (today) ? more testing I'm not seeing any consistency in this. Is it possible the second time you try to access the right click menu in a register on a field that isn't the Description it always works but only works first time on tx before the red line. Sorry, folks, I just can't get a grasp on what it is that is actually going wrong or why at the moment. Can't find a pattern to report solidly. Apols.
Sorry, should have said I'm on Win8.1 not MacOS so this is cross platform.
I think the status of this should be raised substantially. I thought it was just cosmetic / GUI stuff, an inconvenience, it isn't. The crap it produces is getting into the db :( headline above some detail below testing a bit more (not live data) 1a. was it intended that emojis [1] should be used as or in account names, etc ? I predict tears later on if the "average user" finds out about this and starts using them 1b. I have just created a new top level a/c named whatever the emoji I chose at random was (a picture of a trumpet), with an account code of a smiley face and a security that includes a gender symbol. I stopped around there. Ugh, this fun stuff *is* going to break if people start using it. I know of people in work situations who don't see the difference between a graphic / img / pic saying ABC and the actual text ABC. It might be hard to undo this later. [1] my understanding is that emoji's are not universal (I could be wrong) but do we want to get involved if (for e.g.) my musical instrument emoji turns out to be a satirical cartoon of the idiot president of the USA in another emoji set ? I think not.
I meant IMPORTANCE not STATUS in my previous msg. Further, offering Insert Emoji, etc as first choice for date and number fields simply makes no sense. Right click is meant to be a *context* menu. If an emoji is allowed into a date or number similar to account names all bets are off.
I think that you're getting a bit overwrought about this. Emojis are a legitimate block in Unicode, just like chinese characters. There should be no problem with using them in any text field if that's what users want to do. Date fields are filtered to ignore input that the date parser can't parse, and numeric fields to compute with numbers--and I think only the ASCII numbers and operators work--so emojis will simply be ignored in those fields. The one thing that might be an issue is sorting. And no, the emoji code points are indeed standardized, so a trumpet is always a trumpet and never a Trump. The actual glyph's appearance will vary by typeface just as it does for any other codepoint, and some type faces may not implement all--or any--of the emojis, also just like any codepoint > 0x7f. That said, we do want the context menu to consistently be the GnuCash one. I was able to get it only on date fields and number fields on an empty register; when I tried on a populated register I got the GnuCash one every time. The register didn't have red or blue lines, so that's a possible variable. I suspect that what's going on is that under some conditions (like a tranaction marked read-only) we don't show the context menu and Gtk3, unlike Gtk2, is helpfully providing one.
After working more with 3.0, I think there is definitely a usability bug here. (not sure yet if this is GnuCash or Gtk+3) If the user tabs through to a new split and decides to delete it, unless there is a key-combo, they can't easily do so via a right-click. (is there such an accelerator?) They first have to either tab to a different split and then right-click only on the desired split or else right-click on a different split and then right-click on the desired split, or right-click on a different field in the selected split and then right-click. (or they'll get the Gtk+3 menu instead of the GnuCash menu) Note, my read-only setting is '0' and I don't have any future transactions entered, so no red-line/blue-line issue for me. I can trigger this consistently. Steps to reproduce: 1. Select a split by left-clicking or tabbing. 2. Right-click to bring up the context menu. 3. Only the Gtk+3 input-edit menu will display. If you right click anywhere else (even a different field in that same split) then the GnuCash menu will display. Expected behavior: Regardless of what is selected or how selected, a right-click will produce the GnuCash context menu. Also, this might be a separate bug (again, not sure if GnuCash or Gtk+3) but the GnuCash context menu is very slow to 'wake up'. That is, it displays promptly but the highlight on hover indicator (and the ability to select any menu item) can have a significant (≈+1 second) lag. Interestingly even if the menu is otherwise fully 'active' upon raising, which occasionally does happen for me, the "delete" (and, as far as I can tell only the "delete") option has a longer lag, usually another 1-2 seconds. And one can't simply rest the mouse pointer on the menu and wait, but you have to move it around to get it to 'wake up.' To be sure, it isn't a show stopper, but it does make data entry annoying and cumbersome. As for the 'input edit' Gtk+3 menu I have no beef with it other than it seems to be getting in the way when I only and always want the GnuCash menu. If there were a way to make the GC menu a higher priority or if necessary turn off the GTK menu, that would help significantly, and then the only other issue would be the lag, which may or may not be related. (it seems to lag more when switching between the two menus)
Yes, the context menu is a usability bug. It comes by default on GtkTextEntry widgets in Gtk3. It should become a combination of the text entry menu Gtk provides and our extra GnuCash menu IMO. I believe we can't just drop the Gtk provided menu as I thought it's also used to select input methods (which are important for non-lating alphabet based languages).
If I can express a preference it would be for the gnc context menu to take preference in all cases *except* where the Gtk3 menu might make sense ... in that case a combined menu might be appropriate. I think it has been made clear that right-click on a tx description or other field should not offer the entry of an emoticon ONLY vs Delete / Duplicate and other gnc specific expectations. I am tired of the counter argument.
More info: As noted in my workaround attempt for the SQLite issue, this is also a problem in the bills/invoices tabs. (editing/entering line items) I've discovered a nuance that is another damper on usability related to the default menu. It seems using the 'move entry up/down' context menu items enter the 'insert' mode of whatever cell you happen to right-click on. That is, right-click on the Description cell and it is now selected for text input. Gnucash will properly bring up its own context menu (if you only right-clicked without selecting first as noted in above comments) and it will properly move the line item up/down in the list, but it leaves that cell selected for input. Now, if you right-click that cell again to move up/down again, you can't because you get the Gtk+3 input menu. You'd have to right-click on a different cell on the same line item to get the GnuCash menu again. I just had to move a newly added line item up 6 spots. This involved right-clicking alternately on the Description and Date fields in order to accomplish this. (rather than just repeated right-clicking on the Description) In addition to this issue, the lag that I mentioned before is much more pronounced. The lag occurs each and every time the menu is brought up and it is longer, about 2-3 seconds. Steps to repeat the menu issue: 1 - Enter several line items on a bill/invoice. 2 - Right-click on a cell in a line item and choose 'move entry up/down'. Observe that this cell's contents are highlighted for input. 3 - Right-click again on the same cell to move up/down again and observe, you now get the Gtk+3 input menu, not the GnuCash context menu. Steps to repeat the lag issue (continuing from "2" above): 3 - Right-click a different cell on the same line item to get the context menu. Observe that the menu is not immediately usable. You have to move the mouse around to 'wake it up.' 4 - choose 'move entry up' 5 - Right-click, again on a different cell on the same line item (to consistently get the proper menu) and observe the lag, again. As noted above, I'm not sure if this should be a separate bug or if solving the first will solve both problems. But I wanted to add this is also happening in the business module, and the lag is consistently longer. (sometimes in an account register after repeated use, the context menu is more immediately responsive, it doesn't seem so in bills/invoices)
I've told a non-profit not to use 3.0 until further notice because of this stuff. I haven't had a chance to visit them recently but what Adrien says fits with their reported troubles getting invoices done. They have necessary boilerplate that needs to be in the right sequence in their invoices plus or interspersed with one or more money lines and they're saying they can't get their invoices right. I didn't really understand what they meant until I saw what Adrien said above.
This problem has been fixed in our software repository. The fix will go into the next software release, 3.1. Once that release is available, you may want to check for a software upgrade provided by your Linux distribution or on our website. For 3.1 the behaviour of the context menu has been reverted to how it behaved in 2.6.x. However I do stand by my position it really should be a combination of the default GtkEntry context menu (for text manipulation in the entry) and the gnucash provided higher level extensions. This will be re-evaluated in the future.
I can confirm this now works like 2.6.x using 3.1.2. (or is that now 3.1-2?) I don't have any unposted bills/invoices to test at the moment. I only tested in registers. Thanks for the fix!
Thanks for your feedback. And it's 3.1-2 now. The -x is only added if we have to repackage a release (that is if there's a packaging issue after tagging the release).
(In reply to Geert Janssens from comment #15) > Thanks for your feedback. And it's 3.1-2 now. The -x is only added if we > have to repackage a release (that is if there's a packaging issue after > tagging the release). That's what we do on Windows, but all Mac dmgs have a version suffix.
Oh, ok.
(In reply to Adrien from comment #14) > I can confirm this now works like 2.6.x using 3.1.2. (or is that now 3.1-2?) > I don't have any unposted bills/invoices to test at the moment. I only > tested in registers. > > Thanks for the fix! Thanks indeed. My right-clicky desires in the registers seem to satisfied and I'll be testing some business functions over the next day or so as "my" non-profit needs an update and I need to do some invoicing myself. P.S. did I miss this this being mentioned in the 3.1 announce ?
(In reply to Wm from comment #18) > P.S. did I miss this this being mentioned in the 3.1 announce ? It was forgotten indeed. I have now added it to the release announcement on the gnucash website and github.
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=794976. Please update any external references or bookmarks.