| Summary: | Allow changing variable name | ||
|---|---|---|---|
| Product: | LibreOffice | Reporter: | Luke Kendall <luke.kendall> |
| Component: | Writer | Assignee: | Not Assigned <libreoffice-bugs> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | enhancement | CC: | dgp-mail, libreoffice-ux-advise, xiscofauli |
| Priority: | medium | Keywords: | needsUXEval |
| Version: | 6.4.3.2 release | ||
| Hardware: | All | ||
| OS: | All | ||
| See Also: | https://bugs.documentfoundation.org/show_bug.cgi?id=135609 | ||
| Whiteboard: | |||
| Crash report or crash signature: | Regression By: | ||
| Bug Depends on: | |||
| Bug Blocks: | 129294 | ||
| Attachments: | Sample document | ||
|
Description
Luke Kendall
2020-06-20 09:11:36 UTC
(In reply to Luke Kendall from comment #0) > The name of the function "Edit fields" and the sketchy help pages (like > https://help.libreoffice.org/6.4/en-GB/text/swriter/01/04090300. > html?&DbPAR=WRITER&System=UNIX) implies you should be able to edit a field > you have inserted. Help says: "When visible, opens a dialogue box to edit the contents of the field.". In case of a variable it is grayed out, so I think, help is correct here. An I assume, that there are some reasons, why you can't edit a variable. (In reply to Dieter from comment #1) > (In reply to Luke Kendall from comment #0) > > The name of the function "Edit fields" and the sketchy help pages (like > > https://help.libreoffice.org/6.4/en-GB/text/swriter/01/04090300. > > html?&DbPAR=WRITER&System=UNIX) implies you should be able to edit a field > > you have inserted. > > Help says: "When visible, opens a dialogue box to edit the contents of the > field.". In case of a variable it is grayed out, so I think, help is correct > here. An I assume, that there are some reasons, why you can't edit a > variable. @Luke, do you agree with Dieter's comment ? I don't really agree, even though you /could/ read the words to mean that. The words would be clearer if they said "Unless the field is greyed out, ..." but that still leaves the key issue: you can't edit them. As it stands the help and the functionality together produce a Catch 22: - you can edit the things when they're not greyed out - they're always greyed out, so in practice you can't edit them I'm not sure now, if your aim is, that 1) LO help is improved => change component to "Documentation" 2) LO gives you the possibility to edit variable fields => This would be an enhancement request I think (In reply to Dieter from comment #4) > I'm not sure now, if your aim is, that > 1) LO help is improved => change component to "Documentation" > 2) LO gives you the possibility to edit variable fields => This would be an > enhancement request I think Waiting for a response My preference, because it would be useful to be able to edit a field, would be to make the bug an enhancement (to provide the implied functionality). My 2nd preference, if that can't be done, would be to clarify the documentation to explain you cannot edit a field, despite the fact that the functionality appears to have been planned. (In reply to Luke Kendall from comment #6) > My preference, because it would be useful to be able to edit a field, would > be to make the bug an enhancement (to provide the implied functionality). I guess renaming is prevented in order to protect the user from making mistakes, shooting themselves in the foot. Let's ask UX what they think. There is bug 111888 for a variable UX overhaul (In reply to Buovjaga from comment #7) > (In reply to Luke Kendall from comment #6) > > My preference, because it would be useful to be able to edit a field, would > > be to make the bug an enhancement (to provide the implied functionality). > > I guess renaming is prevented in order to protect the user from making > mistakes, shooting themselves in the foot. Let's ask UX what they think. > > There is bug 111888 for a variable UX overhaul I'm not sure in what way it could lead to causing the user to create errors, but even if there were, I'd hope the function could either: 1) check and adjust to use the new edited value wherever it was previously used, or 2) offer to create a new field with the new properties. In either case, if there's only a single use, I suspect no errors could be caused. But you would all know better than me about the consequences and effects. (In reply to Luke Kendall from comment #8) > I'm not sure in what way it could lead to causing the user to create errors... You may have a reference to the variable like Section1 visible if Test is 1. Renaming requires to reverse parsing all references, which may cause some trouble. I'd rather reconsider the workflow and question why renaming is needed. Guess something like "Test" going into "Productive" later. The help is clear on what you can do, and the UI too with disabled controls. |