Created attachment 186064 [details] Save dialog with all but one file invisible. For several releases, the file dialogs do not display the files; only the file under the cursor. Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: e1c6f36d8bcc0799281e3a7e244175f682d97cb2 CPU threads: 20; OS: Linux 6.2; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded Jumbo Trying to load or save a file, only the file under the cursor is visible -- until I click on it, then the blue bar stays visible; but the filename becomes invisible. LODev is the only application exhibiting this issue. It's like the font is white on white for all other entries except the file under the mouse cursor. I kept assuming this would have been noticed; but I may be the only one seeing this. I did nothing to affect this; I simply update LO every few days... This is not a problem in LO 7.5. Version: 7.5.1.2 (X86_64) Build ID: 50(Build:2) CPU threads: 20; OS: Linux 6.2; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded Jumbo
I reproduce, but only with gtk3 (not with kf5, gen or Windows). However, running Fedora 30 with distrobox in a container, I do not see the problem in the 7.6 bibisect repo (last build from yesterday). Could it be related to themes somehow? I am running KDE Plasma desktop and there is always some difference with the theming on my host vs. Fedora 30 container. Arch Linux 64-bit, X11 Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 90c590812eecb3a0eb2748a132e304fa6c0ea0ad CPU threads: 8; OS: Linux 6.2; UI render: default; VCL: gtk3 Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: threaded Built on 5 April 2023
This, presumably, is with tools, libreoffice, general, use libreoffice dialogs enabled, yes? If so, was that a deliberate choice?
(In reply to Caolán McNamara from comment #2) > This, presumably, is with tools, libreoffice, general, use libreoffice > dialogs enabled, yes? > > If so, was that a deliberate choice? Yes, sorry for not mentioning the explicit option.
(In reply to Caolán McNamara from comment #2) > This, presumably, is with tools, libreoffice, general, use libreoffice > dialogs enabled, yes? > > If so, was that a deliberate choice? Thank you. The option was checked, and not by me. Unchecked it and I can see everything now. This was changed a few nightly versions before I reported it. I now have both normal and dev versions displaying as expected... So the issue is with LO dialogs.
whatever about the non-system dialog having some sort of problem, I think we have another problem that this checkbox gets toggled on under some set of circumstances I'm not sure of (running without gtk and then with gtk?)
I was not able to reproduce on Ubuntu 20.04 with GNOME 3.36.8 + Wayland, even with a build at the same commit as OP. I tried various VCL and DE theme combinations. Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: e1c6f36d8bcc0799281e3a7e244175f682d97cb2 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded Removing the regression keywords for now as the difference between dev and stable might have come from the different user profiles. Caolán, was 9e786320a7d2609a9f997b32e31347f2eab0489e related to comment 5 in some way?
yeah, in a way. This "built-in" file picker shouldn't normally be seen unless the user explicitly selected it in options, which isn't something someone normally does. But I did find it happening to me too. I found that if I used --headless to convert a document that the option was turned on automatically at the start and off at the end and if we crash before getting to the end it remains stuck on. But I use that mode for examining the output of crashtesting so I see crashing documents in headless mode a lot more than the average person :-) That commit makes such a crash not affect the global setting anymore so a document that crashes in --headless --convert-to doesn't affect the normal profile. If it was the case that Pierre also was using --headless mode for document conversion, or some similar scripting solution, then that could explain this here too. But I think that's a bit of a stretch.
Here is one of a few Python scripts I found and used as the core code to include in my scripts to extract files via Calc a year ago; but never connected the issue to that. I don't recall when this issue first occurred before I reported it... As seen at the bottom, it's code I got from stackoverflow.com... IIRC, --headless was defaulted... HTH #!/bin/env python # -*- mode: python; -*- from os import system import audit.util class spreadsheet_extract: # Extract sheet(s) from a spreadsheet # This invokes LibreOffice def __call__(self, fname, csvdir = None ): if csvdir: outdir = f'--outdir {csvdir}' MSE = f'libreoffice --convert-to \ csv:"Text - txt - csv (StarCalc)":\ 44,34,UTF8,1,,0,false,true,false,false,false,-1 \ {outdir} {fname}' system( MSE ) audit.util.set_module(spreadsheet_extract, __name__) # From: https://stackoverflow.com/questions/1060796/callable-modules # This is how to get around: TypeError: 'module' object is not callable
Oh good, so it does look like the scenario was the same as mine then. Headless mode switching on this internal file dialog and some crash or other failure making the reset to "normal" not happen. So that trigger is fixed at least.
Thanks Caolán. Pierre and Buovjaga, regarding the UI issue, are you able to five us the OS / Desktop Environment / Theme combination that makes the non-selected items disappear in that dialog?