If I create a new Master document, and try to insert a new item (e.g. using the button in the Master Document sidebar) - I can't! Only if I have another item (e.g. by focusing the document area of the window, and have it selected in the sidebar, can I make insertions. I should be able to insert items right away.
I confirm the observed behaviour, but I don't think it's a bug. For example if you have more than one item in the document, it is not clear, where the new item should be inserted. What is your expectation here? So for me this is a WONTFIX. Steps: 1. File -> New -> Master Document 2. In Master document open navigator in sidebar 3. Open insert submenu -> empty submenu 4. Select "Text" in navigator sidebar -> Open insert submenu -> three entries Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 069c7dc4e9706b40ca12d83d83f90f41cec948f8 CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-GB Calc: CL threaded
(In reply to Dieter from comment #1) > I confirm the observed behaviour, but I don't think it's a bug. For example > if you have more than one item in the document But initially, I don't even have any items in the master document. >, it is not clear, where the > new item should be inserted. What is your expectation here? When we have no items - there's just one option. When we have items - either before all other items, or after all other items. Any of those two is legitimate.
Created attachment 188652 [details] Screenshot of Navigator in empty master document (In reply to Eyal Rozenberg from comment #2) > But initially, I don't even have any items in the master document. Screenshot shows how it looks for me. If you click on insert icon there is the message "[no selection possible]". Perhaps there could be an improvement to make it more clear, that you first have to select an item
(In reply to Dieter from comment #3) > Screenshot shows how it looks for me. If you click on insert icon there is > the message "[no selection possible]". Perhaps there could be an improvement > to make it more clear, that you first have to select an item But I should not have to select anything, that's the bug.
(In reply to Dieter from comment #3) > If you click on insert icon there is > the message "[no selection possible]". Actually, when I click on the insert menubutton (we call it a splitbutton maybe?), the menu opens, but all items are grayed out.
(In reply to Dieter from comment #3) > Screenshot shows how it looks for me. If you click on insert icon there is > the message "[no selection possible]". Perhaps there could be an improvement > to make it more clear, that you first have to select an item So as I sad, perhaps there should be an improvement here. Let's ask design-team
I don't see an issue here. You can edit the master document directly, and Text shows up in the Navigator after a few milliseconds, if that's a concern. Besides, I don't think 'inserting new items' into the master is the primary use case. My take => NAB.
We discussed the topic in the design meeting. Fact is that the floating Navigator always has the first entry "Text" selected while the docked variant doesn't. Without this selection no content can be added. But selecting the first entry wont resolve the problem since after adding a document/section nothing is selected. And it's unclear to the user why adding content is not possible - ideally it should be possible.
How about making the Insert tool button disabled when no entry is selected? It already becomes disabled when more than one entry is selected.
(In reply to Jim Raykowski from comment #9) > How about making the Insert tool button disabled when no entry is selected? > It already becomes disabled when more than one entry is selected. Wont be clear why it's not working; the insert function is the main interaction and one should be able to run it when the applications starts.
(In reply to Heiko Tietze from comment #10) > (In reply to Jim Raykowski from comment #9) > > How about making the Insert tool button disabled when no entry is selected? > > It already becomes disabled when more than one entry is selected. > > Wont be clear why it's not working; the insert function is the main > interaction and one should be able to run it when the applications starts. Alright, I think this would only take a couple of lines of code added to the click handler of the toolboxes to select the first entry in the tree when there isn't an entry already selected, just before the toolbox menu handler is called for the insert command. sw/source/uibase/utlui/navipi.cxx IMPL_LINK(SwNavigationPI, ToolBoxClickHdl, const OUString&, rCommand, void)
(In reply to Jim Raykowski from comment #11) > Alright, I think this would only take a couple of lines of code added to the > click handler of the toolboxes to select the first entry in the tree when > there isn't an entry already selected, But inserting should not selected the first entry. Suppose you have 3 entries, your window shows content from the 2nd entry, nothing is selected, and you press Insert. Why should the first entry now be selected? Also - shouldn't an insertion happen, by default, after the last item?
(In reply to Eyal Rozenberg from comment #12) > But inserting should not selected the first entry. Suppose you have 3 > entries, your window shows content from the 2nd entry, nothing is selected, > and you press Insert. Why should the first entry now be selected? Only sections are tracked by the Navigator. It would need to also track index and text entries for an entry to always be selected. I've poked at tracking text entries. It's sort of complicated. It's much easier to make a selection automatically if needed. I don't have a preference of the first or last entry being automatically selected. > Also - shouldn't an insertion happen, by default, after the last item? Fine with me.
> But inserting should not selected the first entry I meant, should not trigger selection of the first entry. But Jim understood what I was saying. (In reply to Jim Raykowski from comment #13) > Only sections are tracked by the Navigator. It would need to also track > index and text entries for an entry to always be selected. I've poked at > tracking text entries. It's sort of complicated. It's much easier to make a > selection automatically if needed. I don't have a preference of the first or > last entry being automatically selected. Well, auto-selection would be an improvement, but it would still be "off" in my view. Probably worth doing it, and remain with a minor, lower-priority bug.
The code reads that a text paragraph is first added before the selected entry, then the file or table of content section is inserted before the just added text paragraph when a file or table of content section is inserted into a master document using the Navigator, For example: Navigator initially shows: text With the text entry selected, right click popup menu > insert > file file1.odt result: file1.odt text With the file1.odt entry selected, right click popup menu > insert >file file2.odt result: file2.odt file1.odt text What I believe was the intended result when implemented, and is the result when a suspicious line of code is removed: file2.odt text file1.odt text I'm not sure including a text paragraph along with a file or table of content insert is the best behavior but it seems this how it was implemented. This enlightenment has come about while working on a patch that inserts linked files after the last entry when no entry is selected.
(In reply to Jim Raykowski from comment #15) > What I believe was the intended result when implemented, and is the result > when a suspicious line of code is removed: https://opengrok.libreoffice.org/xref/core/sw/source/core/edit/edglbldc.cxx?r=ada3cf7a#156
Well, I'm not very picky about all of this, as long as we don't need to make a selection to insert items. (Although other people, who work with master documents often, may be picky.)
Patches that make the Navigator track master document 'Text' and table of content content types are here: https://gerrit.libreoffice.org/c/core/+/157741/1 https://gerrit.libreoffice.org/c/core/+/157695/2 These make the Navigator less likely to not have an entry selected. For example, opening a new master document will always have the 'Text' entry selected in the Navigator. I poked around with making it possible to insert without having a selected entry in the Navigator. To make it easier to do this I proposed in bug 157610 to not automatically insert 'Text' when inserting a file or index. With the patches above the proposal is not as important.
Is the behavior provided by the merged patches in comment 18 enough to resolve this bug? Even with these patches there are still instances when there is no selected entry in the master document Navigator, for example, when the cursor is in a footnote or endnote or a frame is selected.
(In reply to Jim Raykowski from comment #19) > Is the behavior provided by the merged patches in comment 18 enough to > resolve this bug? Even with these patches there are still instances when > there is no selected entry in the master document Navigator, for example, > when the cursor is in a footnote or endnote or a frame is selected. Eyal: what do you think?