Description: Test system Ubuntu 18.04 and Version: 6.2.0.0.alpha0+ Build ID: f61af646c5c3fe7e50aea01ede6a9d7ea53380f2 Steps to Reproduce: 1. Make sure experimental features are enabled. 2. Open a Writer file (or create one) from the menu View->User Interface select any of the experimental options 3. Close the Writer file 4. Open an ODB file with an embedded form. 5. Open the embedded form Actual Results: The experimental UI is displayed instead of the Standard Toolbar UI. Using the experimental notebook bar UI to switch back to Standard Toolbar does not work. Using the Toolbar settings from the notebook bar UI does nothing. Expected Results: The embedded form continues to use the Standard Toolbar UI or The experimental UI controls are updated to work with an embedded form. Reproducible: Always User Profile Reset: No Additional Info:
For the moment, I'm just focusing about 1 point of this bugtracker to start. Do you mean each time LO is closed, User interface should be reset to Standard Toolbar? I mean, I gave a try just by using Writer: 1. Make sure experimental features are enabled. 2. Open a Writer file (or create one) from the menu View->User Interface select any of the experimental options 3. Close the Writer file 4. Open Writer => I still got the previous User Interface selected. Isn't it what's expected? Heiko/Xisco: put you in cc since it might interest you.
(In reply to Julien Nabet from comment #1) > For the moment, I'm just focusing about 1 point of this bugtracker to start. > > Do you mean each time LO is closed, User interface should be reset to > Standard Toolbar? > What I am saying is that prior to very recently (recent builds) embedded forms disregarded the experimental UI changes. So if the change was not planned it is a bug, right, if it was then it still needs some work to make it work.
If I try repeating this with Version: 6.2.0.0.alpha0+ Build ID: d99af1a67cbe4e23661467843e7d72194b45b313 CPU threads: 4; OS: Mac OS X 10.13.6; UI render: default; Locale: fr-FR (fr_FR.UTF-8); Calc: threaded I get an instant repeatable crash when attempting to load an embedded form.
Alex: the crash you encounter must correspond to tdf#119330 fixed 2 days ago.
(In reply to Julien Nabet from comment #4) > Alex: the crash you encounter must correspond to tdf#119330 fixed 2 days ago. Oh thanks Julien, I'll rebuild a fresh master and try again to reproduce Drew's problem.
The issue here, as I understand it, is that it is possible to set one of the notebookbar options and that this choice is correspondingly shown in an embedded form when it is loaded - so far, so good, as that is how it is supposed to function, at least from what I understand. However, at least some of the menu entries for resetting back to standard toolbar from within the loaded form do not appear to be active. This behaviour, if confirmed, would indeed be an issue.
The type of user interface is set per module, meaning you can have a standard UI in Writer and Tabbed in Calc. So the first issue is that Base is not working as expected (not tested so keeping the status). Second issue is the missing option to switch back. And in fact the work has been started, IIRC, but is not finished.
(In reply to Heiko Tietze from comment #7) > The type of user interface is set per module, meaning you can have a > standard UI in Writer and Tabbed in Calc. So the first issue is that Base is > not working as expected (not tested so keeping the status). > Second issue is the missing option to switch back. And in fact the work has > been started, IIRC, but is not finished. As a general statement, IMO, the amount of influence changes made to the Writer UI have to Base forms is already a problem and this makes it worse again. (form size, placement, zoom factor, toolbars opened or closed - should not affect base forms but they do) Reports on the other hand have used the notebook UI and there it makes perfect sense and there it makes sense to reflect any change made in Writer, because a user might very well change something on the report and at that moment it is in fact a stand alone Writer file. Base forms are not stand alone and the user (the real end user) is not going to be editing form contents, they are editing data contents via the form. The notebook UI has, from I can see, no support for those functions. Editing Base forms on the other hand (by the database developer) is just the opposite, you are editing the contents of the file and the notebook UI would work just fine there.
It would be great if you can attach an example. The NB designer are not necessarily experts in Base.
(In reply to Heiko Tietze from comment #9) > It would be great if you can attach an example. The NB designer are not > necessarily experts in Base. An example can be found here: https://bugs.documentfoundation.org/attachment.cgi?id=144254 from tdf#119330 (put in See Also)
1. Experimental features = enabled. 2. Open a Writer (master, local build); View->User Interface = Contextual sections 3. Open example ODB Shows Base with the standard UI.
(In reply to Heiko Tietze from comment #11) > 1. Experimental features = enabled. > 2. Open a Writer (master, local build); View->User Interface = Contextual > sections > 3. Open example ODB > > Shows Base with the standard UI. Are you opening a Form in that ODB?
(In reply to Drew Jensen from comment #12) > Are you opening a Form in that ODB? In the open Writer instance I just open the file.
(In reply to Heiko Tietze from comment #13) > (In reply to Drew Jensen from comment #12) > > Are you opening a Form in that ODB? > > In the open Writer instance I just open the file. I really am sorry but I have no idea what that means.
Created attachment 144344 [details] Screen cast using 6.2/master After the first start (make clean) I enable advanced features, change the UI in Writer, and finally get the standard UI in Base when opening the example file.
(In reply to Heiko Tietze from comment #15) > Created attachment 144344 [details] > Screen cast using 6.2/master > > After the first start (make clean) I enable advanced features, change the UI > in Writer, and finally get the standard UI in Base when opening the example > file. The issue is about Forms in an ODB file, not the main ODB window. Open one of the forms - if LibreOffice crashes at that moment you don't have the latest 6.2 files. Which could be the problem here, the very latest builds do not crash any more when you open a form and without that latest build you won't wee the change in the embedded forms UI.
Don't have SDBC drivers installed. Up to the QA experts from here on ;-).
(In reply to Heiko Tietze from comment #17) > Don't have SDBC drivers installed. Up to the QA experts from here on ;-). Really? Now I am confused, because it sure looks like a UX/UI question at this point.
(In reply to Heiko Tietze from comment #17) > Don't have SDBC drivers installed. Up to the QA experts from here on ;-). On which env are you? The odb file quoted in https://bugs.documentfoundation.org/show_bug.cgi?id=119364#c10 is hsqldb so Java should be sufficient?
Created attachment 144345 [details] example firebird odb with one form An example using firbird backend and a single form. (The issue is actually agnostic with regards to the data engine)
(In reply to Julien Nabet from comment #19) > ... Java should be sufficient? I build w/o Java and Firebird (--enable-debug --without-java --without-myspell- icts --without-doxygen --disable-firebird-sdbc --without-system-firebird).
(In reply to Heiko Tietze from comment #21) > (In reply to Julien Nabet from comment #19) > > ... Java should be sufficient? > > I build w/o Java and Firebird (--enable-debug --without-java > --without-myspell- icts --without-doxygen --disable-firebird-sdbc > --without-system-firebird). without-java -> you can't use hsqldb disable-firebird-sdbc, --without-system-firebird -> you can't use firebird. Any reasons about why disabling these (perhaps build failures?)? Indeed, it prevents you from testing lots of bugs related to Base.
(In reply to Julien Nabet from comment #22) > Any reasons about why disabling these (perhaps build failures?)? Indeed, it > prevents you from testing lots of bugs related to Base. IIRC it was build issues but also I don't want to install Java jdk/sdk on my system.
(In reply to Heiko Tietze from comment #23) > (In reply to Julien Nabet from comment #22) > > Any reasons about why disabling these (perhaps build failures?)? Indeed, it > > prevents you from testing lots of bugs related to Base. > > IIRC it was build issues but also I don't want to install Java jdk/sdk on my > system. At least, if you want to stay away from Java, you may remove "disable firebird" related options since Drew provided a Firebird odb file. If you've got building pbs, don't hesitate to ping dev mailing list.
Tested with : Version: 6.2.0.0.alpha0+ Build ID: b4ef23955e11a90b54bce189c3300406e9cf15b0 CPU threads: 4; OS: Mac OS X 10.13.6; UI render: default; Locale: fr-FR (fr_FR.UTF-8); Calc: threaded Confirming.
Created attachment 144352 [details] Screenshot of opened form showing mis-inherited toolbar setting
Drew: I submitted a patch on gerrit about this https://gerrit.libreoffice.org/#/c/59417/ Quoting my patch's comment: " tdf#119364: fix by reverting some previous commits about notebookbar Revert: - dcbb65f2a4a3ee70ccd4896d7a5e975dbd9e6509 which was to avoid Avoid com.sun.star.container.NoSuchElementException "Active" when opening embedded form - 6c89f41b02fcd8918e535460994daac4ecd5d37e which was to fix previous commit and fix tdf#119330 Just fix "Avoid com.sun.star.container.NoSuchElementException "Active"" by testing if OUString returned by lcl_getAppName is empty or not. If empty, just return false " I hope it'll restore back the initial behavior and fix the console log. I tested with the attachment of tdf#119330 and had no crash. Could you give it a try (obviously if you build sources)?
Julien Nabet committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=2bc3bda3a9d0abc7435e5dc9004c74304330a121 tdf#119364: fix by reverting some previous commits about notebookbar It will be available in 6.2.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
I submitted a patch so it'll be easier to test it in a next daily build instead of retrieving sources, cherry-picking the patch and building. Of course, if there's something with the patch, I'll revert it.
Any update here with a recent daily build which includes quoted patch?
(In reply to Julien Nabet from comment #30) > Any update here with a recent daily build which includes quoted patch? Verified with Ubuntu 18.04 and Version: 6.2.0.0.alpha0+ Build ID: 76be5c31b97a37d15a3009995f4e60e4cee011ee Dated: 2018-08-31_02:44:17