Description: Insert Pagenumber and insert header and footer linking to the same dialog Steps to Reproduce: 1. Open Impress 2. Go to Insert --> Pagenumber (take notice of the dialog) 3. Go to Insert --> Header and footer (take notice of the dialog) Actual Results: Same dialog Expected Results: Two different dialogs Reproducible: Always User Profile Reset: YES Additional Info: Version: 5.3.0.0.alpha1+ Build ID: 02ec51c7e0bf9320b32ec73233ecaaf160448776 CPU Threads: 4; OS Version: Windows 6.2; UI Render: default; Layout Engine: new; TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2016-11-20_23:12:18 Locale: nl-NL (nl_NL); Calc: CL User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0
This is the same in 3.3. I think this is the intended behavior. There is the checkbox Slide number. Do you have a proposal to make it different?
(In reply to Buovjaga from comment #1) > This is the same in 3.3. I think this is the intended behavior. There is the > checkbox Slide number. > > Do you have a proposal to make it different? Didn't check it first, my bad! I suppose the menu-item Insert Page Number could be removed. It doesn't have a separate function as in Writer. The Calc Insert menu doesn't have Page Number item either. In Calc page-numbers can be created with 'Header/Footer' option.
(In reply to Telesto from comment #2) > Didn't check it first, my bad! I suppose the menu-item Insert Page Number > could be removed. It doesn't have a separate function as in Writer. The Calc > Insert menu doesn't have Page Number item either. In Calc page-numbers can > be created with 'Header/Footer' option. I think it's separate because of easier discoverability. Let's throw this to UX real quick.
At least the commands are different. Page Number... <menu:menuitem menu:id=".uno:InsertPageNumber"/> Header and Footer... <menu:menuitem menu:id=".uno:HeaderAndFooter"/>
The two commands/slots are served by the same Execute function and the same branch in switch-case, see here: http://opengrok.libreoffice.org/xref/core/sd/source/ui/view/drviews3.cxx#289 Afaics it has been like that since 2004 when the feature (header/footer support in Impress'n'Draw) has been added If you ask me, it's slightly substandard UX, but I'm "just" a developer, not a UX expert
So for consistency, we should change .uno:InsertPageNumber towards a toggle function which shows or hides the page number. The function itself should be disabled when there is no footer. Since master slides define page numbers on/off this option should be also taken into account. Sounds like an easyhack to me. Code pointer is in comment 5.
(In reply to Heiko Tietze from comment #6) > So for consistency, we should change .uno:InsertPageNumber towards a toggle > function which shows or hides the page number. The function itself should be > disabled when there is no footer. Since master slides define page numbers > on/off this option should be also taken into account. > > Sounds like an easyhack to me. Code pointer is in comment 5. This is a Uno api change, that need first to be aproved by ESC, then the consequences for 3rh party programs. This requieres insight.
First, not every change is an (incompatible) API change. Deleting a command is an API change. Changing the type and number of arguments a command accepts is an API change. However, changing return value of a command (which is what would be required to make this .uno command a binary toggle) is NOT an API change, thus it's fine to do it that way Second, the code pointers are slightly misleading and rather incomplete. The return value of SID_INSERT_PAGE_NUMBER slot is defined in sd/sdi/sdraw.sdi, it should be changed from SfxVoidItem to SfxBoolItem. Then, a new case has to be added to sd/source/ui/view/drviews3.cxx, DrawViewShell::ExecCtrl to serve the changed slot. It has to contain some code to find out if the current page has a page number visible and toggle it on/off Come to think of it, maybe it'd be better to do this in a new, separate slot (.uno:TogglePageNumber?) instead of sodomizing the old .uno:InsertPageNumber one And finally third, given all of the above, this is likely not an easy hack.
OK, so I think the confusion here is that the dialog that shows either with Insert -> Page Number... or Insert -> Header and footer... is mis-categorized. It is not an insert function at all; more like a formatting one (a bit equivalent to Format -> Page Style... (tabs Header / Footer). In the Writer, Insert -> Page Number inserts a field with the actual page number, and Insert -> Header and Footer inserts the actual header / footer. I think the best solution would be to move the dialog to the Format menu, and remove both "Page Number..." and "Header and Footer..." from the Insert menu; but no idea what would be the impact on the user who are used to this location of the dialog.
Hmm, this has been discussed rather extensively when working on the new Menu layout for Impress. :) Logic would be to have one entry "Insert > Slide number / Header and Footer text" But way too long. (Note that the entry is "Header and Footer" since there is a header in the Notes and Handouts..) I would suggest to leave as is.
(In reply to Cor Nouws from comment #10) > I would suggest to leave as is. Made a patch last week which awaits approval. "Header and Footer" goes under Slide/Master Elements and Pagenumber will be removed from the main menu.
(In reply to Heiko Tietze from comment #11) > Made a patch last week which awaits approval. "Header and Footer" goes under > Slide/Master Elements and Pagenumber will be removed from the main menu. I have the impress ;) ion that the following applies: Master Elements allows to show or hide elements per master page. Multiple master pages are possible in one presentation. When one enters text for a footer, or a slide number, that is applied to all slides (except #1, by choice) that have the corresponding master page elements set to visible. Master Elements, show or hide, is more about the design of the presentation, and not necessary to be 'right in the face'. Inserting a page number or entering the desired text for footer (header) is a matter for the basic user who makes the presentation.
(In reply to Cor Nouws from comment #12) > I have the impress ;) ion that the following applies: So you disagree with what kendy stated in comment 9? Do you suggest to change Impress so that the page number is not part of the master anymore? These are rhetorical questions, we better discuss it in a meeting. If you, on the other hand, think my suggestion to have H&F next to master elements is a fail you could easily -1 the patch https://gerrit.libreoffice.org/#/c/31502/. But please share a better idea in this case.
(In reply to Heiko Tietze from comment #13) > (In reply to Cor Nouws from comment #12) > > I have the impress ;) ion that the following applies: > > So you disagree with what kendy stated in comment 9? Yes. The formatting aspect is done via Slide>Master Elements The insert aspect is done via Insert>Slide Number (etc) (As I expressed in my previous comment.) (Similar in Writer: - Format>Page for formatting header/footer and page number; - Insert>Header/Footer to actually add content; and > Page Number to actually insert the page number field ) > Do you suggest to > change Impress so that the page number is not part of the master anymore? No. > These are rhetorical questions, we better discuss it in a meeting. I'm always is favor of discussion in a meeting when enough factual information (and interpretations) are gathered beforehand. > If you, on the other hand, think my suggestion to have H&F next to master > elements is a fail you could easily -1 the patch > https://gerrit.libreoffice.org/#/c/31502/. Done. > But please share a better idea in this case. IMO the current situation is the best, most consequent across the modules.
(In reply to Cor Nouws from comment #14) > (Similar in Writer: > - Format>Page for formatting header/footer and page number; > - Insert>Header/Footer to actually add content; and > Page Number to You can insert the page number independently from the page formatting in Writer. The opposite is true for Impress where you insert a page number but remove it by changing the master layout. The page number is furthermore part of the master details hardly comparable to page settings in Writer. While I understand your concerns the issue remains: two functions lead to the same dialog. That's confusing for users. And I believe we make it more clear that page numbers are not the same as in Writer when the header/footer elements go to some other place. Alternatively (and even better IMHO) the page number would be a toggle function disabled when the element is excluded in the master slide (see comment 6). But the decision was made by ESC to better not touch .uno commands which brought us to the current situation. More opinions are welcome.
(In reply to Heiko Tietze from comment #15) > You can insert the page number independently from the page formatting in > Writer. The opposite is true for Impress where you insert a page number but > remove it by changing the master layout. In Writer, the page number (format/position) is stuck to the specific page style. In Impress, the page number (format/position) is stuck to the specific.. master page. > The page number is furthermore part > of the master details hardly comparable to page settings in Writer. Semantic discussion.. > While I understand your concerns the issue remains: two functions lead to > the same dialog. That's confusing for users. I agree that that is unfortunate. But breaking the logic "design&formatting versus inserting" (similar to Writer), and hiding the features that basic users will look for, seems even less ideal to me.
The page number field in Impress is the same as in Writer. It belongs to the kind "Text Fields" and is an element <text:page-number> in both cases. A page number field as such does neither belong to the page style in Writer nor to the Master in Impress/Draw. The <text:page-number> element can be child of a <text:p> element. And such paragraph is child of a <style:header> element or of <office:text> or of <draw:text-box> or of other places which allow a paragraph. [I know that LibreOffice has not implemented all possible places.] Impress has the difference to Writer, that it has a predefined frame which has a paragraph with the page number field. This frame is called "Slide Number Area" in the UI. But you can add the page number field to the title too or use a custom frame for example; that is via Insert > Field > Page Number. That is the same <text:page-number> element. And you need not insert the page number in a Master but you can add it into a slide directly, same as you can add a page number to any text in Writer. All these aspects make the page number different from the footer, header and date/time placeholders, which are pure presentation fields. Show/Hide in "Master Elements" dialog does actually mean to show/hide the frame, that is called "NNN Area" in the Master UI. It is very confusing, that its settings have priority over the checkboxes in "Header and Footer" dialog, but the "Header and Footer" dialog does not reflect that. I suggest: Keep the current "Header and Footer" dialog, but perhaps name it "Manage Field Areas" and put it into the Slide menu or Format menu. Remove the "Master Elements" dialog and make the check boxes in the current "Header and Footer" dialog work the same as in the current "Master Elements" dialog. Disable options in the "Header and Footer" dialog in Normal view, in case that Area is hidden by the Master. Users might want a "Slide Number" item in the Insert menu. That should not open the "Header and Footer"-dialog, but insert a slide number same as via Insert > Field. That would be similar to the "Insert > Page Number" item in Writer. It might be useful to have an additional item "Show Slide Number Area", so that the user need not find this setting in a dialog, which has not "slide number" in its name.
(In reply to Regina Henschel from comment #17) > I suggest: > Keep the current "Header and Footer" dialog, but perhaps name it "Manage > Field Areas" and put it into the Slide menu or Format menu. > Remove the "Master Elements" dialog and make the check boxes in the current > "Header and Footer" dialog work the same as in the current "Master Elements" > dialog. > Disable options in the "Header and Footer" dialog in Normal view, in case > that Area is hidden by the Master. The idea of combining both in one dialog sounds attractive. But it implies that is has two functions, what (partially) depends on the position where you would open the dialog: if you want to hide master elements for a master page, you have to open the dialog on a slide with that master page; if you want to insert text etc. in the master elements, you must open it on a different slide. This is not self explaining.. Could be circumvented by adding a list view to the dialog, showing all the applied master pages, so that in one run, all master pages can be handled. (Analogue to list view in e.g. Tools>Outline Numbering) But a problem you'll have with a dialog in that form, is that it may suggest that one can add different footer text to different master page slides. And that is not the case. So therefore more changes on a combined dialog are needed. > Users might want a "Slide Number" item in the Insert menu. That should not > open the "Header and Footer"-dialog, but insert a slide number same as via > Insert > Field. That would be similar to the "Insert > Page Number" item in > Writer. Activating the slide number in the current dialog, puts the field in the master page element(s). And you can check to omit the fist slide. This is quite different from putting a page number field om the cursors position, so why not simply ..: > It might be useful to have an additional item "Show Slide Number Area", so > that the user need not find this setting in a dialog, which has not "slide > number" in its name. what is what one does in the current dialog.
Created attachment 129398 [details] seeming different footer content on same master (In reply to Cor Nouws from comment #18) > But a problem you'll have with a dialog in that form, is that it may suggest > that one can add different footer text to different master page slides. And > that is not the case. So therefore more changes on a combined dialog are > needed. It is not a problem, which comes with a new dialog, but the problem exists already in the current "Header and Footer" dialog. In Master View it looks, as if you can set the content of the footer-field. But the content of the footer-field never belongs to a Master page. [The footer-field is the part with placeholder-text <footer>, which is gray.] To see what I mean open the attached document. Goto first slide, then switch to Master View. Open the 'Header and Footer' dialog and look at the line 'Footer text:'. You will see "1First version inside footer1". Cancel and close Master View. Goto second slide, then switch to Master View. Again open the 'Header and Footer' dialog and look at the line 'Footer text:'. You will see "2Second version inside footer2". Cancel and close Master View. I think, these dialogs need a deep rework. An additional idea for a solution: Make different dialogs for Master View and for Normal View.
For what it's worth, I like the Regina's proposal; particularly the "Keep the current "Header and Footer" dialog, but perhaps name it "Manage Field Areas" and put it into the Slide menu or Format menu." would sort out the confusion that was reported in this bug in the first place :-)
What i mentioned in the gerrit patch "we have unified the location of 'header & footer' in all modules to the insert menu, so i would not move it". (In reply to Heiko Tietze from comment #6) > So for consistency, we should change .uno:InsertPageNumber towards a toggle > function which shows or hides the page number. The function itself should be > disabled when there is no footer. Since master slides define page numbers > on/off this option should be also taken into account. Agree that this should be changed, as i believe i mentioned the same somewhere else but cant remember where, but its code should only show and not hide the slide/page number field, as it is in the insert menu. Google Docs has it in this way as well. (In reply to Jan Holesovsky from comment #20) > For what it's worth, I like the Regina's proposal; particularly the "Keep > the current "Header and Footer" dialog, but perhaps name it "Manage Field > Areas" and put it into the Slide menu or Format menu." Not sure about renaming it as the same dialog is in Powerpoint and WPS/Kingsoft and named the same way.
(In reply to Jan Holesovsky from comment #20) > For what it's worth, I like the Regina's proposal; particularly the "Keep And what about "I think, these dialogs need a deep rework."? When we start changing these area's, with so many remarks, quirks.. let's please go all the way.
*** Bug 109109 has been marked as a duplicate of this bug. ***
Dear Telesto, 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 Version: 6.4.0.0.alpha0+ Build ID: 8387a6db641b29e6ff3c2f4cdc4688f538cbe35f CPU threads: 4; OS: Linux 5.0; UI render: default; VCL: gtk3; TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2019-08-09_06:28:42 Locale: nl-NL (nl_NL.UTF-8); UI-Language: en-US Calc: threaded now Insert > Slide Number now puts the slide number where the cursor is.. If that is really an improvement or more a affront..?
Please add keyword 'needsUXEval' and CC 'libreoffice-ux-advise@lists.freedesktop.org' if input from UX is needed.
Dear Telesto, 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
As Cor noted, Insert > Slide Number puts the slide number so this is WFM. Slide number gets somewhat strange position in the slide center, and frame is too large, but that's for another report.
Just for the record, the command for Insert > Slide Number was switched by Andreas Kainz in 6.2 from .uno:InsertSlideNumber to .uno:InsertSlideField with c50e4badfcb701d9e3927dae6617bb0d33f386e0 But now we have a duplicate in the menu, given that it's also in Insert > Fields > Slide Number.