Created attachment 149924 [details] text input header frame menu button display interfer with each other When the header/footer frame menu is activated and the header/footer is empty the cursor is placed either at the start or end of the page text. If text is entered before the frame menu button is pressed to add the header/footer the text and menu button display interfere with each other. Attached is a screen recorded example. One solution would be to place focus on the header/footer frame menu button if the header/footer is empty.
I confirm that behaviour. Version: 6.1.5.2 (x64) Build-ID: 90f8dcf33c87b3705e78202e3df5142b201bd805 CPU-Threads: 4; BS: Windows 10.0; UI-Render: Standard; Gebietsschema: de-DE (de_DE); Calc: group threaded One solution could also be to place the frame menu button above the line, if the header is empty.
Created attachment 149951 [details] change positon of header/footer frame menu button when empty (In reply to Dieter Praas from comment #1) > One solution could also be to place the frame menu button above the line, if > the header is empty. Hi Dieter, Attached is a screen recorded implementation of the solution you have suggested. Perhaps this could be opened in a separate bug report and made into an easy hack. I think we should check with the UX team before moving anymore on this.
(In reply to Jim Raykowski from comment #2) > I think we should check with the UX team before moving > anymore on this. Adding UX team
That's a lot of movement, I would go with the focus as there is no reason to active the menu but continue to type. Another option is to redraw the buttons, eg. opaque. Users can hide the advanced header/footer menus.
(In reply to Heiko Tietze from comment #4) > Another option is to redraw the > buttons, eg. opaque. Users can hide the advanced header/footer menus. There is a "TODO Ghost it all" comment in the code which may be the opacity approach. I'm lost on the "Users can hide the advanced header/footer menus." My vote is for moving focus to the frame menu button. This suggests implementation of keyboard input handling for the add header/footer frame menu button, the button that shows with the + after the text. Currently an escape key press when the cursor is in the header/footer edit window moves focus to the main document. Pressing the escape key when the non empty header/footer frame menu button pop up menu is active closes the pop up menu and places focus on the frame menu button. Escape key from this state does nothing. Move focus to the header/footer edit window if header/footer is not empty or to the main document if header/footer is empty seems logical. I didn't find a way to move focus to the header/footer edit window or activate the frame menu button using the keyboard.
(In reply to Jim Raykowski from comment #5) > I'm lost on the "Users can hide the advanced header/footer menus." See bug 118621 > My vote is for moving focus to the frame menu button. Would be my first choice too.
(In reply to Jim Raykowski from comment #5) > I didn't find a way to move focus to the header/footer edit window or activate > the frame menu button using the keyboard. To Header (.uno:JumpToHeader) and To Footer (.uno:JumpToFooter) do this. They are assigned keyboard shortcut keys Ctrl+Page Up and Ctrl+Page Down by default.
Code pointers to grab focus to the empty header/footer frame menu button. Use SwHeaderFooterWin::IsEmptyHeaderFooter() to check if... header footer is empty, then grab focus to SwHeaderFooterWin using Window::GrabFocus() inherited by SwHeaderFooterWin. Add lines of code in the appropriate place in this function sw/source/uibase/docvw/FrameControlsManager.cxx void SwFrameControlsManager::SetHeaderFooterControl( const SwPageFrame* pPageFrame, ... After is this is done I can supply code pointers for adding key input handling of Escape key to return to main document and handling of Space and Enter key to add the header/footer.
Thanks for the code pointers, Jim. It's a proper easy hack now.
Since it is no longer a maybe, concerning what is to be done, I have changed the bug title.
Dear Aditya Sahu, This bug has been in ASSIGNED status for more than 3 months without any activity. Resetting it to NEW. Please assigned it back to yourself if you're still working on this.
Kindly review the following change: https://gerrit.libreoffice.org/#/c/83115/
Created attachment 156018 [details] screenshot of hf frame menu button opacity approach My idea to move focus to the frame button when the hf is empty doesn't work well. For multi page documents the frame button can still become in the way. The opacity approach, which can be seen in the attachment, seems not so good either. IMHO Dieter's suggestion to move the frame button when the hf is empty is the best way to avoid this nuisance.
Perhaps the frame button displayed when there is an empty hf should be eliminated and when hf is clicked on it should be added if empty without need for clicking on the add hf frame button?
until we arrive at a concurred solution, removing myself as the assignee and changing bug status back to NEW.
Another idea for this annoyance: Since the cursor remains in the document when the Add header/footer frame menu button is displayed. How about simply hiding it if a key is pressed?. This would be consistent with a mouse click in the document area.
Is this bug still active? I tried reproducing it but failed to do so.
(In reply to Moaz El-defrawy from comment #17) > Is this bug still active? I tried reproducing it but failed to do so. I failed as well. The glitch is no longer there and the text goes under the button. Let's close. Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 005adbefc746f9024adcf572c287dc061acbcf00 CPU threads: 2; OS: Windows 10.0 Build 19042; UI render: default; VCL: win Locale: fi-FI (fi_FI); UI: en-US Calc: threaded