Description: Format->Page->Header->Edit I press the "Custom header" button marked 'T' - for text attributes; I select a larger font size, and say an orange text colour, and super-script. Interestingly, these are not saved by the dialog as I close it; so re-opening the flow and re-visiting the data shows that this is not persisted by the dialog. Actual Results: Expected Results: Reproducible: Always User Profile Reset: No Additional Info: User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36
Hmm - so in fact this is an idiot bug report =) You need to have some text selected for the format to apply to it; so the behavior of 'T' is a little non-intuitive. It would be nice - if no text is selected, to pre-select the text in whichever pane the cursor contains - I know that was my intention at least =) Thoughts from UX ? if they like that, I'll turn it into an easy-hack with some code-pointers; thanks !
(In reply to Michael Meeks from comment #1) > Hmm - so in fact this is an idiot bug report =) Well, let me be friendly and disagree on that; users - however dump it may seem - are always right (TM) /me hope people will not quote me for this :p > Thoughts from UX ? if they like that, I'll turn it into an easy-hack with > some code-pointers; thanks ! OK > change summary a bit. thanks in advance for code pointers!
(this needs to be added for ux-advize)
Well it does do something without selection, it changes the font style at that point, so you can type with the newly selected font features. It acts the same ways as it would in writer with direct formatting, as you can have multiple direct formatting applied to the text in the pane. It would be no different than having bold, italics, underline, etc buttons in the dialog that a user could press to apply the feature. So maybe having a simple toolbar of direct formatting attributes (font name, font size, bold, italics, underline, font color) is the simplest way of making it easy for them to customize the font style and then changing the 'T' button into a 'More...' buttton. We should also change the 'Header' label to 'Presets' and change 'Custom Header' label to 'Insert Field'.
Created attachment 127850 [details] dialog mockup
Sounds reasonable; but now this is quite a large change =) certainly for an easy-hack. As far as I can see, it is a trivial minority use-case to first change the font and colour, and then type - whereas - changing it, seeing there is no change; and closing and re-opening, and seeing that that change is not persisted (even for the same cursor position ;-) is well - I'm no idiot and fell immediately into that trap. Type then format should be the norm, I hope - and if not - when there is no content in the box, it can behave as before =) I would strongly suggest that we go with the tweak to pre-select the text if nothing is selected when that button is pressed. Then again - I like your new mockup =) re-arranging it trivially in glade anyway to change the order would be great; and a legend of "Insert Field" rather than Field might be better for the 2nd row of buttons (?) [ we should drop the 'T' there - it is now the 'More' button right ? ;-].
(In reply to Michael Meeks from comment #6) > Sounds reasonable; but now this is quite a large change =) certainly for an > easy-hack. Yes large changes are needed to most dialogs, so might as well fix them all in one go to improve UX. Would assume moving around widgets in glade should be easy to do, but having the formatting toolbar would be the hard part. > As far as I can see, it is a trivial minority use-case to first > change the font and colour, and then type - whereas - changing it, seeing > there is no change; and closing and re-opening, and seeing that that change > is not persisted (even for the same cursor position ;-) is well - I'm no > idiot and fell immediately into that trap. Yes i only changed the font and color at the beginning as your steps in the description didnt say to type something first and then click the 'T' button. :D But yes having text attributes hidden in a dialog would likely confuse many to assume it might be a style type dialog which affects all the text in the pane. Cant predict what my behaviour would have been if i didnt already know how it functions and whether i would have easily discovered how it does or would have had your same frustrations. > Type then format should be the > norm, I hope - and if not - when there is no content in the box, it can > behave as before =) I would strongly suggest that we go with the tweak to > pre-select the text if nothing is selected when that button is pressed. Yes type then format would definitely be the most used behaviour, but dont tell that to style users :D. Well with no content in the box, it would still be selecting no characters and styling it :D. > Then again - I like your new mockup =) re-arranging it trivially in glade > anyway to change the order would be great; and a legend of "Insert Field" > rather than Field might be better for the 2nd row of buttons (?) Glad you like it :D. Initially i had it as 'Insert Field' and changed it just to 'Field' to save space, especially as we have to think about l10n, and also because we can add 'insert' to the button tooltips without worry. > [ we should > drop the 'T' there - it is now the 'More' button right ? ;-]. About the 'T' icon, i was using it for insert title, as the icon for insert title in worthless - its the icon for up one folder level. ;D
Nice mockup in c5 could be the basis for an easyhack.
I would like to work on this. Can you pls give me the code pointers and any other changes in the given mockup?
Code pointers: sc/uiconfig/scalc/ui/headerfootercontent.ui - describes that dialog sc/source/ui/pagedlg/scuitphfedit.cxx - has the code for this: , m_xBtnText(m_xBuilder->weld_button("buttonBTN_TEXT")) is the 'Text attributes' button IMPL_LINK( ScHFEditPage, ClickHdl, weld::Button&, rBtn, void ) handles the setting of text attributes. And we need to check for and set a selection here I guess: if (&rBtn == m_xBtnText.get()) { m_pEditFocus->SetCharAttributes(); } Thanks ! =)
Re-evaluating the EasyHack in 2022 This enhancement is still relevant. This is about creating a better way to format text in a UI (headerfootercontent.ui). The suggested path to achieve this is to use a new design for the UI, as shown in attachment 127850 [details]. Btw, I had to read the comments more than once to understand the whole problem. :-) I suggest that anyone who wants to fix this issue should read the all the comments thoroughly.
Submitted preparation stage (upgrade relevant UI file to newer version of glade): https://gerrit.libreoffice.org/c/core/+/161707
Is this completed?
(In reply to Devansh Varshney from comment #13) > Is this completed? No.