Description: Steps to Reproduce: 1. Select data in several columns to be copied elsewhere. Ctrl C 2. Copy it somewhere as unformatted text. The text import window is shown. 3. Select multiple columns in the column preview pane to define their data type at once. This used to be done while holding the Ctrl key. Actual Results: You can’t select a range a columns at once any more in Calc 24.2.0.3. Expected Results: Let it select a range of columns in some way, as it used to be in Calc ≤ 7.6.4. Reproducible: Always User Profile Reset: No Additional Info:
Testing with a recent 24.8 alpha, I can see 1 difference regarding prior versions. NOTE: This problem happens with the setting "Use Skia for all rendering" disabled. Until LO 7.6, when using [CTRL] to select multiple columns in the import/paste unformatted dialogue, each selected column would be seen with its background color inverted (e.g. painted as black with white fonts). This identifies the selected columns more clearly. When testing with a recent LO 24.8, there is no _clear_ indication that multiple columns were selected. I can barely see some kind of edge/border (or it might be my imagination), but IMO it is not as a clear indication as the inverted background color. Having said that, the actual selection of multiple columns does occur; this is only a visual problem. For instance, select multiple columns and change them to "text". The selected columns will change to "text", although there was no inverted background color indicating that the columns were selected. As mentioned, this visual problem happens with Skia OFF, same as the guiding edge when we drag a selected range to move/copy. This has been reported already in some other ticket (which should rather have a higher priority, IMHO) IMO, this SKIA issue should be resolved ASAP, before we get dozens of reports about the "same" problem starting in LO 24.2.
(In reply to ady from comment #1) > NOTE: This problem happens with the setting "Use Skia for all rendering" > disabled. Oops!, this happens with that Skia option ENABLED. When disabling it, the old, normal, correct and expected visual behavior can be seen.
Testing with a recent 24.8 alpha, I can see 1 difference regarding prior versions. NOTE: This problem happens with the setting "Use Skia for all rendering" ENABLED. Until LO 7.6, when using [CTRL] to select multiple columns in the import/paste unformatted dialogue, each selected column would be seen with its background color inverted (e.g. painted as black with white fonts). This identifies the selected columns more clearly. When testing with a recent LO 24.8, there is no _clear_ indication that multiple columns were selected. I can barely see some kind of edge/border (or it might be my imagination), but IMO it is not as a clear indication as the inverted background color. Having said that, the actual selection of multiple columns does occur; this is only a visual problem. For instance, select multiple columns and change them to "text". The selected columns will change to "text", although there was no inverted background color indicating that the columns were selected. As mentioned, this visual problem happens with Skia ON, same as the guiding edge when we drag a selected range to move/copy. This has been reported already in some other ticket (which should rather have a higher priority, IMHO) IMO, this SKIA issue should be resolved ASAP, before we get dozens of reports about the "same" problem starting in LO 24.2.
Created attachment 192636 [details] Screen snapshot of columns selected in the Text Input dialog
I cannot reproduce this on macOS with the latest nightly master build with either Skia/Metal or Skia/Raster enabled. In both cases, I can select the columns in the Text Import dialog by Command-clicking on each: https://bugs.documentfoundation.org/attachment.cgi?id=192636 So maybe this is bug occurs only on Windows or Linux? Here is my data: Version: 24.8.0.0.alpha0+ (AARCH64) / LibreOffice Community Build ID: 8ac287e2b75bf04637771f5d20b9e44af95a48c4 CPU threads: 8; OS: macOS 14.2.1; UI render: Skia/Raster; VCL: osx Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
(In reply to ady from comment #3) > As mentioned, this visual problem happens with Skia ON, same as the guiding > edge when we drag a selected range to move/copy. This has been reported > already in some other ticket (which should rather have a higher priority, > IMHO) The report I mentioned in that paragraph is tdf#159214, also with Skia ON. Additionally, in tdf#159214 comment 3 I mentioned tdf#158167 comment 13 posted on 2023-11-27, in which I saw the same behavior while testing it (although tdf#158167 is about a different issue). So we have this problematic behavior for around 3 months (or more) ATM.
No repro in: Version: 24.2.1.2 (X86_64) / LibreOffice Community Build ID: db4def46b0453cc22e2d0305797cf981b68ef5ac CPU threads: 8; OS: Linux 6.5; UI render: Skia/Vulkan; VCL: x11 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded Nor with Skia/Raster. Let's mark as Windows-only.
So from see also bug 160036 is this Win11 with Skia Raster, and now fixed target:24.8.0, or target:24.2.2.2? [1][2] Is this resolved? @ady, should we assume your use of Skia is Raster rendering and not Vulkan based? And why we like to see the Help -> About LibreOffice content pasted. =-ref-= [1] https://gerrit.libreoffice.org/c/core/+/164933 [2] https://gerrit.libreoffice.org/c/core/+/164877
(In reply to V Stuart Foote from comment #8) > @ady, should we assume your use of Skia is Raster rendering and not Vulkan > based? And why we like to see the Help -> About LibreOffice content pasted. (In reply to ady from comment #3) > NOTE: This problem happens with the setting "Use Skia for all rendering" > ENABLED. This issue was (tested but) not seen when the setting "Use Skia for all rendering" was DISABLED. As of LO Dev 24.8 alpha built on 2024-03-25, testing with the same "Use Skia for all rendering" ENABLED, the particular issue reported in comment 0 is no longer reproduced – I am still testing other issues that seem to be related to the same original problem; I'll post in their own respective reports (or create new if needed). For this particular report, as of today's build, no longer repro: Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 1344e6261a1d856c71eca1e0cc29215a586bf335 CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: en-US (es_AR); UI: en-US Calc: CL threaded
(In reply to ady from comment #9) OK, this tracks with Patrick's adjustment [1] to our Skia libs implementation to restore use of the Skia Shading Layer (SKSL) with our "software only" raster frame rendering. The Vulkan mode GPU shading follows different rendering paths and we can have differences between the two modes CPU and GPU accelerated. Should also be set with the 24.2.2 builds. =-ref-= https://gerrit.libreoffice.org/c/core/+/164933
*** This bug has been marked as a duplicate of bug 160036 ***