Bug 139070 - LISTBOX: Values, which are in different rows, where not shown right separated in preview
Summary: LISTBOX: Values, which are in different rows, where not shown right separated...
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
7.0.4.2 release
Hardware: All All
: medium normal
Assignee: Caolán McNamara
URL:
Whiteboard: target:7.2.0 target:7.1.2 target:7.0.6
Keywords: bibisected, bisected, regression
Depends on:
Blocks:
 
Reported: 2020-12-19 16:07 UTC by Robert Großkopf
Modified: 2021-02-25 20:32 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Sign between entries should be ";" (48.04 KB, image/png)
2020-12-19 16:07 UTC, Robert Großkopf
Details
how it looks for me in libreoffice and gedit (106.77 KB, image/png)
2021-02-23 15:19 UTC, Caolán McNamara
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Robert Großkopf 2020-12-19 16:07:08 UTC
Created attachment 168333 [details]
Sign between entries should be ";"

Have a look at the attached screenshot.
In the back for the input list of the listbox-entries you see all the entries in one row, with a wrong sign as separator between the entries.

This screenshot is made in VCL: gtk3 . With VCL: kf5 there is no separator shown at all. The whole text is set in one row.

If you open the listbox it will be shown as "First entry";"Second entry"; ... but it is greyed out.

This behavior is new in LO 7.0.4.2. It doesn't appear in LO 6.4.6.2 on OpenSUSE 15.1 64bit rpm Linux.
Comment 1 Xisco Faulí 2020-12-21 14:22:34 UTC
Reproduced in

Version: 7.2.0.0.alpha0+
Build ID: ad8485ebe11396aaac68095ef9eec819de6af26c
CPU threads: 4; OS: Linux 5.7; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded
Comment 2 raal 2021-02-21 17:35:57 UTC
This seems to have begun at the below commit.
Adding Cc: to Caolán McNamara ; Could you possibly take a look at this one?
Thanks

e7cb5671ab586f618b3a45c5e9241f3d1988226c is the first bad commit
commit e7cb5671ab586f618b3a45c5e9241f3d1988226c
Author: Jenkins Build User <tdf@pollux.tdf>
Date:   Mon Dec 9 14:28:14 2019 +0100

    source sha:1efeb17837c22499f00299c033ae59ba3910f7d7

commit	1efeb17837c22499f00299c033ae59ba3910f7d7	[log]
author	Caolán McNamara <caolanm@redhat.com>	Mon Nov 04 13:06:04 2019 +0000
committer	Caolán McNamara <caolanm@redhat.com>	Mon Dec 09 13:28:35 2019 +0100
tree	a8db0b758e942b3b14fba26129dc51a95ff5c10c
parent	4da3e0a0e5b2260c26186890724978bfd00f796c [diff]

weld Property Browser
Comment 3 Caolán McNamara 2021-02-23 15:18:56 UTC
The idea is that the entry can be used to edit a single line, but if there are multiple lines you have to use the multi-line dropdown editor. That there are odd symbols between the lines in the gtk one suggests there might be symbols lacking in your font. i.e. if you select the below, copy it, launch gedit and ctrl+f to show its find box and ctrl+v into it do those symbols also appear between the lines ?

---->
one
two
three
<----
Comment 4 Caolán McNamara 2021-02-23 15:19:34 UTC
Created attachment 170003 [details]
how it looks for me in libreoffice and gedit
Comment 5 Caolán McNamara 2021-02-23 15:45:56 UTC
what I can do is to change the modification behavior so that during editing of the multiline view the entry contains the text formatted as how it will appear once editing is finished instead of leaving it to the default gtk and vcl behaviors of showing symbols vs stripping newlines.
Comment 6 Robert Großkopf 2021-02-23 16:22:22 UTC
There isn't any special font used for this.
The font you are using, Caolán, would be great to show the right behavior. But it doesn't seem to be a sing, which is part of Liberation Sans or something else, which is used there.
When I leave the input for more than one row it will switch back to the old appearance: "one";"two";"three". So it is irritating the sign between the entries changes.

I couldn't test it any more with gtk3, because i have decided only to work with kf5. Seems many of the design for gtk3 together with my KDE-desktop has been created for screens with higher resolution.
Comment 7 Commit Notification 2021-02-23 19:19:46 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/8365076e896238d1dc870910f5fd6234d0931f7b

tdf#139070 format entry view of multilines with final formatting

It will be available in 7.2.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.
Comment 8 Caolán McNamara 2021-02-23 19:23:39 UTC
I'll try the above, to not use the default behaviour for newlines in the single-line entry and to use the "final" view that will end up in there. Backport to 7-1 and 7-0 in gerrit
Comment 9 Xisco Faulí 2021-02-24 12:47:40 UTC
Verified in

Version: 7.2.0.0.alpha0+ / LibreOffice Community
Build ID: 7cb59a86d45d06836723c93b063060f27f9669c6
CPU threads: 4; OS: Linux 5.7; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded

@Caolán, thanks for fixing this issue!!
Comment 10 Commit Notification 2021-02-24 12:48:52 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-7-1":

https://git.libreoffice.org/core/commit/782f5369e2966e6e54dd71a3c4e1e62927029031

tdf#139070 format entry view of multilines with final formatting

It will be available in 7.1.2.

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.
Comment 11 Commit Notification 2021-02-25 20:32:17 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-7-0":

https://git.libreoffice.org/core/commit/5ff60569f998d9afe9273ec4223d91f6d549e51a

tdf#139070 format entry view of multilines with final formatting

It will be available in 7.0.6.

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.