Bug 79877 - Option to revert to old Pop-Up edit method for Input Fields
Summary: Option to revert to old Pop-Up edit method for Input Fields
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.2.4.2 release
Hardware: All All
: medium enhancement
Assignee: Bernhard
URL:
Whiteboard: target:6.0.0
Keywords:
: 75319 108522 (view as bug list)
Depends on:
Blocks: Fields
  Show dependency treegraph
 
Reported: 2014-06-10 11:51 UTC by Charles
Modified: 2018-08-15 21:17 UTC (History)
13 users (show)

See Also:
Crash report or crash signature:


Attachments
Simple Template illustrating the bug (56.12 KB, application/vnd.oasis.opendocument.text-template)
2014-10-03 12:09 UTC, Charles
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Charles 2014-06-10 11:51:04 UTC
Hello,

I have been getting nothing but complaints and users begging me to downgrade them back to 4.1.6 after updating them to 4.2.4, just for this one new feature.

The new inline method for editing Input Fields in text templates is simply much less convenient and more error prone - even if/when the current problem of not being able to copy/paste from/into these fields is fixed.

Personally, I can see the argument for both ways, but I also can say that these pop-up fields is one thing that I have always liked *better* than the inline way that Microsoft does it.

I am begging the Libreoffice development team to provide a simple user preference/option to allow reverting to the old behavior of editing these fields in pop-up mode.

Please, please please allow the users the choice.

Thanks for listrening.
Comment 1 mchan223 2014-07-08 03:54:09 UTC
Seconded. The inline method is awkward and obscures the nature what you're actually doing - as someone who's had to work with the Word implementation for years now I must say LO's old popup method was vastly preferable.
Comment 2 mchan223 2014-07-08 05:02:12 UTC
That said, I really don't want to give the impression that I think the current situation is anywhere near as bad as it is in Word. Only being able to put text in the field with no in-field formatting allowed still saves me a world of headache and I'm still generally able to easily tell where one field ends and another begins.

I've seen some discussion elsewhere about possibly making double-clicking on an input field bring up the old popup, but a preference that could be turned on and off would probably be better for the mouse buttons and fingers of people who will ordinarily use that method rather than inline.
Comment 3 Michael Meeks 2014-10-03 10:47:28 UTC
Can you confirm that this worked in LibreOffice 4.1.x ? If it is the MS Office compatible text fields work that was done way back in the 3.x series.
And/or can you attach a simple sample document with idiot-user instructions: "move the cursor to here", "type XYZ" etc. that has this feature working as you like it in 4.1.x ?
Thanks.
Comment 4 Charles 2014-10-03 12:07:50 UTC
Hi Michael,

Thanks very much for taking a look at this!

