Description: LibreOffice should prompt for all input field values Steps to Reproduce: Open attach doc in version 5.4.7.2. Type value in first input field. Hit Enter. Second input field will be displayed. In version 6.0+ only the first input field is displayed. Actual Results: In version 6.0+ only the first input field is displayed. Expected Results: LibreOffice should prompt for all input field values Reproducible: Always User Profile Reset: No Additional Info:
Created attachment 143536 [details] libreoffice document
Reproducible with LO 4.4 (both input fields are displayed) and LO 6.2 (inly first input fields is displayed)
The behaviour changed after https://cgit.freedesktop.org/libreoffice/core/commit/?id=7d5245848c28f5786258476cd7aa2a4523645de3, where the previous/next navigation button were added, thus not considering it like a regression... The question is: is it a bug ?
(In reply to Xisco Faulí from comment #3) > The question is: is it a bug ? I think it's not really a bug, but it could be improved to make it more clear. Some ideas: a) The dialog actually is named "Input Field". So you might think, that it is only about the first field. So if the dialog would be renamed to "Input Fields" it might be more clear. b) Add tooltip to arrows: "next field" and "previous field" c) "OK"-Button should only be active if you've passed through all fields(is a problem in documents with a lot of fields)
(In reply to Dieter Praas from comment #4) > a) The dialog actually is named "Input Field". So you might think, that it > is only about the first field. So if the dialog would be renamed to "Input > Fields" it might be more clear. The simple plural is not a heureka moment. How about "Please review field values"? > b) Add tooltip to arrows: "next field" and "previous field" Absolutely, all unlabeled (at least) controls should get a tooltip. > c) "OK"-Button should only be active if you've passed through all fields(is > a problem in documents with a lot of fields) Wouldn't do that as users can change the first field only and confirm per Ok.
Heiko, Let me explain our use-case here. We have some documents, where what we used to do is: (1) open a template (2) input field dialog displays (3) fill in field (4) hit enter (5) LO would display the next field (if there was one) and goto (3) (6) print document out This workflow is no longer quite as slick, because now LO closes the dialog after the first field. If we don't want that behaviour, then I guess our people will just have to get used to using arrow keys or something similar. There is precedent for this in how calc behaves when you hit enter on a cell i.e. going to the next cell.
(In reply to Noel Grandin from comment #6) > Heiko, Let me explain our use-case here... Okay, it's the default button which associated event is activated on Enter. We can clear that or move the default to Next. Will try myself, but if Bernhard (the original author) is faster... I also wonder why we need the Edit button. ;-)
(In reply to Noel Grandin from comment #6) > This workflow is no longer quite as slick, because now LO closes the dialog > after the first field. When I press enter it adds a line break since the focus is always in the edit box. That's correct. And Cancel is never invoked for me. What I did in patch https://gerrit.libreoffice.org/#/c/58132/ is to add tooltips and accelerators for the previous/next field buttons. It's a dirty solution because alt+> and alt+< might not easily accessible on some keyboards but are hard coded to the buttons (there is no label taking the underscore). But at least we have something for discussion.
thanks for looking at this @heiko, my users like the idea of making the default button Next
(In reply to Noel Grandin from comment #9) > thanks for looking at this @heiko, my users like the idea of making the > default button Next I didn't change the default button since the focus is inside the edit field (cannot reproduce the cancel issue). What I did is to introduce tooltips and shortcuts. And all is up for discussion.
Adolfo on Gerrit (refusing to comment here): "The key bindings must not be hardcoded in the .ui-described tooltips; besides, they’re wrongly capitalized (it’d be “Alt”)." Without discussion I will not submit another patch, e.g. using characters "<" and ">" instead of icons.
(In reply to Heiko Tietze from comment #10) > What I did is to introduce tooltips and > shortcuts. And all is up for discussion. Should tooltips be already in the master? Couldn't finde them in master from 8/8/2018. Heiko, you suggested to name the dialog "Please review field values". I think the problem here is still, that you might think, that the dialog is only about the first field. So it should be clear, that it is about all fields. So my suggestion is "Review Fields"
(In reply to Dieter Praas from comment #12) > (In reply to Heiko Tietze from comment #10) > > What I did is to introduce tooltips and > > shortcuts. And all is up for discussion. > > Should tooltips be already in the master? Couldn't finde them in master from > 8/8/2018. No, my (bad( solution was rejected without providing alternatives. Meanwhile another comment came in from from Katarina Behrens "The original patch (by Bernhard) used stock buttons - gtk-media-previous and gtk-media-next. Then it was changed in https://cgit.freedesktop.org/libreoffice/core/commit/?id=c8780642a5e8dc0bdcc97940ee7d9cacdc64c928 for ... um, no good reason? So why not use those stock buttons again? They come w/ text outta the box (and textless buttons are a11y nightmare)" We can try this. > So my suggestion is "Review Fields" Okay, no hard feelings here.
heiko tietze committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=1188bebbc53d0519733cfe98cfab4d83474e8ddf tdf#118742 - Input field dialog workflow It will be available in 6.2.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.
The dialog takes now the stock buttons prev/next that comes with text and icon. And I also changed the title as Dieter suggested.
Thanks Heiko!
(In reply to Heiko Tietze from comment #8) > (In reply to Noel Grandin from comment #6) > > This workflow is no longer quite as slick, because now LO closes the dialog > > after the first field. > > When I press enter it adds a line break since the focus is always in the > edit box. That's correct. And Cancel is never invoked for me. It used to be Ctrl+Enter ;) If that could be linked for Next, would be great.
(In reply to Cor Nouws from comment #17) > It used to be Ctrl+Enter ;) Which was wrong as this combination enters a page break. The right shortcut is now alt+N/V (depending on your localization) coming from the button label, as shortcuts are applied usually.
Created attachment 144893 [details] Works as aspected... see the vide works as aspected. Version: 6.2.0.0.alpha0+ Build ID: 9a9b81c7212fa6a6762246593acf3f1950677a22 CPU threads: 4; OS: Linux 4.15; UI render: GL; VCL: gtk2; TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2018-09-08_00:00:43 Locale: ro-RO (ro_RO.UTF-8); Calc: threaded
(In reply to Heiko Tietze from comment #18) > (In reply to Cor Nouws from comment #17) > > It used to be Ctrl+Enter ;) > > Which was wrong as this combination enters a page break. A page break in the context of a text input field in useless. IIRC, there are more dialogs where Ctrl+Enter is used to launch the default button, if the focus is in a widget/control, that allows to use Enter. Will keep an eye on it and come back on this if needed.