As stated in bug 88367, we have many fields in the statusbar that are of little use to main users, so rather than removing them as some are opposed to this, these fields can be hidden by default and then enabled by users who wish to use them. Fields i think can be hidden by default :- 1) Text Language - Useful to users who write documents in multiple languages 2) Insert Mode - Cursor indicates which mode you are in 3) Selection Mode - available in Edit menu 4) Document Modified State - save toolbar button provides this functionality 5) Digital Signature - limited to users who digitally sign their documents I would suggest that the option to enable/disable these fields be accessible in a View > Statusbar submenu along with the the current View > Statusbar checkbox. Alternatively, it would be available in the Tools > Options dialog (LibreOffice Writer > View).
+1 but need to agree on which fields continue to show by default, and prioritization of sizing behavior when more fields are open than fit the width of the status bar. And of course this will need complete details in F1 help and documentation.
It's hard to imagine the user who tweaks the status bar rather than switching it completely on/off. However customization makes sense in general. But I think those settings belong to the configuration, i.e the dialog.
(In reply to V Stuart Foote from comment #1) > +1 but need to agree on which fields continue to show by default, and > prioritization of sizing behavior when more fields are open than fit the > width of the status bar. What is remaining is - Page Number, Word Count, Page Style, Object Properties, Page View, Zoom. (In reply to Heiko Tietze from comment #2) > It's hard to imagine the user who tweaks the status bar rather than > switching it completely on/off. However customization makes sense in > general. But I think those settings belong to the configuration, i.e the > dialog. Yes customizing things are limited to more advanced users (e.g. Eve), so we need to have the default statusbar suitable to new and average users (e.g. Benjamin). The other alternative is to have a basic and advanced mode for the statusbar, so users dont have to choose everything they want enabled and then it would be a simplified option that could be in the View menu, and likely a simplified option for a dev to correctly specify the sizes for the basic mode. Here are statusbar options in other suites: Google Docs - None iWork Pages '09 - Zoom Percentage, Word Count, Page Number - http://www.digitalcupcake.net/wp-content/uploads/2011/12/iWork-Pages-One-Up-Two-Up.png iWork Page 5.0 - No actual statusbar, but you can enable a hovering Word Count that appears close to the bottom of the window. Word 2013 - Page Number, Word Count, Spell Check status, View Shortcuts, Zoom Slider & Percentage - http://i1.ytimg.com/vi/Dzds_djefuI/maxresdefault.jpg Word 2011 Mac - View Shortcuts, Section, Page Number, Word Count, Zoom Percentage & Slider - https://noppyfoto.files.wordpress.com/2011/03/screen-shot-2011-03-24-at-1-32-18-pm.png AbiWord - Page Number, Insert status, not sure what the next one is :D, Language - http://imagenes.es.sftcdn.net/es/scrn/13000/13357/abiword-23.jpg WPS/Kingsoft Writer - Page & Section Number, Row & Column Number, Word Count, Spell Check status, AutoBackup status, View Shortcuts, Zoom Percentage & Slider - http://1.bp.blogspot.com/-mtmWGiSCVj4/VEdl2zI2__I/AAAAAAABi3U/sF3mGV2cU7U/s1600/wps-writer_ubuntu.jpg
*** Bug 97681 has been marked as a duplicate of this bug. ***
We're replacing our use of the 'ux-advise' component with a keyword: Component -> LibreOffice Add Keyword: needsUXEval [NinjaEdit]
I think customization of status bar issues could be solved by allowing users to specify for each item in the status bar: - hide/show - high/normal display priority - left-right order of display Some algorithm could be deployed to share the display space between items on this basis. An easy "reset to default" option would be pragmatic for saving novice users from "fiddling" errors. Personally, I rely on the zoom buttons for Writer and Calc but often find they disappear when I'm sharing a single screen with multiple applications. Having this capability in Calc would also give me/others continual access to the useful "Selection Sum/Count/etc." facility, which often gets hidden.
i cherish perusing this article so beautiful!!great work! https://hipster-vintage-and-indie.com
I love the blog. Great post. It is very true, people must learn how to learn before they can learn. lol i know it sounds funny but its very true. https://www.singinglikepro.com
You made such an interesting piece to read, giving every subject enlightenment for us to gain knowledge. Thanks for sharing the such information with us to read this https://www.mingmenhong.com
A great blog that I recommend to all my friends! I do not even know what I did without your advice, great work! https://small-home-ideas.com
Superbly written article, if only all bloggers offered the same content as you, the internet would be a far better place. https://www.debt-to-income.com
I agree with Tom Colley in comment #7. Being able to hide items that are of no use to me (which would make items that I DO care about appear, since they disappear when I use narrow windows) would be a great boon.
I would find a configurable status bar incredibly useful. I often have two windows open on a quite high resolution monitor. I do not want them overlapping. When I make the Writer window narrower I lose the language field. That is one I use very often as I write documents in multiple languages.
In case you will not wait, till something is implemented, you can already tweak the status bar by editing its xml-file: Copy the file statusbar.xml from <program>\share\config\soffice.cfg\modules\swriter\statusbar to <user>\config\soffice.cfg\modules\swriter\statusbar. (I suggest to copy it, because then you can simple delete the copied file, in case it does not work for you.) Open the file in an editor and change values and/or order. Some information about the status bar can be found in https://wiki.openoffice.org/wiki/Framework/Tutorial/Statusbar_Controller. Although for an old version of OpenOffice.org, most parts are still valid for LibreOffice.
You can tweak the status bar by editing its xml-file. https://2048game.io/
window weep hole: I am lose my statusbar bar. this satausbar re create. https://civiljungle.com/weep-holes/
*** Bug 150067 has been marked as a duplicate of this bug. ***
It is proposed to modify the behavior of Navigate by Comment so that it instead of opening the comment edit window, it instead moves the pointer to the comment anchor inside the page. This would keep the cursor in place when replying to closed comments that are no longer visible. While this may not be the desired response, it is better than losing the cursor altogether. The separate ticket please so https://gerrit.libreoffice.org/c/core/+/130471 https://slopegame.net can be assigned to it.
*** Bug 159073 has been marked as a duplicate of this bug. ***
Statusbar items are defined in xml files like https://opengrok.libreoffice.org/xref/core/sw/uiconfig/swriter/statusbar/statusbar.xml and look like this <statusbar:statusbaritem xlink:href=".uno:ModifiedStatus" statusbar:align="center" statusbar:ownerdraw="true" statusbar:mandatory="true" statusbar:width="16"/> So we can reasonably tweak the alignment and if it's mandatory and remains as long as possible on small windows sizes. Of course, a toggle to hide items is needed too. One option to tackle the problem is checkboxlist similar to the classic toolbars where users can hide/show individual items. Would be easy to use and maybe simple to implement. With the hurdle that right click interaction might have a meaning per panel. If things need to be more complex we may add a tab to the customization dialog with all UNO commands that may work on the statusbar on a left-hand list, the current setup right-hand, etc. all similar to toolbars or menus. My take is the simple solution, KISS!
(In reply to Heiko Tietze from comment #21) Trying to embrace the simplicity and complexity at the same time... consider the following set of potential state of affairs (which is obviously not the current reality): 1. The status bar is a kind of toolbar, but a special special kind. 2. Some UNO entities can be placed on both regular toolbars and status (tool)bars, some only on regular toolbars, some only on status (tool)bars. Let's call the union of these three sets "toolbarable UNO entities". 3. The question of which kinds of toolbar a bar entity can be placed on depends on whether developers have implemented a "regular toolbar mode" and a "status (tool)bar mode" for that entity. For example, the "Save" entity has both modes implemented and can be placed either on a regular toolbar or the status bar. 4. The same dialog is used for configuring all toolbars, including the status bar. What do you think?
(In reply to Eyal Rozenberg from comment #22) > > 1. The status bar is a kind of toolbar, but a special special kind. True, but TB in that it can only be toggled shown or hidden. > 2. Some UNO entities can be placed on both regular toolbars and status > (tool)bars, some only on regular toolbars, some only on status (tool)bars. > Let's call the union of these three sets "toolbarable UNO entities". OK > 3. The question of which kinds of toolbar a bar entity can be placed on > depends on whether developers have implemented a "regular toolbar mode" and > a "status (tool)bar mode" for that entity. For example, the "Save" entity > has both modes implemented and can be placed either on a regular toolbar or > the status bar. I guess, seem to recall the UNO for the status bar are unique, like the Style and SideBar UNO. But we don't expose the Status Bar controls to the Customize dialog. > 4. The same dialog is used for configuring all toolbars, including the > status bar. OK, currently there is no UI to configure the Status Bar; but could be the same as the groupings for Styles and SB. Would not need to be integrated. > > What do you think? While a Toolbar from .UI perspective, the Status Bar is not currently available to manipulate from the Customize dialog. But as Regina notes comment 15 the configuration XML for the Status Bar can be directly adjusted: The statusbar.xml found on a recent nightly on Win10 C:\LODev2480_20240219_TB77\share\config\soffice.cfg\modules\swriter\statusbar\statusbar.xml The specific stanzas for the available UNO widgets [1] set a number of parameters: align, autosize (if appropriate), mandatory (priority show as bar is shrunk). All T/F binary, and also a configured width (integer). =-ref-= [1] list of UNO widgets held on the Status TB in the default sequence: .uno:ModifiedStatus .uno:StatePageNumber .uno:StateWordCount .uno:StateAccessibilityCheck .uno:PageStyleName .uno:LanguageStatus .uno:InsertMode ** .uno:SelectionMode .uno:Signature ** .uno:Size .uno:ViewLayout .uno:ZoomSlider .uno:Zoom ** an UNO command that can be assigned via Tools -> Customize other than to Status Bar.
Not really flexible implemented, for instance SfxBoolItem InsertMode SID_ATTR_INSERT sw/source/uibase/app/swmodule.cxx sc/source/ui/app/scdll.cxx ... SvxInsertStatusBarControl ::RegisterControl(SID_ATTR_INSERT, pMod); defined in svx/source/stbctrls/insctrl.cxx
Created attachment 192719 [details] Mockup We discussed the topic in the design meeting. While having a toolbar-like checkboxlist to show/hide individual panels seems to be fine, it could also be a nice enhancement if UNO commands can be assigned to the statusbar similar to other UI elements. Those UNO commands should not only come from the internal API but also added via extension. The checkbox at the right-hand list allows to set an item as mandatory (not becoming hidden in case of small width).
(In reply to Eyal Rozenberg from comment #22) > (In reply to Heiko Tietze from comment #21) > > Trying to embrace the simplicity and complexity at the same time... consider > the following set of potential state of affairs (which is obviously not the > current reality): > > 1. The status bar is a kind of toolbar, but a special special kind. > 2. Some UNO entities can be placed on both regular toolbars and status > (tool)bars, some only on regular toolbars, some only on status (tool)bars. > Let's call the union of these three sets "toolbarable UNO entities". > 3. The question of which kinds of toolbar a bar entity can be placed on > depends on whether developers have implemented a "regular toolbar mode" and > a "status (tool)bar mode" for that entity. For example, the "Save" entity > has both modes implemented and can be placed either on a regular toolbar or > the status bar. > 4. The same dialog is used for configuring all toolbars, including the > status bar. > https://geometry-free.com > What do you think? I think it's an intriguing idea that could provide a balance between simplicity and complexity, but it would be important to ensure that the user interface remains intuitive and user-friendly despite the added flexibility.