| Summary: | Place visibility-toggling menu items under the View menu, when present | ||
|---|---|---|---|
| Product: | [Frameworks and Libraries] frameworks-kxmlgui | Reporter: | AndyKluger |
| Component: | general | Assignee: | kdelibs bugs <kdelibs-bugs> |
| Status: | RESOLVED MOVED | ||
| Severity: | wishlist | CC: | AndyKluger, nate, un4tt3nd3d, vpilo |
| Priority: | NOR | ||
| Version: | 5.34.0 | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
AndyKluger
2017-06-06 17:08:06 UTC
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". |