Bug 402904

Summary: The status bar imposes a limit on the minimum width of the window
Product: [Applications] kate Reporter: zeta <franciscodezuviria>
Component: kwriteAssignee: KWrite Developers <kwrite-bugs-null>
Status: RESOLVED FIXED    
Severity: wishlist CC: loh.tar
Priority: NOR    
Version: 18.08.0   
Target Milestone: ---   
Platform: Other   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description zeta 2019-01-05 21:24:04 UTC 
SUMMARY
Let's say that I want a really small (20 chars width) instance of kwrite for note taking (to achieve a small 'always on top' sticky note) - it cannot be done unless the status bar is hidden.

STEPS TO REPRODUCE
1. Open Kwrite
2. Make sure status bar is showing
3. Shrink horizontally as much as possible

OBSERVED RESULT
The status bar imposes a limit on the minimum width of the window.

EXPECTED RESULT
Any of the following (from easy to hard):
 A: Status bar should get cut
 B: Status bar should get shrinked
 C: Status bar should be scrollable

I think 'B' is the current behaviour in Kate, but not sure since I'm on an old version.

ADDITIONAL INFORMATION

This was discussed in https://phabricator.kde.org/D17730 where the status bar was reworked for Kate (note: this is a Kwrite bug). It was concluded that the length issue was out of scope and better handled separately.

This same bug was treated and fixed for gwenview and kst in 2003 and 2005 (https://bugs.kde.org/show_bug.cgi?id=69885 and https://bugs.kde.org/show_bug.cgi?id=104347). I don't use those and maybe this is completely irrelevant, but maybe there is some useful code to reuse? Who knows?
Comment 1 Dominik Haumann 2019-01-08 19:10:29 UTC 
The correct approach to this is in my opinion to hide information in the statusbar that is less relevant.

Example: If the statusbar shrinks, it should first hide e.g. amount of lines, then amount of words, then highlighting, etc...

The correct solution to this approach would be to have a dedicated layout, let's call it StatusBarLayout, derived from QLayout. Indeed, we are not the first ones having this problem, as such a solution to this problem exists:
https://github.com/KDE/okteta/blob/master/libs/kasten/gui/shell/statusbarlayout.h

Unfortunately, this solution simply hides the last N widgets that do not fit. This is not exactly what I wrote above, but maybe that would already solve the problem nicely.

A very sophisticated solution would be a StatusBarLayout that tells its widgets to use a "compact notation" if possible. "Line 1, column 1" could then turn into "L1, C1" or so, making room for other widgets.

In addition, the StatusBarLayout could have a function addWidget(Widget *, int priority), where lower priority values would indicate that these widgets should be hidden first (or put into compact notation).

Thoughts on this? Volunteers? The StatusBarLayout above is LGPLv2+, so compatible with what we would need. It could act as base.
Comment 2 Dominik Haumann 2019-01-08 19:14:16 UTC 
Btw, there are also other issues about the status bar:
- https://bugs.kde.org/show_bug.cgi?id=362036
- https://bugs.kde.org/show_bug.cgi?id=368296
- https://bugs.kde.org/show_bug.cgi?id=402706

Maybe it's worth to have a look at this as well to take possible other issues into account.
Comment 3 Lothar 2019-01-09 15:46:27 UTC 
I recently notice that Kate/KWrite has some similar functionality at the (main) toolbar. There is then an extra button shown to expand the toolbar temporary.

The solution I had in mind is to add "not shown buttons" to the context menu of the status bar.

@Dominik, The mentioned latter two bug reports are already on my radar screen ;-)
Comment 4 Lothar 2019-03-06 05:47:46 UTC 
I'm so free to close this
https://phabricator.kde.org/D17730#389468