| Summary: | Context Menus(RMB) for text edits | ||
|---|---|---|---|
| Product: | [Unmaintained] HIG | Reporter: | Frans Englich <frans.englich> |
| Component: | general | Assignee: | Celeste Lyn Paul <celeste> |
| Status: | RESOLVED UNMAINTAINED | ||
| Severity: | wishlist | CC: | fabian |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
I do not understand.
Konsole can never have Paste, should it always take space as an disabled
option? And there ARE read only areas too...
The only mandatory option would be Copy, but what about when no text is
selected?
The same is true for Undo/Redo, konqueror could allow undo for the last
characters entered (before pressing return) with close readline
integration. But the only possible undo action would be to remove everything
written on the current line - would that be expected?
(Undo the previous command would be nice but rather difficult...
> rm -rf /
as it removes every file on the computer without asking...
Showing an Undo option might even indulge the user in false expectations)
Spell check - OK. But could be an wish for the widget.
key cuts - Drag&Drop (do you mean when dropping a file like in kmail, konsole
text edit window) might be a missing feature. An rather unimportant one since
your hand is on the mouse not on the keyboard. (But accessability might require that all options needs to be accessible by keyboard only). I see no HIG/general
problem here...
regarding size - this contradicts your other cases. You want some options that
NEVER can be of use to always be disabled on the context list, at the same time
you want the list to have a maximum length...
I really think that this bug report is invalid. And that closing it and
open specific wishes (one for bug D&D drop, and one for spell check) would
increase the chance to get it done...
BTW the bug is Assigned To you, Frans. Have you taken responsibility
to modify the HIG? (or source)
|
Version: (using KDE Devel) Installed from: Compiled sources Clear guidelines on context menus are needed, especially for text edits. Currently, judging from central applications such as kicker/kdesktop, kmail, konsole, kmail, and konqueror, there's quite some inconsistency. What to name entries, must be explicit. For example, the "Copy" text entry have various versions: Copy to Clipboard Copy Copy text It must also be specified what entries are mandatory. For example, some applications do not at all have Cut/Copy/Paste, while some do. There exist three cases, AFAICT: * Readonly text area(Copy only usable) * "Add only" -- paste, copy, but not cut(konsole for example) * Write/Read text area(cut, copy, paste) Another inconsistency is Undo/Redo; some have while other don't. In other words, there's a diversity in different types of text areas. One possibility is to have different kinds of context menus for each type(more or less as it is now), or have one layout, and disable the inappropriate entries, as consistency usually is solved in menus. KDE has a very high level of integration(which of course is good); parts appears everywhere; from app A to app B. This suggests menus from slightly different uses should be kept as similar as possible, in order to make the high integration as subtle -- and integrated -- as possible. What entries to have, such as Undo/Redo, is perhaps tied to in what context RMBs are used; when the user is working with the text, or when switching between applications? In what case is Undo/Redo needed? Weighted in, should also be how high its usefulness is in contrast to how much the sheer amount of entries is boosted. Another inconsistency is spell checking; it varies from kmail, konqueror, to KOffice. Application menus should also be consistent in this. KMail have different menus for incorrectly spelled words, and those who are correct, which is a dynamically built interface, and is a restricting mode; depending on context, different functionality is available. This needs clarification. Another issue is showing key cuts in menus; some menus(Drag&Drop) do not show the corresponding key cut. This needs clarification; emphasizing, and urging developers to put key cuts(proper use of KAction/KStdAction). Context menus grows very large(kmail) and what entries to have is, as discussed, inconsistent. The guidelines needs to be very clear on what is mandatory, and what is optional, and in what order to have them. Perhaps there should be an upper definite limit on the number of entries(including delimiters?), in order to put a "roof" on the complexity. KDE's minimum screen size(800x600) needs to be taken into account. This is how a context menu layout could look like: Cut Copy Paste <delimiter> <grammar checking, something> <delimiter> <application specific entries> <delimiter> Properties Entries are then disabled, instead of building custom menus. Cheers, Frans