Created attachment 132156 [details] preliminary toolbar concept Writer's formatting toolbar is more focused on direct formatting, so this enhancement will focus on a formatting toolbar that is more focused on styles and the easier creation of styled documents. I've created a preliminary toolbar concept in the attached image for people to comment on and will add dependent bug reports for additional things that need to be done for the completion of the concept. The preliminary toolbar concept is as follows Show Styles Sidebar - separator - Paragraph Styles Update Style New Style Edit Style - separator - Default Paragraph Style Heading 1 Heading 2 Heading 3 Heading 4 Text Body Quotations - separator - Character Styles (bug 88512) Update Style (needs creation of uno command) New Style (needs creation of uno command) Edit Style (needs creation of uno command) - separator - Default Character Style Emphasis Strong Emphasis Quotation Source Text
Thanks for that mockup, Jay! One question to the New style command: Will it create a child style of the style where the caret actually is or a complete new style, independent from caret position and/or currently activated style in the drop-down?
Jay, * Not opposed as I think current standard and formatting toolbars over emphasize Direct formatting rather than applying Styles, but wouldn't this be more in line with MUFFIN customizations of the Sidebar or the Notebookbar? Shouldn't the legacy Toolbars (admittedly now mostly Glade .UI configured) be added to scope of MUFFIN? The mockup is fine, but as I note on bug 106681#c2 the drop list widget for Character styles is more concise and can actually hold all the available styles--rather than trying to decide on a specific set of buttons to provide on the toolbar. And of course, question becomes how these additional toolbar controls are made available. Are they core .src provided like other "legacy" toolbars, exposed from the View -> Toolbar menu--or would they be packaged as .oxt extensions to skin the UI with the tools and layout a user prefers to work with? Working out details to do the latter for all the MUFFIN resources would provide a lot more flexibility.
Created attachment 132160 [details] preliminary toolbar xml (In reply to Thomas Lendo from comment #1) > One question to the New style command: Will it create a child style of the > style where the caret actually is or a complete new style, independent from > caret position and/or currently activated style in the drop-down? Yes it would behave similar to its current behaviour in the sidebar, of creating a child style either based on the selection (if all the text is styled the same) or based on the caret position. Its creation is being handled in bug 106782. (In reply to V Stuart Foote from comment #2) > Not opposed as I think current standard and formatting toolbars over > emphasize Direct formatting rather than applying Styles, but wouldn't this > be more in line with MUFFIN customizations of the Sidebar or the Notebookbar? MUFFIN doesnt customize the sidebar or notebookbar, it simply provides preset arrangements of toolbars, sidebar and notebookbar. Wheels turn slowly with the sidebar and notebookbar, but much faster with toolbars, and if the concept works fine with the toolbars, it could possibly be adopted into the notebookbar, but highly unlikely with the sidebar. > The mockup is fine, but as I note on bug 106681#c2 the drop list widget for > Character styles is more concise and can actually hold all the available > styles--rather than trying to decide on a specific set of buttons to provide > on the toolbar. With 27 default character styles available in Writer, that doesnt reduce the number clicks and mouse movements needed to select a different style, which could take alot less mouse movement and a single click to activate from a toolbar button. > And of course, question becomes how these additional toolbar controls are > made available. Are they core .src provided like other "legacy" toolbars, > exposed from the View -> Toolbar menu--or would they be packaged as .oxt > extensions to skin the UI with the tools and layout a user prefers to work > with? It will be a standard toolbar .xml file, which a user can easily active from View > Toolbars. I've included in the attachment if you'd like to try it out, though some of the character style controls are just placeholders for when the real uno commands are implemented. > Working out details to do the latter for all the MUFFIN resources would > provide a lot more flexibility. The various MUFFIN toolbar/sidebar/notebookbar layouts are currently configured in code, which means that a dev would need to code the creation of new layouts.
(In reply to Yousuf Philips (jay) from comment #3) > MUFFIN doesnt customize the sidebar or notebookbar, it simply provides > preset arrangements of toolbars, sidebar and notebookbar. Wheels turn slowly > with the sidebar and notebookbar, but much faster with toolbars, and if the > concept works fine with the toolbars, it could possibly be adopted into the > notebookbar, but highly unlikely with the sidebar. > Sorry, going to continue to insist that as with Notebook Bar, the Sidebar content panels and decks remains fertile ground for customization--and in fact is MUFFIN https://bugs.documentfoundation.org/show_bug.cgi?id=33223#c11 The "provides preset arrangements" is exactly the customization that the majority of users would employ--providing that as Extension would be another way of delivering the customization, available to load as prefered, but not disrupting the UX otherwise.
(In reply to V Stuart Foote from comment #4) > Sorry, going to continue to insist that as with Notebook Bar, the Sidebar > content panels and decks remains fertile ground for customization--and in > fact is MUFFIN > https://bugs.documentfoundation.org/show_bug.cgi?id=33223#c11 Yes we've agreed to disagree about that, as users requiring dev skills to customize the sidebar, i wouldnt call it fertile ground for customization. > The "provides preset arrangements" is exactly the customization that the > majority of users would employ--providing that as Extension would be another > way of delivering the customization, available to load as prefered, but not > disrupting the UX otherwise. Yes it would be a good feature to be able to deliver toolbar presets as extensions, so please do submit an enhancement request for such a feature. Lets try to keep the focus of this bug about what is wanted in the new toolbar and we can have discussions about notebookbar/sidebar/MUFFIN in the mailing list or preferably in the design meeting, so the discussion is clear and we are on the same page, as that gets lost in bug comments. So are there any default paragraph or character styles that you think should/shouldn't be in the toolbar?
I was just looking at the style buttons included on the eLAIX extension toolbar. That extension is designed for creating epub3 compatible documents so it has the expected H1, H2, H3, etc. But it also has buttons for List styles and Object styles. So consider adding List style and Object style buttons. Maybe even Page styles too. While we are at it ... Why not make it possible for all styles to be a button on a toolbar? I guarantee knowledgeable users would use them. (I would) ----- Regarding toolbar presets ... There was a new extension just released the other day - Custom palette export. Any user can create a custom palette, and then export it as an extension. No programming required. Makes it very easy for any user to share. I am sure new custom palettes will start appearing now that is it this easy. A similar tool for toolbars would be very helpful. Custom Toolbar Export Creating and sharing a custom toolbar could be as easy as a custom template. In fact a custom toolbar & custom template package would be fantastic.
(In reply to LibreTraining from comment #6) > I was just looking at the style buttons included on the eLAIX extension > toolbar. > That extension is designed for creating epub3 compatible documents so it has > the expected H1, H2, H3, etc. Can you show us a screenshot?
Created attachment 132211 [details] Jay's toolbar concept with list widget I like the preliminary toolbar concept and it is not revolutionary because it presents more or less the Styles menu as toolbar buttons (which were selected due to high frequency of use from users, I assume ;-). What's missing is list styles which are not possible to insert as toolbar buttons now. The following ideas are an enhancement for a style-focused formatting toolbar. It it's worth I could create a new bug for it (or a bug for every widget?). I attached an enhanced concept with a list widget similar to the already existing Bulleted list widget or Numbered list widget or Outline list widget. The entries should show the list styles available in the Styles and Formatting sidebar panel. At the bottom new list styles can created or existing one edited (maybe that can also be achieved with a right-click context menu but in now existing list widgets there is also an edit line in the bottom of the entries). The same widget system can be used for table, frame and page styles to save vertical space and to give a preview to the user how it will it look like (similar to Word 2013 widgets for inserting Shapes, Header, Text fields, etc.). They are not so frequently used therefore they don't need a single click button. Also the same widget system can be used for indent paragraph styles to pool styles like First line indent, hanging indent, Marginalia and Text body indent. One other important point is localization - most languages need more space than English, therefore we can't fill the whole toolbar with text buttons. IMO this all is so basic stuff that all the ideas could be included in the Notebookbar too. How it's possible to make a Notebookbar style-focused formatting tab?
(In reply to Thomas Lendo from comment #7) > (In reply to LibreTraining from comment #6) > > I was just looking at the style buttons included on the eLAIX extension > > toolbar. > > That extension is designed for creating epub3 compatible documents so it has > > the expected H1, H2, H3, etc. > > Can you show us a screenshot? Yes. Just give me a few hours. The buttons are all images. So I will also list the text.
(In reply to Thomas Lendo from comment #7) > (In reply to LibreTraining from comment #6) > > I was just looking at the style buttons included on the eLAIX extension > > toolbar. > > That extension is designed for creating epub3 compatible documents so it has > > the expected H1, H2, H3, etc. > > Can you show us a screenshot? Maybe, just load the extension... https://extensions.libreoffice.org/extensions/elaix
(In reply to Thomas Lendo from comment #8) > > I attached an enhanced concept with a list widget similar to the already > existing Bulleted list widget or Numbered list widget or Outline list > widget. The entries should show the list styles available in the Styles and > Formatting sidebar panel. At the bottom new list styles can created or > existing one edited (maybe that can also be achieved with a right-click > context menu but in now existing list widgets there is also an edit line in > the bottom of the entries). > > The same widget system can be used for table, frame and page styles to save > vertical space and to give a preview to the user how it will it look like > (similar to Word 2013 widgets for inserting Shapes, Header, Text fields, > etc.). They are not so frequently used therefore they don't need a single > click button. > > Also the same widget system can be used for indent paragraph styles ... I would prefer the ability to add specific styles rather than a generic widget. I want to limit the options, and include custom styles. The widgets would also be useful for the many who do not use custom styles. So both options would be desirable to support both beginner and advanced users.
(In reply to V Stuart Foote from comment #10) > (In reply to Thomas Lendo from comment #7) > > (In reply to LibreTraining from comment #6) > > > I was just looking at the style buttons included on the eLAIX extension > > > toolbar. > > > That extension is designed for creating epub3 compatible documents so it has > > > the expected H1, H2, H3, etc. > > > > Can you show us a screenshot? > > Maybe, just load the extension... > > https://extensions.libreoffice.org/extensions/elaix I am looking at the v5.0 beta, which is hard to find. And I had to fix it for the closing ) bug. I will attach the fixed version when I am at my desktop in few hours.
(In reply to LibreTraining from comment #11) > (In reply to Thomas Lendo from comment #8) > > I attached an enhanced concept with a list widget similar to the already > > existing Bulleted list widget or Numbered list widget or Outline list > > widget. ... > > The same widget system can be used for table, frame and page styles ... > > Also the same widget system can be used for indent paragraph styles ... > > I would prefer the ability to add specific styles rather than a generic > widget. I want to limit the options, and include custom styles. Imagine a checkbox on the right of "Edit" in the opened widget: □ "Show only custom styles" But these widgets are concepts. Easier to do is the ability to use all kind of styles as a command and to insert a single button per list style, etc. (In reply to V Stuart Foote from comment #10) > (In reply to Thomas Lendo from comment #7) > > (In reply to LibreTraining from comment #6) > > > I was just looking at the style buttons included on the eLAIX extension > > > toolbar. > > Can you show us a screenshot? > Maybe, just load the extension... Sorry, don't realize that it is a LibO extension ...
Created attachment 132227 [details] eLAIX 5.0 Toolbar and Menus Screenshots of eLAIX 5.0 Toolbar and Menus I also included images of the menus (in the document area). The menus show the same icons as the toolbar and can be used as a list of the styles and other functions.
Created attachment 132228 [details] eLAIX Extension v5.0.1 The author's website describes this as a beta version. I fixed the closing ) issues and changed it from v5.0.0 to v5.0.1. So this is not an official release (the KM tells me I modified the file). It does install and now seems to run without code errors. But I have not tested it thoroughly (and it is a beta). With that said, it seems to be a really nice extension and if all these features work properly it is going to be a fantastic help.
Jay: Do the wanted toggle behavior of style buttons (mentioned in bug 106681, comment 27, paragraph 2) needs a new bug or is it covered by an existing one? Such a bug would fit to the dependency tree of this bug. Or do you want to wait till a developer made a point to your question? LibreTraining: The eLAIX extension has some interesting features. Bug I don't see any new ideas that should be part of the preliminary concept here; many of the buttons are duplicating other toolbars like the Standard toolbar (inserting images, bookmars, etc.).
(In reply to LibreTraining from comment #11) > I would prefer the ability to add specific styles rather than a generic > widget. Not limited to custom styles. That would definitely serve an existing need.
(In reply to LibreTraining from comment #6) > I was just looking at the style buttons included on the eLAIX extension > toolbar. > That extension is designed for creating epub3 compatible documents so it has > the expected H1, H2, H3, etc. The toolbar seems interesting. > But it also has buttons for List styles and Object styles. Unlike the paragraph style buttons, eLAIX bundles its own set of list styles which it applies when the list style buttons are pressed. > So consider adding List style and Object style buttons. I've added three list style buttons (Bullet, Number, Roman) to the toolbar, as those are available builtin list styles. Hopefully when a better set of default list style are added (bug 106988), more can be added to the toolbar. When you say Object styles, do you mean Frame styles, and if so, which Frame styles? > Maybe even Page styles too. Which page styles do you suggest? Most of the default ones look the same, except envelope, landscape, left page, and right page. (In reply to Thomas Lendo from comment #8) > The following ideas are an enhancement for a style-focused formatting > toolbar. > It it's worth I could create a new bug for it (or a bug for every widget?). Yes it would be a good idea, so i've filed a bug for it (bug 107000). > One other important point is localization - most languages need more space > than English, therefore we can't fill the whole toolbar with text buttons. The finalized toolbar would have icons rather than text, so there wouldnt be an issue of space there. (In reply to Thomas Lendo from comment #16) > Jay: > Do the wanted toggle behavior of style buttons (mentioned in bug 106681, > comment 27, paragraph 2) needs a new bug or is it covered by an existing > one? Such a bug would fit to the dependency tree of this bug. Or do you want > to wait till a developer made a point to your question? Bug filed (bug 106999).
I've submitted a patch, so it can get into a daily build and people can really test it out and give feedback. https://gerrit.libreoffice.org/36717
Yousuf Philips committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=e3cfb753524ecfabc07bccef5f5b2b54d06cd444 tdf#106781 Style-focused formatting toolbar for writer It will be available in 5.4.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Commit Notification from comment #20) > Yousuf Philips committed a patch related to this issue. > It has been pushed to "master": Jay, thanks for your commit! I'll test it when I've time for. A question: Is it possible (or is it already implemented) to only show the Style-focused formatting toolbar in situations when the Formatting toolbar is shown too? For example, it shouldn't be shown on images or frames. Negative effect if not context-sensitive is e.g. that the image/frame toolbars are shown additionally to the text toolbar which makes the view canvas "jump" when selecting/unselecting an image/frame. And I didn't want to wait till bug 106846 is fixed -- respectively: as pre-installed toolbar it should be context-sensitive like the other toolbars.
Regarding the eLAIX extension ... It is just an example of a dedicated toolbar which emphasizes styles vs. direct formatting. That toolbar attempts to put all the tools needed for ePub documents in one place. Instead of scattered around in multiple toolbars. And it adds some missing features. The tools developed for this styles-focused toolbar will enable other dedicated toolbars. For example Corel WordPerfect X8 has a Legal Toolbar. It includes all the the tools needed by lawyers to file pleadings, etc. in one toolbar. It includes paragraph styles. It includes page styles. It includes buttons to run fill-in-the-form macros to get the document started with proper page layout and the basic information which is needed every time. Another example is a Long Document Toolbar. The tools needed for long documents are scattered all over the place. And turning all these separate toolbars on and off is a giant PITA. Having to go back into that toolbars menu over and over again is ridiculous. I will create a separate bug report/request for that issue - with examples from other apps which work better. Adobe InDesign has pre-defined and customizable Workspace options. This changes the toolbars and the sidebars all at once. Essentials (minimal), Digital Publishing, Book (long print docs), Advanced (everything), etc. etc. All toolbars can be customized and all panels turned on or off. There a Lynda.com video on creating your own ePub workspace. Easy to do. MUFFIN on steroids. And, Yes, I did mean frame styles, object styles is the similar feature in InDesign. :-)
(In reply to Thomas Lendo from comment #21) > Is it possible (or is it already implemented) to only show the Style-focused > formatting toolbar in situations when the Formatting toolbar is shown too? I had tried to do it in the commit, but wasnt able to get that functionality working, so i'll have to leave it to a dev to look into. So to solve the issue, i placed the toolbar as a 3rd toolbar, so no constant jumping happens. (In reply to LibreTraining from comment #22) > Adobe InDesign has pre-defined and customizable Workspace options. > This changes the toolbars and the sidebars all at once. LibreOffice has a similar feature in the View > Toolbars and once we have additional focused toolbars geared towards specific workflows, we'll additional toolbar layouts for them. > And, Yes, I did mean frame styles, object styles is the similar feature in > InDesign. :-) As LO doesnt have any styled predefined frame styles, it cant be incorporated into the toolbar at present. I'd suggest you submit an enhancement request for the creation of a good set of predefined styled frame-type styles that could be used.
Just tried with Version: 5.4.0.0.alpha0+ Build ID: f0340e3dca1091accdb71e0c566b96cdf9e0f791 CPU threads: 4; OS: Linux 4.4; UI render: default; VCL: kde4; TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2017-04-21_13:34:48 Locale: es-ES (es_ES.UTF-8); Calc: group If I go to "customize toolbar" on the new style toolbar and add the "Character style" or the "List style" box it adds just another "paragraph style" box instead. The rest of the toolbar seems to work OK.
(In reply to RGB from comment #24) > If I go to "customize toolbar" on the new style toolbar and add the > "Character style" or the "List style" box it adds just another "paragraph > style" box instead. The rest of the toolbar seems to work OK. Yes those are just placeholders now until the character style (bug 88512) and list style (bug 107000) boxes are created.
I created bug 107851 because the other bug 106846 is for toolbars that are created by the user and not toolbars delivered by LibO. Jay: The aligning, line spacing and paragraph spacing commands are nice. Idea to enhance the style-focused behavior: These commands should change the corresponding paragraph style's attributes of the selected paragraph, not the selected paragraph in a direct-formatting way. How does that sound? Too strange? What I added to my company's style-focused formatting toolbar is the highlight color button/widget. Because people like to (temporary) emphasize or mark some text for collaborating people.
(In reply to Thomas Lendo from comment #26) > I created bug 107851 because the other bug 106846 is for toolbars that are > created by the user and not toolbars delivered by LibO. Though 106846 initially began about user custom toolbars, it expanded to include all toolbars, so i've closed yours as a duplicate. > The aligning, line spacing and paragraph spacing commands are nice. Idea to > enhance the style-focused behavior: These commands should change the > corresponding paragraph style's attributes of the selected paragraph, not > the selected paragraph in a direct-formatting way. How does that sound? Too > strange? Initially i didnt place any of these direct formatting-level paragraph options into the toolbar, but thought that it would be easier for users of the toolbar to change them with direct formatting and click the 'update style' button, rather than always having to open the edit style dialog. But yes having duplicate style-level commands for commands in the formatting toolbar would be beneficial (bug 107865), as we could create a duplicate of the formatting toolbar that would work at the style-level, that could benefit users who want to begin using styles, while the toolbar being created in this bug report is more for advanced style users. > What I added to my company's style-focused formatting toolbar is the > highlight color button/widget. Because people like to (temporary) emphasize > or mark some text for collaborating people. Interesting as i was just thinking to add font color, highlight and strikethrough to the toolbar. :D
Yousuf Philips committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=1fde962b71860d77fb10e9b16c9d5b6c124d9b61 tdf#106781 Enable a few hidden items in writer styles toolbar It will be available in 6.0.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Thanks for the last patch, Jay. Seems to be the optimum of style-focused commands until some depending bugs are fixed. One sidenote, can you copy the toolbar to Writer for master documents as it was done in bug 103733?
(In reply to Thomas Lendo from comment #29) > Thanks for the last patch, Jay. Seems to be the optimum of style-focused > commands until some depending bugs are fixed. Hopefully additional minor improvements coming soon. > One sidenote, can you copy the toolbar to Writer for master documents as it > was done in bug 103733? Maybe when its complete.
Yousuf Philips committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=1de71f95047630c1488e0a63a3a43cea8dfb8507 tdf#106781 Copy style-focused toolbar to writer master doc It will be available in 6.0.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Yousuf Philips committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=970627c079e5e48a606859b3a8d71abbdec3a2c0 tdf#106781 Updates to tango icons in writer styles toolbar It will be available in 6.0.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Yousuf Philips committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=cc9718587110757b3b7ef8813089458b07aec60d tdf#106781 Make buttons work with RTL and accessibility It will be available in 6.0.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Yousuf Philips committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=e62d00db505258ac788958e354b5f928a99d4cad tdf#106781 Add icons for new numbering list styles It will be available in 6.1.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Yousuf Philips committed a patch related to this issue. It has been pushed to "libreoffice-6-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=bb8fedb5645e2c8103f670f398ee4a3bd5b5bad0&h=libreoffice-6-0 tdf#106781 Add icons for new numbering list styles It will be available in 6.0.0.2. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
A polite ping to Yousuf Philips: is this bug fixed? if so, could you please close it as RESOLVED FIXED ? Thanks
(In reply to Xisco Faulí from comment #36) > A polite ping to Yousuf Philips: is this bug fixed? if so, could you > please close it as RESOLVED FIXED ? Thanks Xisco, this is fixed when the bugs are fixed that it depends on.
(In reply to Thomas Lendo from comment #37) > (In reply to Xisco Faulí from comment #36) > > A polite ping to Yousuf Philips: is this bug fixed? if so, could you > > please close it as RESOLVED FIXED ? Thanks > Xisco, this is fixed when the bugs are fixed that it depends on. It's not a meta ticket, has patches submitted... resolved. No dev will read a ticket with >10 comments that has been solved.