Created attachment 145731 [details] Demo database Following on from #112590 (gtk3 and window size) I have tried to set the size and position of forms in code. Ignoring ubuntu ppa versions and gtk3 for now, and using: Version: 6.1.4.0.0+ Build ID: 7ea7b86e7731f8cc1366ea632653fecc97267378 CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: gtk2; TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:libreoffice-6-1, Time: 2018-10-13_04:47:20 Locale: en-GB (en_GB.UTF-8); Calc: group threaded Open Table1 form. On my system it shows on the top line, inset a little to the right. The setPosSize function is called when the table is opened, and contains: Sub FormSize() Wait 150 oFrame = StarDesktop.getCurrentFrame() oWin = oFrame.getContainerWindow() oWin.setPosSize(100,150,500,400,15) End Sub The y position 150 seems to be ignored completely. I've tried and failed to position and size forms to precisely what and where I want them, with many variations of sizes and positions. The Wait function seems to be needed otherwise the function runs against the main window, not the form (I guess a different way of getting the Frame and Window might work better), but this isn't the issue at hand. The only environment that works on my ubuntu system is without gtk2 or gtk3, where setPosSize works perfectly every time, so I'm running: Version: 6.1.3.1 Build ID: 1:6.1.3~rc1-0ubuntu0.18.04.1 CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: x11; Locale: en-GB (en_GB.UTF-8); Calc: group threaded I'd much prefer it if Base forms would preserve the size (and hopefully position) when edited and saved, but using setPosSize on the forms I use most has alleviated the problem somewhat, even if the x11 rendering is not too nice. The setPosSize solution does, of course, fail when I run the application on a different system, where other sizes are needed, and I really don't want to have to modify code every time I move apps around (whereas opening, reshaping and saving each form would be much, much easier). My memory still tells me that LO used to remember form sizes, once upon a time.
I tried under Windows 10 and the setPosSize seems to work OK, so may be just ubuntu, or gnome.
Just in case someone wonders why I don't try the ubuntu ppa gtk3, this version: Version: 6.1.3.1 Build ID: 1:6.1.3~rc1-0ubuntu0.18.04.1 CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: en-GB (en_GB.UTF-8); Calc: group threaded also gets the positions wrong.
Testing with Ubuntu 18.04 LibreOffice 6.2Alpha1 also 6.0.7 and 5.4.7 Tried with OpenGL enabled and disabled and with GTK2 and GTK3 (where I could). The problem is persistent across all the different setups, and requires the following to manifest. First how to make it work every time. If you open the form for editing before you do anything else the macro does correctly resize and position the form window. Close the form without saving it. Now if you open the form in data entry mode you notice that it initally opens full screen and then it is properly resized and positioned. How to make it fail. Open the form for editing or data entry mode again, then maximize the form, now close it and again answer no if/when asked to save it. Now when the form is opened for data entry it starts out at full screen and stays at full screen. NOTE: 5.4 has the worst problems as it does not position the form properly but 6.0 and 6.2Alpha do. I didn't check 6.1 but I doubt it would be different.
On my system I never get it to set the y position properly with gtk2 or gtk3. With X11 it's fine, but I did find I needed to add oWin.IsMaximized = false to the macro, otherwise it's sometimes full screen.
(In reply to Drew Jensen from comment #3) > Testing with Ubuntu 18.04 LibreOffice 6.2Alpha1 also 6.0.7 and 5.4.7 > Tried with OpenGL enabled and disabled and with GTK2 and GTK3 (where I > could). > > The problem is persistent across all the different setups, and requires the > following to manifest. > > First how to make it work every time. If you open the form for editing > before you do anything else the macro does correctly resize and position the > form window. Close the form without saving it. Now if you open the form in > data entry mode you notice that it initally opens full screen and then it is > properly resized and positioned. > > How to make it fail. Open the form for editing or data entry mode again, > then maximize the form, now close it and again answer no if/when asked to > save it. Now when the form is opened for data entry it starts out at full > screen and stays at full screen. > > NOTE: 5.4 has the worst problems as it does not position the form properly > but 6.0 and 6.2Alpha do. I didn't check 6.1 but I doubt it would be > different. I've tried again. On my system it never sets x and y correctly, even using your first 'works every time' suggestion.
I'm now on Version: 6.2.6.1 Build ID: 1:6.2.6~rc1-0ubuntu0.19.04.1~lo1 CPU threads: 8; OS: Linux 5.0; UI render: default; VCL: x11; Locale: en-GB (en_GB.UTF-8); UI-Language: en-GB Calc: threaded The gtk2/3 problem remains as it was. The setpos statements do not work properly. The dimensions are OK, but the positions are not. I know this may seem trivial, and I do have a work around that makes the forms ugly (by not using gtk2/3) but it's a niggling bug none the less.
Dear tim, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
I am still having to avoid the gnome and gtk3 versions because of this bug. So I am running: Version: 7.1.5.2 / LibreOffice Community Build ID: 10(Build:2) CPU threads: 8; OS: Linux 5.11; UI render: default; VCL: x11 Locale: en-GB (en_GB.UTF-8); UI: en-GB Ubuntu package version: 1:7.1.5~rc2-0ubuntu0.21.04.1~lo1 Calc: threaded If I add libreoffice-gnome and gtk3 back in the problem remains. The look of libreoffice is much better, but I still cannot position windows. I have rechecked that the problem remains with: Version: 7.1.5.2 / LibreOffice Community Build ID: 10(Build:2) CPU threads: 8; OS: Linux 5.11; UI render: default; VCL: gtk3 Locale: en-GB (en_GB.UTF-8); UI: en-GB Ubuntu package version: 1:7.1.5~rc2-0ubuntu0.21.04.1~lo1 Calc: threaded
Confirmed in Version: 7.4.2.3 / LibreOffice Community Build ID: 382eef1f22670f7f4118c8c2dd222ec7ad009daf CPU threads: 4; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR Calc: threaded
Confirmed in Version: 7.5.4.2 (X86_64) / LibreOffice Community Build ID: 36ccfdc35048b057fd9854c757a8b67ec53977b6 CPU threads: 4; OS: Linux 5.19; UI render: default; VCL: gtk3 Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR Calc: threaded
When will this bug be solved !!!!
Version: 7.6.2.1 (X86_64) / LibreOffice Community Build ID: 56f7684011345957bbf33a7ee678afaf4d2ba333 CPU threads: 4; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR Calc: threaded Confirmed for ME with ubuntu 23.10 under Wayland and under Xorg But my graphic card (Intel® HD Graphics 4000 (IVB GT2)) is perhaps too old No problem under windows 10 with recent computer.
Confirmed in Version: 24.2.0.3 (X86_64) / LibreOffice Community Build ID: da48488a73ddd66ea24cf16bbc4f7b9c08e9bea1 CPU threads: 4; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR Calc: threaded I looked a lot, because even my programs in Python for QT do not work. I found this: https://github.com/gotk3/gotk3/issues/397 I leave a comment here if someone run in the same issue. After talking with gnome team in irc, they said that wayland doesn't let an application move its windows. So Wayland is involved. Is it too difficult to find a solution at Libre Office? Thank a lot