GNOME Bugzilla – Bug 634357
Menu UI cleanup: Remove menu items Budget New / Open from file menu
Last modified: 2018-06-29 22:46:54 UTC
Created attachment 174097 [details] [review] Move the Budget Open/New menu items to Actions -> Budget -> New Budget / Open Budget because they have nothing to do with the file menu. I propose to remove the "New Budget" and "Open Budget" menu items from the File -> New and File -> Open menu, respectively. Those are not related to the file or database, but rather to individual items contained within the currently open file. Hence, they should appear in a different menu. I propose to move them to Actions -> Budget -> "New Budget" / "Open Budget", similar to the business menu items or the scheduled transaction menu items. Attached patch does this. Also, I propose to remove anything from "File -> New / Open" that is not related to the top-level file or database itself. The second patch does that as well. In fact, I haven't even noticed those other items under File -> New or Open until I searched through the ui.xml files, which is a good indication that I have never looked for those in the file menu. But most importantly I want to get rid of the "Open Budget" right next to the "Open File", because those actions are on a completely different level.
Created attachment 174098 [details] [review] Further menu ui cleanup: The File New/Open items relate only to the file (database), not to anything within a file.
Seems like a good idea to me. I've thought before that this was confusing.
Does this mean a new menu i.e. does Actions -> Budget already exist? Will this mean a new string for translation? In general, I like the idea.
(In reply to comment #3) > Does this mean a new menu i.e. does Actions -> Budget already exist? Will this > mean a new string for translation? No new string (but good that you asked). There is already a string saying "B_udget" which can be used, or one string "Budget" if the "u" shortcut is already taken in that menu.
While I like the idea, I think it's a bit late in the 2.4 development cycle to be doing things like this if we're going to release 2.4 anytime soon. Yes, I understand that it's a fairly straightforward UI change which has no effect on underlying function or code. But if not here, where do we stop? Or is 2.3.16 not really a release candidate? (Yeah, I know I'm the one who said that it should be in the first place, but Phil repeated it in the release announcement.)
(In reply to comment #0) > [...] I have to say I love these ideas. But practically speaking, 2.3.16 is being prepped for release now as 2.4.0, and we have this cool new database backend users want to migrate to. I haven't really noticed much feedback indicating user confusion about the menu structure (beyond the general levels of `Where is that feature?' expected from new users as they discover the UI) ... so from general chatter in the lists I'd say put more immediate priority on 2.4.0 with SQL, WebKit, eguile etc. But right after that--how about we put this in the 2.5 branch and get 2.6.0 out the door real fast, like in 3--6 months? If we do that, I also have some suggestions for main window menu cleanup (I've elided the menus I don't want to change, and expanded the ones I do): File New Open... [... everything else ...] Export Accounts... [... everything else ...] Edit View [... everything that's there already ...] -- Scheduling Reminders [renamed from Actions > Scheduled Transactions > Since Last Run...--more discoverable at expense of move to slightly less topical location, IMO worth it, and GnuCash does have more confusing UI than this :-] Price Editor Security Editor Financial Calculator General Ledger Actions [delete this] Reset Warnings... [IMO this should be somewhere in Preferences] Rename Page [delete--IMO there's no benefit from this, and some potential for confusion] Accounts [everything to do with manipulating accounts] New... [these commands manipulate one account at a time] Open Edit Delete -- Stock Split... View Lots... -- Transfer... [these commands manipulate >1 account at a time] Reconcile... Auto-Clear... Repair... [make this a dialog, maybe an assistant] Close Book Planning Schedule Transactions [make this a verb-noun menu item name to clarify] Mortgage & Loan Repayment... -- New Budget... [... other budget menu items ...] Online Setup... Get Balance Get Transactions... Issue Transaction... Internal Transaction... Direct Debit... Business Reports Help The above structure gets rid of all submenus, which I think greatly improves UI discoverability. What do you all think? Cheers
(In reply to comment #6) In this bug I specifically addressed *only* the issue with the "Open Budget" item being *very* badly placed in File -> Open -> ... Intentionally, I would *not* want to start reorganizing the complete menu structure at this point in time. Hence, I *only* want to change the weird File -> Open -> ... submenu but not any of the others for now. @Yawar: I'd propose to move your proposals (which are good) to another bug and discuss it some more, then implementing it probably after 2.4.0 is out. Re version 2.6.0: When honestly thinking about this, I think we have to admit a follow-up 2.6.0 release will not happen within a few months, even though it might have made some sense. But the way the project is structured currently just won't make that happen.
I think this is a good change. Regarding the timing, I'm tempted to do this before 2.4 still. Doing so would indeed mean we have to create a second release candidate though. At this point, bug #633550 hasn't been fixed yet either, which is marked for 2.4. If that bug is to be fixed (which Derek promised it would be), we have to do another release candidate anyway. So my conclusion would be, go ahead and let's do a new release candidate as soon as possible (which also requires bug #633550 to be fixed or at least worked around).
Comment on attachment 174097 [details] [review] Move the Budget Open/New menu items to Actions -> Budget -> New Budget / Open Budget because they have nothing to do with the file menu. This first not-so-large change is committed, given the comments here. I'm somewhat hesitating to commit the second patch, which would remove the extra submenus File->Open and File->New and turn them into plain menu items.
Hi Christian, (In reply to comment #7) > (In reply to comment #6) > In this bug I specifically addressed *only* the issue with the "Open Budget" > item being *very* badly placed in File -> Open -> ... Intentionally, I would > *not* want to start reorganizing the complete menu structure at this point in > time. Hence, I *only* want to change the weird File -> Open -> ... submenu but > not any of the others for now. Oh, absolutely. Given also that we have an outstanding bug that needs to be fixed before 2.4.0, and we're doing an RC2, the budget menu items change is very feasible now. I'll let Cristian Marchi know as well, I know he's working on the docs for the menus but I don't think he's following this bug. > @Yawar: I'd propose to move your proposals (which are good) to another bug and > discuss it some more, then implementing it probably after 2.4.0 is out. Sure, that was always my intention to keep (biggish) UI changes for 2.5--6. I've filed a bug 634456 to move the discussion there. > Re version 2.6.0: When honestly thinking about this, I think we have to admit a > follow-up 2.6.0 release will not happen within a few months, even though it > might have made some sense. But the way the project is structured currently > just won't make that happen. Yeah, a little wishful thinking on my part. If we had an infusion of devs like a GSoC sponsorship, maybe :-)
(In reply to comment #9) > (From update of attachment 174097 [details] [review]) > This first not-so-large change is committed, given the comments here. Sounds good, at any rate budgets shouldn't be under the file menu, they're not stored as separate files. > I'm > somewhat hesitating to commit the second patch, which would remove the extra > submenus File->Open and File->New and turn them into plain menu items. Always good to have plain menu items instead of submenus, but the Actions menu is starting to become a kind of halfway-house for all the menu items in search of a real home :-) Anyway--let's do it for now and change it later if/when we decide on a better solution.
Somewhat apropos to this discussion, there was a discussion on IRC today about the "save" button and menu item with databases. A couple of users suggested rather forcefully that instead of being disabled, those items should be hidden when the session is a database, because they're never useful in that case. It's not something I'd advocate for 2.4 (in fact I'm not sure that it's the right thing to do), but this seems a good place to mention it before it wanders into some dark alley of my brain.
(In reply to comment #12) > [...] > A couple of users suggested > rather forcefully that instead of being disabled, those items should be hidden > when the session is a database, because they're never useful in that case. These `forceful' users should open up a UI bug for this and justify it there :-) I know I'd be interested to weigh in with a comment.
If anyone is up to this, the file submenus "File -> New -> New" and "File -> Open -> Open" can now be turned into plain menu items instead of submenus, because with r19806 no other place in gnucash uses those submenus. But the main cleanup issue of this bug is already completed, so I'll close here.
(In reply to comment #14) > If anyone is up to this, the file submenus "File -> New -> New" and "File -> > Open -> Open" can now be turned into plain menu items instead of submenus, > because with r19806 no other place in gnucash uses those submenus. But the main > cleanup issue of this bug is already completed, so I'll close here. I have committed r19815 to change this last bit.
I've commited to rev. 19829 a patch for the GnuCash help to reflect the changes introduced by UI modifications discussed in this bug.
(In reply to comment #16) > I've commited to rev. 19829 a patch for the GnuCash help to reflect the changes > introduced by UI modifications discussed in this bug. Great, thanks !
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=634357. Please update any external references or bookmarks.