(In reply to Michael Meeks from comment #3)
> Can you confirm that this worked in LibreOffice 4.1.x?

Yes, this worked perfectly in 4.1.x and all prior versions. We've been using Libreoffice since its first official release, and Openoffice prior to that, since version 1.0 was released. I honestly don't remember when 'Input fields' were introduced or when we started using them, all I know is that we have been using them for a very long time - I'd have to say at least since about 2003 or so.

> If it is the MS Office compatible text fields work that
> was done way back in the 3.x series.

This is definitely not that - here is the bug responsible for this new inline editing of Input Fields (again, introduced in 4.2):

https://issues.apache.org/ooo/show_bug.cgi?id=33737

So...

>= 4.2 introduced the new 'Inline Editing' method for editing Input Fields, which is the way Word has always worked.

<= 4.1.x edits existing Input Fields in the same pop-up dialog that, incidentally, is still used in 4.2+ when populating them the very first time (it cycles through them all, then the dialog closes), when creating a new document from one of the templates.

I understand the desire that people have for doing it this way, and in fact, I have come around to not hating it, but I still prefer the old way, hence this bug/enhancement request.

> And/or can you attach a simple sample document with idiot-user instructions:
> "move the cursor to here", "type XYZ" etc. that has this feature working as
> you like it in 4.1.x ?

Certainly, but it will just be a simple one for demonstration purposes (our forms mostly have confidential info in them). We have dozens of forms (saved as templates - ie, .ott) with lots of Input Fields (some with 30 or more) that were created many years ago, and have never had a problem with them until the 4.2.x series.

Thanks very much again Michael for taking a look at this, even if it is just to confirm it...
Comment 5 Charles 2014-10-03 12:09:26 UTC
Created attachment 107260 [details]
Simple Template illustrating the bug

Simple Template illustrating the bug (inability to paste into an Input Field) and other problems with the new Inline Editing feature
Comment 6 Cor Nouws 2014-11-05 11:43:06 UTC
*** Bug 75319 has been marked as a duplicate of this bug. ***
Comment 7 Charles 2014-11-05 12:35:42 UTC
Oh, one more thing...

I would be perfectly happy if, instead of an option, a new 'feature' was added that allowed the user to open the pop-up dialog for a field by simply dbl-clicking the field.

Maybe this would be much easier than having to deal with the code required to add an option that could be enabled/disabled?
Comment 8 Charles 2014-11-06 13:58:24 UTC
Ok...

The new in-line editing of Input Fields feature was apparently inherited/pulled from Apache Openoffice.

Atila created an issue for this for Apache Openoffice, and the developer there who was responsible for the new in-line editing feature appears to be interested ini adding this new feature to allow for dbl-clicking a field to pop-up the old field editor. He also is interested in adding a new 'Previous' button to work in conjunction with the 'Next' button, to allow for cycling through the fields in both directions. I added my comments and thoughts there, so hopefully this will get fixed there:

https://issues.apache.org/ooo/show_bug.cgi?id=125108
Comment 9 V Stuart Foote 2017-06-22 17:10:08 UTC
*** Bug 108522 has been marked as a duplicate of this bug. ***
Comment 10 V Stuart Foote 2017-06-22 17:22:07 UTC
The in-place field editing is very useful, but as noted the old dialog really was efficient for sequentially completing a form template, and unfortunately the current "Edit Fields" dialog does not provide editing of the field values. You can change the field(s) but not the actual content. Not the best for completing a form.

While the old dialog probably needed to go, the "Edit Fields" dialog needs rework to supplement the in-place field editing.
Comment 11 Samuel Mehrbrodt (CIB) 2017-07-25 12:54:54 UTC
(In reply to V Stuart Foote from comment #10)
> While the old dialog probably needed to go, the "Edit Fields" dialog needs
> rework to supplement the in-place field editing.

I think the old dialog still has its value as you can simply enter the values without all the clutter the "Edit fields" dialog has.

The old dialog is still there and appears at startup when opening a document which has fields, e.g. the attachment on this bug.
It can also be accessed via Ctrl-Shift-F9.

I think entering values in a field is used much more often than editing a field, so maybe changing the double click action to open the old dialog makes sense. And by now it should be clear that in-field editing is not the best option for many use cases.

== Suggestion: ==
As you can reach the "Edit Field" dialog via the context menu, we should change the double click action to open the "old" dialog instead.

Would you be ok with this solution?
Comment 12 V Stuart Foote 2017-07-25 15:22:00 UTC
(In reply to Samuel Mehrbrodt (CIB) from comment #11)
> == Suggestion: ==
> As you can reach the "Edit Field" dialog via the context menu, we should
> change the double click action to open the "old" dialog instead.
> 
> Would you be ok with this solution?

Yes it would be reasonable to change double click action the open "old" Input Fields dialog (rather than the Edit Fields dialog). 

But the "old" dialog (currently reached with F9_SHIFT_MOD1)  needs refactoring that would make it suitable to task:

1.) "old" dialog's default is to now position at the start (the first text:text-input field) in the document. Instead the dialog should open positioned to the field with cursor focus and the double-click originates.

2.) the "old" dialog needs a Previous button action to complement the Next button. In other words logic to allow movement in both directions through fields of the form--currently it is one way sequential from start of form.
Comment 13 Cor Nouws 2017-07-26 08:58:53 UTC
(In reply to V Stuart Foote from comment #12)

> > Would you be ok with this solution?
> 
> Yes it would be reasonable to change double click action the open "old"
> Input Fields dialog (rather than the Edit Fields dialog). 

Good idea,

> But the "old" dialog (currently reached with F9_SHIFT_MOD1)  needs
> refactoring that would make it suitable to task:
> 
> 1.) "old" dialog's default is to now position at the start (the first
> text:text-input field) in the document. Instead the dialog should open
> positioned to the field with cursor focus and the double-click originates.
> 
> 2.) the "old" dialog needs a Previous button action to complement the Next
> button. In other words logic to allow movement in both directions through
> fields of the form--currently it is one way sequential from start of form.

