In the statusbar of Writer and Calc, we have a field for the current insert mode, which is blank by default and has the text 'Overwrite' when in insert mode. With visual notification of being in insert mode is already present by the cursor being different, i believe this field can be removed.
Hi Jay ah well, you noticed that there is a request to add CAPS state to the status bar ;) Does the cursor state change on all platforms? I see it does on Linux/Ubuntu.
Hi Cor, (In reply to Cor Nouws from comment #1) > ah well, you noticed that there is a request to add CAPS state to the status > bar ;) I had been meaning to suggest this when i suggested bug 82707 and bug 82708, but never got around to doing it :) > Does the cursor state change on all platforms? I see it does on Linux/Ubuntu. Yes it changes in Windows as well. Spoke to mac user and he stated they dont have an insert button on their keyboards, so this functionality isnt native to mac.
@Jay, *, The Insert "field" on status bar, or more correctly the "Edit mode", is a bimodal toggle. By default Writer opens in Insert mode, to toggle to Overwrite mode the keyboard <Insert> key is used on Linux/Windows, have to check but on an Apple keyboard that should be <Fn>+m, or <Help> key. The status enables one to identify the mode their edit session is set to. So, would instead suggest that the edit mode be retained on status bar, but that either mode should show. Either in Insert & Overwrite mode, but maybe rather than lables--might be done with icons? The translatable tooltip work of bug 82708 covers function nicely. Regards bug 88296, as Caps Lock also is modal, there should be an indicator on the status bar--just that we don't presently control it from within LO.
(In reply to V Stuart Foote from comment #3) > The status enables one to identify the mode their edit session is set to. If it were the only way to identify the mode, there would be a benefit having it, but when a user is in overwrite mode, the cursor changes from a thin line cursor, to a cursor that covers the letter going to be overwritten and inverts the font color. This field in the statusbar is something that i believe was simply taken from MS Office's older UI (pre-2007) and wasnt really thought through for how useful it truly is, which is why i believe it was gotten rid of in MS Office's new UI statusbar.
Yes, I see that. But again it is functional to have the indicator of status on the status bar. Additionally, since it behaves the same for all OS--left mouse click on its active area of the bar (so guess that makes it a button?) and gives tool-tip notice)--it makes the UI consistent across OS. Leave it there, doing so serves a purpose--removing it does not.
(In reply to V Stuart Foote from comment #5) > Yes, I see that. But again it is functional to have the indicator of status > on the status bar. As i had stated in bug 88296, should we also consider adding a NumLock indicator as well. I would say no as a user eyes are at the location of the cursor and if he/she is in overwrite mode, the cursor is different, if he/she is in capslock mode, letters pressed are in capitals, and when numlock is off, numbers dont appear when pressing the number keys. This is the same behaviour a user would see when they are in another other application that allows text input and most applications dont provide statusbar indication for these various states. > Leave it there, doing so serves a purpose--removing it does not. Removing it does serve a purpose, reducing the clutter in the statusbar, which does improve the statusbar on smaller resolutions (bug 86018). The statusbar has 12 sections in it, many of which most users would never utilize, and it is useful to get rid of highly unused features.
I think the status bar is designed to show clutter ;) We cannot always serve small displays. I think.
@Jay, Yes adding a Numlock, Caps Lock indicator are both useful statusbar additions. As is retaining the Insert/Overwrite mode indicator. Samuel's patches allowing deeper shrinkage of the status bar element labels resolved issues of bug 86018. Frankly concern about "clutter" on the statusbar is trivial. In fact, there are very few users attempting to do anything with LO on monitors less than 1024x768, and I can't remember the last time I came across an 800x600 resolution laptop or desktop display. The minimum now is probably around 1366x768 found on older laptops with outdated screens. We aren't dealing with Android/iOS based devices--running LO in a minimum screen width should not be a primary design consideration going forward to 4.5.0 Full HD resolution 1920x1080 (16:9) or 1920:1200 (16:10) monitors are the norm, with 4K and Retina HiDPI displays becoming more common, so the "clutter" you suggest of the status bar is simply not an issue for majority of users. Yet removing functions that reside appropriately on the statusbar would be. Our biggest problem with the Statusbar is that we have translatable fielded names rather than functional icons. The by language the named fields expand or shirnk to fill the statusbar. Are some less useful than others? Sure. But the space is there, and we are not considering removal or default suppression of the statusbar. The statusbar takes up screen space, so it should be populated with functional elements. That said, there are two GUI issue here: one is the resizable labeling (and requisite translation). Some additional icons with consistent placement and behavior solves most of that. Might not be able to do it for all, but certainly--Page, words, characters. The other "clutter" as you put it, comes from lack of customization of the status bar. For users working in reduced size VM, or with multiple instances of LO open, the Status bar could be made configurable allowing selection of the status indicator widgets that are rendered active. Do that as opposed to ripping them out of the statusbar. Leave the Insert/Overwrite indicator alone, it has a function--fix the GUI.
(In reply to Cor Nouws from comment #7) > I think the status bar is designed to show clutter ;) We seem to be continuously adding clutter to it. :D > We cannot always serve small displays. I think. Working on smaller screen was an added advantage, but not primary one. (In reply to V Stuart Foote from comment #8) > Yes adding a Numlock, Caps Lock indicator are both useful statusbar > additions. As is retaining the Insert/Overwrite mode indicator. I guess we will have to agree to disagree on this one. ;D > Samuel's patches allowing deeper shrinkage of the status bar element labels > resolved issues of bug 86018. Frankly concern about "clutter" on the > statusbar is trivial. In fact, there are very few users attempting to do > anything with LO on monitors less than 1024x768, and I can't remember the > last time I came across an 800x600 resolution laptop or desktop display. The > minimum now is probably around 1366x768 found on older laptops with outdated > screens. We aren't dealing with Android/iOS based devices--running LO in a > minimum screen width should not be a primary design consideration going > forward to 4.5.0 I am aware of the various screen resolutions used by users, as i had to take those into consideration when i redid the toolbars and tried my best to keep it under 1024px width, though it has slipped over in calc and impress. > Full HD resolution 1920x1080 (16:9) or 1920:1200 (16:10) monitors are the > norm, with 4K and Retina HiDPI displays becoming more common, so the > "clutter" you suggest of the status bar is simply not an issue for majority > of users. Yet removing functions that reside appropriately on the statusbar > would be. Users with large screen like to compare documents side by side, which results in each window being 960 pixels in width on a 1920x1080 display and the reason i noticed and filed bug 86018 (though this problem still effects other modules - bug 86612). "Clutter" is clutter at whatever resolution a user is at when they have things in the statusbar that has no benefit to them. > Our biggest problem with the Statusbar is that we have translatable fielded > names rather than functional icons. The by language the named fields expand > or shirnk to fill the statusbar. Are some less useful than others? Sure. > But the space is there, and we are not considering removal or default > suppression of the statusbar. The statusbar takes up screen space, so it > should be populated with functional elements. I would say the biggest problem with the statusbar is that it is not configurable, so we can have a simple default statusbar to fit most users needs and users who want more fields in it can enable them. We have an icon in the statusbar to identify whether the document was modified since the last save. For what reason is this useful when the save button in the toolbar tells us the exact same thing. > That said, there are two GUI issue here: one is the resizable labeling (and > requisite translation). Some additional icons with consistent placement and > behavior solves most of that. Might not be able to do it for all, but > certainly--Page, words, characters. I think text is preferable over icons, as the icons would be small users would have to rely on tooltips to understand it. (may not have understood what you meant here :D) > The other "clutter" as you put it, comes from lack of customization of the > status bar. For users working in reduced size VM, or with multiple instances > of LO open, the Status bar could be made configurable allowing selection of > the status indicator widgets that are rendered active. I'd assume most of the statusbar would need to be customizable. > Do that as opposed to ripping them out of the statusbar. Leave the > Insert/Overwrite indicator alone, it has a function--fix the GUI. With the statusbar customizable, the Insert/Overwrite indicator maybe useful to some people, so in that scenario there wouldnt be a need to rip out the code that makes it function, as it would be hide-able.
my cents: I agree opposing clutter. I know this is unpopular with FOSS devs as they tend to wanting to serve every corner case. Moving this into a bigger perspective: atm, LO opens with top menu bars and the sidebar. I still feel the sidebar is rather disorganized and stated my reasoning while we were discussing Jay's mockups to clean that up. So while LO provides great features and options, it is really overwhelming to new users and users who "just want to write a letter". PROBLEM: The difficulty of course is finding a balance between offering a minimal feature set to standard users while not cutting functionality for expert users. The above problem is, why a simple icon addition as discussed here, causes those passionate principal discussions. Those are important. I somewhat believe we should have them in the call. But yesterday couldn't find the time to participate. In an ideal world the user would either use the sidebar or the top menu. OR Both would be used, but then having a lot of duplicate functionality is somewhat questionable. I have no easy solution to those problems, but wanted to chime in on this. Sorry it got longer than intended. About OSX: Caps locked: the caps button has an LED and if you press it, you see a yellow dot, thus no UI indicator in LO is needed especially not in the top menu bar which should be reserved for much more important functionality than this corner case. Remove vs replace: I stick to the default and never overwrite. There is indeed a fn key where the insert key is on windows keyboards (above the Remove key). Not sure what it does :( Summarizing, I agree with this request.
> About OSX: > > Caps locked: the caps button has an LED and if you press it, you see a > yellow dot, thus no UI indicator in LO is needed especially not in the top > menu bar which should be reserved for much more important functionality than > this corner case. It's not only OS X we are talking about :) Maybe a CAPS LOCK indicator can be made into an extension?
I’m siding with Stuart here. There is no benefit in removing the status bar indicator for Overwrite Mode and relying only in the changed cursor appearance, which is not obvious in the slightest.