Created attachment 128343 [details] Base Document showing the bug Hallo, I cannot change some properties in the properties dialog window for some controls in forms of a Base document. The attached file contains an embedded HSQLDB-database with just one table (two columns, int as primary key and string). The document contains one form that references the above table. The form contains a table control. In the properties dialog I want to disable "Navigation bar" and "Record marker". I can change the settings from "Yes" to "No" but this has no effect on the referenced table control, which continues to show the navigation bar and record marker. Closing and reopening the properties dialog shows "Yes" again. I hope that you can reproduce this bug, I install the deb packages on Debian Jessie version 8.6. Thanks for looking into this. Regards Jens
Created attachment 128346 [details] Same as first attachment - without navigationbar I couldn't confirm the buggy behavior. Opened the form for editing. Marked the table-control. Set navigationbar and recordmarker to "No". Table-control is shown without navigationbar and recordmarker. Saved the for, could reopen - without recordmarker and navigationbar. My system: OpenSUSE 42.1 64bit rpm Linux, LO 5.2.2.2
Thanks, Robert, I can open your file and indeed the navigation bar and the record marker have disappeared. But using my version and installation I cant get them back. Is there someone listening who can check on a Debian installation?
No repro with Version: 5.2.1.2 Build ID: 31dd62db80d4e60af04904455ec9c9219178d620 Threads CPU : 2; Version de l'OS :Mac OS X 10.12; UI Render : par défaut; Locale : fr-FR (fr_FR.UTF-8); Calc: group I can deactivate both the record marker and the navigation bar, save the form, and the changes are saved on next loading of the form. Sorry, but as this appears to be a distro specific packaging problem, setting to NOTOURBUG.
(In reply to Alex Thurgood from comment #3) > No repro with > > Version: 5.2.1.2 > Build ID: 31dd62db80d4e60af04904455ec9c9219178d620 > Threads CPU : 2; Version de l'OS :Mac OS X 10.12; UI Render : par défaut; > Locale : fr-FR (fr_FR.UTF-8); Calc: group > > I can deactivate both the record marker and the navigation bar, save the > form, and the changes are saved on next loading of the form. > > Sorry, but as this appears to be a distro specific packaging problem, > setting to NOTOURBUG. If you allow I want to add another finding to this topic. At first I had installed all of the deb-files in the download from libreoffice.org. If I uninstall the package libobasis5.2-gnome-integration_5.2.2.2-2_amd64 the problem with editing the navigation bar and record marker goes away. This is a practical workaround for me.
(In reply to je.krause from comment #4) > > If you allow I want to add another finding to this topic. At first I had > installed all of the deb-files in the download from libreoffice.org. > If I uninstall the package libobasis5.2-gnome-integration_5.2.2.2-2_amd64 > the problem with editing the navigation bar and record marker goes away. So this isn't a distro specific bug. It seems to be a bug of the LO-packages on Debian Jessie. I will set this back to Unconfirmed.
(In reply to robert from comment #5) > (In reply to je.krause from comment #4) > So this isn't a distro specific bug. It seems to be a bug of the LO-packages > on Debian Jessie. I will set this back to Unconfirmed. Agreed, it wasn't immediately obvious from the initial report that the TDF packages were used.
Adjusted title to more recent findings
Ok for the name change, now that it is clear that gnome integration is the culprit. The problem is for me reproducible on different computers and different versions: * on debian jessie with TDF packages (v5.2.2.2) * on debiam jessie with packages from debian (v4.3.3.2) * on debian sid with packages from debian (v5.2.3) * on ubuntu xenial with packages from ubuntu (v5.1.) In all these comnination installing the gnome integration causes the bug to appear.
I can't repro the problem, but I can't find the package libobasis5.2-gnome-integration in Synaptic.. Can't find it here, either: http://packages.ubuntu.com/ Can you find it in the ubuntu.com site and link to it? Version: 5.2.3.2 Build ID: 1:5.2.3~rc2-0ubuntu1~xenial1 CPU Threads: 4; OS Version: Linux 4.4; UI Render: default; Locale: fi-FI (en_US.UTF-8); Calc: group
(In reply to Buovjaga from comment #9) > I can't repro the problem, but I can't find the package > libobasis5.2-gnome-integration in Synaptic.. Can't find it here, either: > http://packages.ubuntu.com/ > Can you find it in the ubuntu.com site and link to it? This is not a package provided by ubuntu, but by TDF / the libreOffice project. Download from http://www.libreoffice.org/download/
(In reply to Lionel Elie Mamane from comment #10) > (In reply to Buovjaga from comment #9) > > I can't repro the problem, but I can't find the package > > libobasis5.2-gnome-integration in Synaptic.. Can't find it here, either: > > http://packages.ubuntu.com/ > > Can you find it in the ubuntu.com site and link to it? > > This is not a package provided by ubuntu, but by TDF / the libreOffice > project. Download from http://www.libreoffice.org/download/ Sorry about that. Yep, on Ubuntu the matching package is libreoffice-gnome. I'll create a new VM later to test with the TDF packages from scratch.
Could not reproduce with attachment 128343 [details] I installed all the debs (including the gnome-integration) in LibreOffice_5.2.3.3_Linux_x86-64_deb using the instructions here: https://wiki.documentfoundation.org/Installing_in_parallel/Linux Ubuntu 16.10 64-bit Should I do it somehow differently?
Now I can refine my report with another detail: The Yes/No decision for showing or not the navigation bar is implemented as a listbox. The a two ways of changing the state. (1) using the mouse wheel (2) left-clicking on the little arrow on the right, this open the list and one can select to new choice. Only (2) actually changes the state and (1) has no effect. It seems that I have the tendency to use the mouse wheel in these cases. Knowing this difference I can now work as I wish and this bug (or limitation) is only minor. Having said that I have further found out that this behaviour is not related to gnome-integration after all. Even with that standard libreoffice look it is present (Only that I had - in this case - used method (2)) Thanks again looking into this and I apologize for keeping you busy with these minor issues. Jens
Ok, I confirm. Using the scrollwheel, the new setting is applied, if you click on any other dropdown. I could not find another report (searched generally). Arch Linux 64-bit, KDE Plasma 5 Version: 5.2.3.3 Build ID: 5.2.3-1 CPU Threads: 8; OS Version: Linux 4.8; UI Render: default; Locale: fi-FI (fi_FI.UTF-8); Calc: group Arch Linux 64-bit Version 3.6.7.2 (Build ID: e183d5b)
Many changes for a control take effect only when you click into another field. For example, if you change width, height, position etc. manually by setting another value, you also have to click elsewhere. I think the change is only recognized after an event for the field has been fired, and this happens only when leaving the field, but not when you simply change the value; this would be uncomfortable because it would be fired continuously as long as you scroll the wheel or change the value using a spin button. The firing would probably be quicker than the reaction, leading perhaps to problems. For a listbox the situation is different, because the selection of an entry can fire an event; this is mainly a single choice and not a continuous change, as described before. Thus, I do not consider this as a bug. I hope you will understand my reasoning. If you do, I propose you set the status of this bug to RESOLVED. Gerhard
(In reply to Gerhard Weydt from comment #15) > Many changes for a control take effect only when you click into another > field. For example, if you change width, height, position etc. manually by > setting another value, you also have to click elsewhere. > I think the change is only recognized after an event for the field has been > fired, and this happens only when leaving the field, but not when you simply > change the value; this would be uncomfortable because it would be fired > continuously as long as you scroll the wheel or change the value using a > spin button. The firing would probably be quicker than the reaction, leading > perhaps to problems. > For a listbox the situation is different, because the selection of an entry > can fire an event; this is mainly a single choice and not a continuous > change, as described before. > Thus, I do not consider this as a bug. I hope you will understand my > reasoning. If you do, I propose you set the status of this bug to RESOLVED. > Yes agree, key here is the need for a selection action in a drop list widget. Applying drop list attribute _without_ a specific selection action during cursor or mouse-wheel navigation would be a very unreliable UI--it is not appropriate either for UI elements or for DB fields. Contrast that to a spin widget that increments/decrements and applies and is appropriate UI. This is a pretty clear WONTFIX