I'm not sure which component this corresponds to; I apologize. This comes from the discussion at https://bugs.kde.org/show_bug.cgi?id=202414 . Proposal -------- If an interface has a top level View menu, and menu items which toggle the visibility of interface elements, then those menu items should be placed under View. Current Status (an incomplete sampling) --------------------------------------- Gwenview: ☑ Sidebar ☒ Toolbar ☒ Statusbar Dolphin: ☑ Panels ☒ Toolbar Okular: ☒ Toolbar ☒ Navigation Panel ☒ Page Bar Karbon: ☑ Page Margins ☑ Rulers ☑ Color Palette ☑ Grid ☑ Guides ☒ Toolbars ☒ Docker Titlebars ☒ Individual Dockers Krita: ☑ "Canvas only" (everything not-canvas) ☑ Rulers ☑ Guides ☑ Status Bar ☑ Grid ☑ Painting Assistants ☑ Assistant Previews ☒ Toolbars ☒ Docker Titlebars ☒ All Dockers ☒ Individual Dockers Calligra Words: ☑ Rulers ☑ Guides ☑ Grid ☑ Comments ☑ Word Count ☒ Toolbars ☒ Docker Titlebars ☒ Status Bar ☒ Individual Dockers Depending on implementation considerations, this proposal might be extended to add a top-level View menu when one is not present.
They should be in the Settings menu, if the status is saved across invokations.
(In reply to Christoph Feck from comment #1) > They should be in the Settings menu, if the status is saved across > invokations. Can you please explain the usability rationale behind this? It seems very obviously counterintuitive to me to depart from the traditional visibility-under-View paradigm, which is partially implemented here. As a user I can see no logic in keeping visibility toggles somewhere other than the View menu.
(In reply to Christoph Feck from comment #1) > They should be in the Settings menu, if the status is saved across > invokations. I'll add that *many* other menu items, not under Settings, have persistent effects across invocations.
(In reply to Christoph Feck from comment #1) > They should be in the Settings menu, if the status is saved across > invokations. Can you please offer rationale for your counter-proposal, and clarify whether you are suggesting that all menu items with persistent effects, from all categories, be moved to the Settings menu?
I agree with your original proposal. Putting all actions that save their state in the Settings menu is a fairly implementation-centric UI. I think a user-focused UI of location actions based on function makes more sense and this is in fact what we already generally do. However I'm afraid there's nothing actionable in this bug report at the KXMLGui level. View actions that are common to many KDE apps are already all in the View menu; everything you're proposing will require changes to the individual apps themselves, as those items are specific to those apps. You'll want to open a new bug report for each app.
(In reply to Nate Graham from comment #5) Please note that this was part of bug 202414 for gwenview, which begins 'Please add another entry to "view" menu...' The bug was "resolved" while ignoring this. I requested that the bug be kept open until/unless actually resolved. The developer who implemented the fix, Valerio Pilo, said that while he agreed it should be done, "it's a change that has to be planned and done desktop-wide. Propose it!" And that is what I've tried to do here. Are you sure it should be done on a purely individual basis, and not as previously suggested as a "desktop-wide" guideline to be established first? Regarding process, I don't see a description of "MOVED" at https://bugs.kde.org/page.cgi?id=fields.html#bug_status -- is there a description of that status elsewhere?
I don't think it's very controversial that view-related actions should be in the view menu. However for general discussion points we tend to use Phabricator tasks rather than bug reports, which are more intended for discrete bugs and feature requests. RESOLVED MOVED basically means "we should have the discussion somewhere else".