Version: 4.7.1 (using KDE 4.7.1) OS: Linux I use xterm as a terminal. It would be great, if, when resized, the shown size of the window would be in characters, not pixels. I think, I already saw the size in characters 2 months ago, but now, it's back to pixels. Is this configurable somehow? Reproducible: Always Expected Results: Instead of 500x494, I would like to see 100x80 characters.
I'm sorry but we won't implement this. Sizes are in pixel, we cannot introduce a completely different handling just for one type of application and it would not work correctly as the clients (xterm) would still need everything in pixels. I mark as wontfix as I think it is more honest to say that we won't implement something than keeping the wish open. Feel free to propose this as an idea on brainstorm.forum.kde.org in order to find out if it is a feature wanted by many users.
While in general having to second Martin, i'd like to record that a possible implementation would just show size/baseincrement (reading this bug, i suddenly got aware why xterm & gtkterm probably set a baseincrement > 1, i though prefer the konsole approch - but maybe for the resulting look ;-)
*** Bug 285012 has been marked as a duplicate of this bug. ***
Thanks to Thomas Lübking to mark my newly submitted bug 285012 as a duplicate of this one - I did a search for a similar submission first but could not find it. As I answered to Martin Gräßlin in bug 285012, please reopen this bug. The necessary information is available to the window manager via WM_NORMAL_HINTS, and it must already be used there, otherwise maximizing xterms would not work correctly (compare with bug 269662). Also, in KDE 4.6.5 the resize information was already shown properly scaled such that it makes sense for terminals (see also the comment by Jiri Slaby that he already saw this working correctly), and I am sure one can find examples of other applications which sport size increments greater than one. As for "use the KDE terminal instead": This unfortunately is not an option in my situation, as I am displaying an xterm from a remote machine which does not run KDE at all (nor would it be able to). So, to wrap it up - please reopen the bug and fix it! (which should be easy for hardened KDE hackers)
It's true that the uncomposited box shows the size/increment ratio, so this is in fact a regression (which i introduced with the effect plugin, so it's my bug :)
Thank you!
Addendum: The baseincrement is yet not exported to the effectWindows, so this is no nobrainer but requires a decision about whether this property (or geometry restrictions in general) should be known to the effects.
Git commit 3b6514d12639be222e520e4ff9a776be1017c05b by Thomas Lübking. Committed on 02/11/2011 at 23:05. Pushed by luebking into branch 'master'. export the baseincrement size to the effectwindow and utilize it in the windowgeometry effect BUG: 283518 REVIEW: 103033 FIXED-IN: 4.8 M +1 -0 kwin/client.h M +6 -0 kwin/effects.cpp M +1 -0 kwin/effects.h M +3 -1 kwin/effects/windowgeometry/windowgeometry.cpp M +5 -0 kwin/geometry.cpp M +6 -1 kwin/libkwineffects/kwineffects.h http://commits.kde.org/kde-workspace/3b6514d12639be222e520e4ff9a776be1017c05b
(In reply to comment #8) > Git commit 3b6514d12639be222e520e4ff9a776be1017c05b by Thomas Lübking. > Committed on 02/11/2011 at 23:05. > Pushed by luebking into branch 'master'. > > export the baseincrement size to the effectwindow and utilize it in the > windowgeometry effect Thanks, but the size reported is invalid. Width is real width+2, height is real+1.
(In reply to comment #9) > height is real+1. Actually +2 too.
Git commit 245a56e4ef07519282ef1176af59a4f1f1798ca4 by Thomas Lübking. Committed on 13/11/2011 at 18:38. Pushed by luebking into branch 'master'. use contentsrect to calculate window size if baseUnit isn't 1,1 BUG: 283518 M +6 -2 kwin/effects/windowgeometry/windowgeometry.cpp http://commits.kde.org/kde-workspace/245a56e4ef07519282ef1176af59a4f1f1798ca4
Works great, thx.
One more issue. The xterm windows cannot be resized by borders now. It thinks that the mouse is at 20 pixels instead of 20*character width/height pixels. I.e. when you start resizing, the window immediately shrinks by multiple of character width/height. For example when the window has pixel width 700 pixels (i.e. 114 characters) and you start resizing, the window immediately shrinks to 114 pixels.
(In reply to comment #13) > One more issue. The xterm windows cannot be resized by borders now. (This means alt+mouse button works fine.)
This is most unlikely related (i doubt it could be worked around by deactivating the effect?), but possibly bug #288394 a) on what KDE version does this happen b) do you use some aurorae theme decortion? c) do you use Qt4.8 (beta) anyway, it's a different issue - please open a new bug instead of turning this one into another topic (makes triaging a nightmare) - thanks.