Steps: 1) Open Writer 2) Insert table 3) Activate Table > Repeat Heading Rows 4) Deactivate Table > Repeat Heading Rows 5) Add a row to the table 6) Notice that Table > Repeat Heading Rows is disabled. Version: 5.1.0.0.alpha1+ Build ID: b712b1f63492a311e4a51cffd516b3e202a140e6 TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2015-08-23_06:03:52 Locale: en-US (en_US.UTF-8)
Isn't 6) exactly the desired outcome after disabling the Heading rows repeat? I don't understand the relation of the summary to the description. Is "menubar" the menu or toolbar?
(In reply to Beluga from comment #1) > Isn't 6) exactly the desired outcome after disabling the Heading rows repeat? No. You should be able to turn this on and off as you like, just like you can do so in the Table > Table Properties > Text Flow > Repeat Heading. If you leave out step 5, it wont be disabled in step 6. > I don't understand the relation of the summary to the description. Is > "menubar" the menu or toolbar? Yes menubar is the correct word for the bar at the top which contains the menu. https://en.wikipedia.org/wiki/Menu_bar
Ok it seems I wasn't parsing correctly. It seems by "disabled" you mean it is somehow greyed out or something, unable to change the state at all. Well, I'm not seeing this in the menu or table properties so leaving as unco. Win 7 Pro 64-bit, Version: 5.0.1.2 (32-bit) Build ID: 81898c9f5c0d43f3473ba111d7b351050be20261 Locale: fi-FI (fi_FI)
Created attachment 118647 [details] screencast Well encase my instructions werent good enough for you to get it, hopefully this screencast will make it easier.
Linux only? Still no repro. Win 7 Pro 64-bit Version: 5.1.0.0.alpha1+ Build ID: 88c51cd55d1a9b29e62269c53b3923770253ab07 TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2015-09-11_13:09:15 Locale: en-US (fi_FI)
In 3.3.0 the same problem (menu greyed out, only it shows a Tick before, although it had be turned off in the previous stepp..)
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.1.6 or 5.2.3 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20170103
Dear Yousuf Philips (jay), To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
(In reply to Yousuf Philips (jay) (retired) from comment #4) > Created attachment 118647 [details] > screencast Reproduced Arch Linux 64-bit Version: 7.1.0.0.alpha1+ Build ID: c54e1c22f30c23d00e2fe7521217569fcec59cc4 CPU threads: 8; OS: Linux 5.9; UI render: default; VCL: kf5 Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: threaded Built on 13 November 2020
Repro 7.2+. It's Table- Header Rows Repeat Across Pages.
Dear Yousuf Philips (jay) (retired), To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
This bug is still biting us! Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 5cd9de202765e243e41416802f3e4486b8a96f16 CPU threads: 4; OS: Linux 6.1; UI render: default; VCL: gtk3 Locale: he-IL (en_IL); UI: en-US
Same as on bug 156455: access to infrequently used functions via main menu and properties dialog is sufficient. => NAB/WF
(In reply to Heiko Tietze from comment #13) > Same as on bug 156455 This is absolutely not the same. The question of how this main menu entry should behave is not a trivial one. At the moment, its toggling-on has a row-specific semantic, while its toggling-off has a table-wide semantic. And the row-specific semantic is difficult to figure out, unless you've selected a full set of rows that's also contiguous from the beginning of the table. I would not support just allowing the enabling Yousuf originally asked for, but I do think this toggle merits some thought.
(In reply to Eyal Rozenberg from comment #14) > At the moment, its toggling-on has a row-specific semantic... You mean the command is disabled except for the first row - or when repetition is active? I'd call it an implementation error -- and vote against such main menu entry anyway (bug 156454).
We discussed the topic in the design meeting. We discussed whether this command is frequently used and thus merits a reasonable visibility. The functions work well but most of the trouble starts with the unconditional placement in the main menu and removing it should be a step forward. We agreed on adding to the context menu as an acceptable "compensation" for the loss of visibility via the main menu. And we think shorter labels that follow the guidelines are needed too. So in a nutshell: Rename + .uno:HeadingRowsRepeat to "Repeat Header Rows" + .uno:RowSplit to "Break Row Across Pages" => officecfg/registry/data/org/openoffice/Office/UI/WriterCommands.xcu Remove from main menu => sw/uiconfig/*/menubar/menubar.xml Add to context menu => sw/uiconfig/*/popupmenu/table.xml
(In reply to Heiko Tietze from comment #16) Heiko, you've _mostly_ summarized the result of our discussion; but the bit you left out is exactly the bit relevant to this bug. Let me explain... > The functions work well Ah, but we agreed (at least, I thought we agreed) it does _not_ well - because it intricates two different functions: 1. Toggling whether or not heading rows repeat 2. Setting which rows are the heading rows and this is what Yousuf was complaining about: He could not toggle the repetition under various conditions, even though one should always be able to make the toggle (at least if at least one header row is defined). Also, an item whose action depends on the current selection of header rows can't be named as though it doesn't. i.e. the separate command - would be named something like "Mark as header rows" or "Set header rows" etc. > but most of the trouble > starts with the unconditional placement in the main menu and removing it > should be a step forward... We agreed on adding to the context menu as an > acceptable "compensation" for the loss of visibility via the main menu. Right. But not adding the intricated command, but the toggle > And we think shorter labels that follow the guidelines are needed too. Right. But - the short label only makes sense for the separated toggle functionality > > So in a nutshell: > > Rename > + .uno:HeadingRowsRepeat to "Repeat Header Rows" > + .uno:RowSplit to "Break Row Across Pages" > => officecfg/registry/data/org/openoffice/Office/UI/WriterCommands.xcu > > Remove from main menu > => sw/uiconfig/*/menubar/menubar.xml > > Add to context menu > => sw/uiconfig/*/popupmenu/table.xml So, that's the easy part - but that part does not resolve this particular bug at all - it only moves things from place to place and renames them. The functionality split is the bigger deal here.