The position of the Find All search result window isn't remembered when closed and reopened. This is different to other windows like Options dialog. The reason for this enhancement request (or bug?) is that it's bad usability if the window always opens above the content cells and the user has to move it manually away -- every time the window opens as it's the case for one of my files. Expected result: Window remembers last closing position and opens there. Or the window doesn't open above a result cell and the window is moving automatically when clicking on a result item that is beneath the dialog window.
Repro. Arch Linux 64-bit Version: 6.2.0.0.alpha0+ Build ID: 0d2c5e0838906101e1fdea93b4a0c422690e331c CPU threads: 8; OS: Linux 4.16; UI render: default; VCL: kde4; Locale: fi-FI (fi_FI.UTF-8); Calc: group threaded Built on June 15th 2018
KDE only, I guess (made the sort dialog resizable for bug 153852 and faced the erratic position issue- size is retained but position not; gtk3 works perfectly). A lot of similar tickets: bug 128174, bug 46106, bug 151676, bug 141792, bug 137471... Stephane, please have a look and consolidate perhaps. Michael, Caolan: IIRC we had a discussion some time ago.
(In reply to Heiko Tietze from comment #2) > KDE only, I guess (made the sort dialog resizable for bug 153852 and faced > the erratic position issue- size is retained but position not; gtk3 works > perfectly). > > A lot of similar tickets: bug 128174, bug 46106, bug 151676, bug 141792, bug > 137471... Stephane, please have a look and consolidate perhaps. The kf5-specific part indeed sounds like a duplicate of tdf#137471, behavior seems to be the same in a quick test. > Michael, Caolan: IIRC we had a discussion some time ago. What I remember/found is the discussion in tdf#137471 and https://gerrit.libreoffice.org/c/core/+/105298 . FWIW, https://gerrit.libreoffice.org/c/core/+/135082 has some more infos and IIRC a previous patch set of that Gerrit change fixed the positioning on kf5, but had other issues, and the version that was finally merged didn't fix the positioning any more and had other issues, was therefore reverted in commit f51b220b953ec71fb742f799fbe645a93cf3d944 Date: Fri Mar 24 08:06:56 2023 +0100 tdf#149805 tdf#151677 tdf#152217 tdf#154043 tdf#153458 tdf#153800 Revert "VCL expect
Thomas, you never reported which OS/DE was used. Do you remember? Can you still reproduced?
*** Bug 156122 has been marked as a duplicate of this bug. ***
It's still there as described in 2018. Tested with Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 77fca616e0bd79e0b405fd0b3543cf8e94e15df3 CPU threads: 2; OS: Linux 5.8; UI render: default; VCL: gtk3 on Ubuntu/Gnome Maybe it's a Linux problem but I can't say it doesn't exist on other OS.
(In reply to Thomas Lendo from comment #6) > Maybe it's a Linux problem It happens on MS Windows too. The results window is always displayed at the center of the screen after it was moved in the prior run (i.e. its position is reset, not remembered).
(In reply to ady from comment #7) > (In reply to Thomas Lendo from comment #6) > > > Maybe it's a Linux problem > > It happens on MS Windows too. The results window is always displayed at the > center of the screen after it was moved in the prior run (i.e. its position > is reset, not remembered). Are you verifying that it's the only response pane in the entire LO suite that behaves in this manner and it is intentional?
(In reply to Colin from comment #8) > Are you verifying that it's the only response pane in the entire LO suite > that behaves in this manner and it is intentional? In comment 7 I partially quoted comment 6, adding info: the behavior described in this report is not limited to Linux, as it can also be replicated on MS Windows. I have said nothing about being intentional (IDK), nor limited to this window only, as I have not tested anything else except the reported behavior in this particular report.
(In reply to ady from comment #9) > (In reply to Colin from comment #8) > > Are you verifying that it's the only response pane in the entire LO suite > > that behaves in this manner and it is intentional? > > In comment 7 I partially quoted comment 6, adding info: the behavior > described in this report is not limited to Linux, as it can also be > replicated on MS Windows. > > I have said nothing about being intentional (IDK), nor limited to this > window only, as I have not tested anything else except the reported behavior > in this particular report. Your comments are presenting as if you believe it to be intentional in this pane and that you support that scenario.