With https://phabricator.kde.org/D16830 the file menu gets more entries. This is a suggestion to do some cleanup before.
This is the corresponding patch for Kate: https://phabricator.kde.org/D17138 (screenshots and general discussion are there)
With https://phabricator.kde.org/D16830 the file menu gets more entries. This is a suggestion to do some cleanup before.
This is the corresponding patch for Kate: https://phabricator.kde.org/D17138 (screenshots and general discussion are there)
No Linters Available |
No Unit Test Coverage |
Buildable 5321 | |
Build 5339: arc lint + arc unit |
Hm, is this really a good idea? Right now, the File menu is rather flat, which is a good thing imo. Do we really want to move Save operations into a "Save Variants" sub menu?
Please no.
File -> Save is one of the most universal menu entries, found in nearly every program that *has* a set of menus. Print is nearly as common.
This breaks a user assumption that's been ingrained across virtually all GUI software for decades, and makes common operations more cumbersome (although I assume many users prefer the shortcuts), for the sake of a few lines in the menu.
@cullmann You did not seem to have strong objections to this. Can you comment on this here again?
I think grouping these not that often used things is ok.
I would keep "save as" toplevel.
One thing to clarify: How do we get the "Save All" of Kate inside the file_save2 menu? I assume we should name the menu better and reuse that name inside kateui.rc.
Maybe file_save_alternatives or as Gregor once suggested file_save_variants. Or file_save_extended.
Btw, do we have an issue that Kate (kateui.rc) and KTextEditor (katepart5ui.rc) use different release schedules? Does that imply issues with XMLGUI merging?
+1 for leaving Save As on top level.
Just for reference the File menu of the current master on my screen :)
As for me, at least all the Close actions could be moved into a submenu.
For:
Maybe file_save_alternatives or as Gregor once suggested file_save_variants. Or file_save_extended.
Btw, do we have an issue that Kate (kateui.rc) and KTextEditor (katepart5ui.rc) use different release schedules? Does that imply issues with XMLGUI merging?
But as normally the frameworks are more up-to-date then the application, the only thing normal users should see is a submenu with the KTextEditor stuff inside and the save all toplevel.
Btw., I think the menus do lack the *_merge markers.
In terms of the submenu text, I just noticed that we already have "Find Variants" in the Edit menu, so I'm okay with using "Save Variants" and "Close variants" for consistency. We can decide later whether we want to keep that style.
If there are no further comments, would proceed with:
src/data/katepart5ui.rc | ||
---|---|---|
2 | Increase version |
This is what is looks like now (together with latest changes from https://phabricator.kde.org/D17138):
What I wonder: during the work with the .rc menu files I noticed that even the menu in Kate which is installed in root got affected by the changes I made in the development version and I had to regularly change the version number to make changes take effect. Is this normal?
Sadly is the benefit, to reduce the menu entries, not "optimal". In the pics you have now 3 sub-entries for one "Variant" entry, effectively only 2 less per topic.
I may like it if these "Variant-Action" could be avoided and merged with one of the "Normal-Action", but guess that will find someone too progressive/uncommon and I'm not sure if that is technically possible by Qt.
What? Well, e.g hovering "Save As..." offer entries from "Save Variants" but click on it still do "Save As..."
I think we need to start here from scratch.
Gregor, if you have some time again, open a new request please!