Even better.
Comment 14 Commit Notification 2017-09-16 16:11:53 UTC
Bernhard Widl committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=ad7bc2f7bbf8497ec83c65719ac0d65459293480

tdf#79877 add button text for 'previous' button (gtk-media-previous)

It will be available in 6.0.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 15 Commit Notification 2017-09-18 23:12:24 UTC
Bernhard Widl committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=7d5245848c28f5786258476cd7aa2a4523645de3

tdf#79877 revert to old behavior when clicking on input fields.

It will be available in 6.0.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 16 V Stuart Foote 2017-09-19 04:56:26 UTC
On windows 10 Pro 64-bit en-US with
Version: 6.0.0.0.alpha0+ (x64)
Build ID: 7d5245848c28f5786258476cd7aa2a4523645de3
CPU threads: 8; OS: Windows 6.19; UI render: GL; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2017-09-19_00:44:40
Locale: en-US (en_US); Calc: CL

Thank you Bernhard!

Behavior seems functional now. 

The double click on a field value launch of the Input Field dialog works nicely.

Kind of seems the Edit -> Fields... entry needs adjustment to "Edit Field" (as for bug 112382) and that this needs its own Edit menu entry "Input Field" to pop open the dialog.
Comment 17 Cor Nouws 2017-12-24 19:27:28 UTC
(In reply to V Stuart Foote from comment #16)
> Behavior seems functional now. 

Indeed - Thanks Bernhard & Thorsten.
Set to Fixed

> Kind of seems the Edit -> Fields... entry needs adjustment to "Edit Field"
> (as for bug 112382) and that this needs its own Edit menu entry "Input
> Field" to pop open the dialog.

Different bug..
Comment 18 Cor Nouws 2017-12-24 19:27:51 UTC
thanks again!

Verified in Versie: 6.0.0.1
Build ID: d2bec56d7865f05a1003dc88449f2b0fdd85309a
CPU-threads: 4; Besturingssysteem: Linux 4.13; UI-render: standaard; VCL: gtk2; 
Locale: nl-NL (nl_NL.UTF-8); Calc: group
Comment 19 Commit Notification 2018-07-10 10:32:27 UTC Comment hidden (off-topic)
Comment 20 Commit Notification 2018-07-11 10:04:32 UTC Comment hidden (off-topic)
Comment 21 D.F. 2018-08-14 19:03:29 UTC
Hi,

great thing, to get the old input-field dialog back.
One small favour I would like to ask, though. ;-)

Whenever you double-click you generally intend to change the value within the input-field. So it would be great if the existing content would be selected as default [as it was with the old input-field dialog].
At the moment you will have to double-click the content to start editing.
It would be great if this could be implemented.
Thanks!
Comment 22 V Stuart Foote 2018-08-14 20:08:39 UTC
(In reply to D.F. from comment #21)

> One small favour I would like to ask, though. ;-)
> 
> Whenever you double-click you generally intend to change the value within
> the input-field. So it would be great if the existing content would be
> selected as default [as it was with the old input-field dialog].
> At the moment you will have to double-click the content to start editing.
> It would be great if this could be implemented.

Sure, but please open a new issue.
Comment 23 D.F. 2018-08-15 19:30:29 UTC
Done that. Filed it under  #119303. Thanks!