Description: See attached image. Steps to Reproduce: 1. Create a new presentation on Impress. 2. View > Toolbars. 3. Try unchecking the Text Formatting toolbar. Actual Results: You can't, as it is not shown on the screen because it does not fit. Expected Results: You should, or there should be an alternative way. Reproducible: Always User Profile Reset: Yes Additional Info: See attached image. Version: 6.1.5.2 Build ID: 1:6.1.5-1 CPU threads: 4; OS: Linux 5.1; UI render: default; VCL: gtk3; Locale: en-US (en_US.utf8); Calc: group threaded
Created attachment 152079 [details] Screenshot that shows the bug
Thank you for reporting the bug. Could you please try to reproduce it with a master build from http://dev-builds.libreoffice.org/daily/master/ ? You can install it alongside the standard version. I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the master build
Alternatively done from the Toolbar itself. Open the toolbar's Contextmenu Close toolbar And, what screen resolution is that clip at--seems like less than our "minimum" supported of 768px?
Beleive this is open as bug 113713 NOB against gtk3 composition. Workaround of context menu, or of dropping back to the gtk renderer. *** This bug has been marked as a duplicate of bug 113713 ***
(In reply to V Stuart Foote from comment #3) > Alternatively done from the Toolbar itself. > > Open the toolbar's Contextmenu > > Close toolbar This bug is not about closing a toolbar. This is about being unable to uncheck a toolbar from the menu. I read on an article that unchecking a toolbar from the menu might make it not appear again despite being a context-sensitive toolbar. I wanted to test that but it's impossible. > And, what screen resolution is that clip at--seems like less than our > "minimum" supported of 768px? 1366x768.
(In reply to Xisco Faulí from comment #2) > Thank you for reporting the bug. > Could you please try to reproduce it with a master build from > http://dev-builds.libreoffice.org/daily/master/ ? > You can install it alongside the standard version. > I have set the bug's status to 'NEEDINFO'. Please change it back to > 'UNCONFIRMED' if the bug is still present in the master build I will try it.
(In reply to V Stuart Foote from comment #4) > Beleive this is open as bug 113713 NOB against gtk3 composition. > > Workaround of context menu, or of dropping back to the gtk renderer. > > *** This bug has been marked as a duplicate of bug 113713 *** I am not sure it's a duplicate. On one hand, I just tried "SAL_USE_VCLPLUGIN=gtk libreoffice" and it did render the menus differently. Part of those differences is that all toolbars fit within the screen. Also, the menus are scrollable. On the other hand, the topic for the other bug is menu overlapping, effectively being mislocated on the screen, which is definitely not my situation. Also the GTK+ 3 Reference Manual page for GtkMenus mentions menu scrollability [*] so, if the options are there and I don't see any arrows at all it may as well be actually LibO's bug. [*] https://developer.gnome.org/gtk3/stable/GtkMenu.html#GtkArrowPlacement At the most, I would say that the two bugs are related but daring to call them duplicates is a premature and dismissive resolution. We don't even know if the root cause is the same. IOW, we don't know if fixing 113713 should fix this one too. The most truthful thing to do is to set it back to NEEDINFO and "See also: 113713". I would do it but I don't have the NEEDINFO option. Can someone else do that, please?
(In reply to Xisco Faulí from comment #2) > Thank you for reporting the bug. > Could you please try to reproduce it with a master build from > http://dev-builds.libreoffice.org/daily/master/ ? > You can install it alongside the standard version. > I have set the bug's status to 'NEEDINFO'. Please change it back to > 'UNCONFIRMED' if the bug is still present in the master build It still occurs on the May 31st snapshot: master_2019-05-31_15.33.33_LibreOfficeDev_6.3.0.0.alpha1_Linux_x86-64_deb.tar.gz
(In reply to Octavio Alvarez from comment #7) > > On one hand, I just tried "SAL_USE_VCLPLUGIN=gtk libreoffice" and it did > render the menus differently. Part of those differences is that all toolbars > fit within the screen. Also, the menus are scrollable. > > On the other hand, the topic for the other bug is menu overlapping, > effectively being mislocated on the screen, which is definitely not my > situation. Also the GTK+ 3 Reference Manual page for GtkMenus mentions menu > scrollability [*] so, if the options are there and I don't see any arrows at > all it may as well be actually LibO's bug. Hmm, we're kind of dismissive around here--nothing gets triaged otherwise ;-| And, in this case if you look at the duplicates also filed against bug 113713 you'll see most are about more than the menu overlapping -- which is exactly the situation in your clip, the gtk3 rendered menu extends from top to bottom of the frame but does not activate scroll bar which it is supposed to do. The correct dev got a bump when set duplicate.
(In reply to V Stuart Foote from comment #9) > Hmm, we're kind of dismissive around here--nothing gets triaged otherwise ;-| Fine, I am reading that for LibO QA, a "similar" bug classifies as a "duplicate" as per https://wiki.documentfoundation.org/QA/BugTriage#Step_3:_Search_for_Duplicates I do appreciate pinging the dev, though.
Would be interesting to hear, if Xfce 4.14 (fully ported to gtk3) makes a difference.