After fixing tdf#79877 [1], the Input Field from Variables tab is now edited using a pop-up dialog, instead of previous in-place edit method. But we have more than one Input Field :-) - and the other one is on Functions tab of Fields dialog. The latter still uses in-place edit method, as of Version: 6.2.2.1 (x64) Build ID: fcd633fb1bf21b0a99c9acb3ad6e526437947b01 CPU threads: 12; OS: Windows 10.0; UI render: GL; VCL: win; Locale: ru-RU (ru_RU); UI-Language: en-US Calc: CL Should it be synchronized with the Input Field from Variables tab for consistency? [1] https://git.libreoffice.org/core/+/7d5245848c28f5786258476cd7aa2a4523645de3
(In reply to Mike Kaganski from comment #0) > After fixing tdf#79877 [1], the Input Field from Variables tab is now edited > using a pop-up dialog, instead of previous in-place edit method. But we have > more than one Input Field :-) - and the other one is on Functions tab of > Fields dialog. I can confirm this.
(In reply to Mike Kaganski from comment #0) > After fixing tdf#79877 [1], the Input Field from Variables tab is now edited > using a pop-up dialog, instead of previous in-place edit method. But we have > more than one Input Field :-) - and the other one is on Functions tab of > Fields dialog. Hm I see no difference to the other input field. Single click activates inline editing mode while double click opens the dialog to edit the value. Am I missing something? Can you maybe create a test document with an example?
(In reply to Samuel Mehrbrodt (CIB) from comment #2) > Hm I see no difference to the other input field. Single click activates > inline editing mode while double click opens the dialog to edit the value. Oh! For me both on Windows and on Ubuntu, with all recent versions, including master, single-click on Input Field from Variables tab activates the same dialog - could that be some overlooked unintended consequence specific for the field on Variables tab then? Or did I misunderstand something - possibly it's the other field was modified to have two edit modes, while this one still only allows one using dialog?
Ok so there is a difference between the input field from the Variables tab and the Functions tab. Bug 79877 implemented the new behavior for fields from the Functions tab. The same should be done for fields from the Variables tab. Single click should allow in-place editing while double click should open the input dialog. The field properties dialog should be reachable via context menu.
Michael Stahl committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/742baabbe4d077e1ba913a7989300908f4637ac7%5E%21 tdf#123968 sw: use inline editing for input fields for variables It will be available in 6.3.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Samuel Mehrbrodt committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/053b1417137b0cdec4e4fed7ae0c57cf67ff2698%5E%21 tdf#123968 Test that imported field is editable It will be available in 6.3.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
[tag] [reply] [−]DescriptionPaul McAuley 2016-12-30 04:42:50 UTC Description: http://www.iu-bloomington.com/ If you flip an image and then try to crop it the cropping occurs at the opposite side to the dragged crop handle. Steps to Reproduce: 1. Insert an image https://www.webb-dev.co.uk/ 2. Flip the image vertically 3. Select the crop tool and try to crop from the top crop handle Actual Results: https://waytowhatsnext.com/ The image is cropped from the bottom Expected Results: http://www.acpirateradio.co.uk/ The image should be cropped from the top Reproducible: Always http://www.logoarts.co.uk/ User Profile Reset: No Additional Info: http://www.slipstone.co.uk/ User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.75 Safari/537.36 [tag] [reply] [−]DescriptionPaul McAuley 2016-12-30 04:42:50 UTC http://embermanchester.uk/ Description: If you flip an image and then try to crop it the cropping occurs at the opposite side to the dragged crop handle. Steps to Reproduce: 1. Insert an image http://connstr.net/ 2. Flip the image vertically 3. Select the crop tool and try to crop from the top crop handle Actual Results: The image is cropped from the bottom http://joerg.li/ Expected Results: The image should be cropped from the top Reproducible: Always http://www.jopspeech.com/ User Profile Reset: No Additional Info: User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.75 Safari/537.36 http://www.wearelondonmade.com/ [tag] [reply] [−]DescriptionPaul McAuley 2016-12-30 04:42:50 UTC Description: If you flip an image and then try to crop it the cropping occurs at the opposite side to the dragged crop handle. Steps to Reproduce: http://www.compilatori.com/ 1. Insert an image 2. Flip the image vertically 3. Select the crop tool and try to crop from the top crop handle Actual Results: The image is cropped from the bottom Expected Results: The image should be cropped from the top Reproducible: Always User Profile Reset: No http://www-look-4.com/ Additional Info: User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.75 Safari/537.36
Michael Stahl committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/99055ae98ef1fe67b8db4a8c3167a8acaeaac02f tdf#123968 sw: fix assert on importing ooo62823-1.sxw It will be available in 24.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-24-2": https://git.libreoffice.org/core/commit/a2a85724b3260713b1938a934fd73211d6e1d99d tdf#123968 sw: fix assert on importing ooo62823-1.sxw It will be available in 24.2.1. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.