Bug 180012

Created attachment 30023 [details]
Proposed fix

Patch that sets the resize increment hint to the font size on font changes.

Thank-you for the patch.

> That behaviour is different to _every_ other terminal emulator
> program I know. 
> ... - again, unlike any other terminal emulator :-( 

I do not generally consider "everybody else does it like this" to be a good argument for making/not making any change on its own - although I appreciate the benefits of consistency.  The sheep mentality irritates me.  The legitimate issues with Compiz are much more interesting.

> The lack of that information, besides not allowing proper constraining
> of the window size by the WM, has a bad side effect on compiz for me:
> in a resize mode that does not immediately resize the window

With a WM which resizes immediately, Konsole can display the current size of the window in lines and columns as the size changes for those who wish to know.  Even with your patch I'm sure the on-screen display would be a lot easier to work with than resizing the window bit-by-bit.  Doesn't Compiz have an option to do non-incremental resizing?

(In reply to comment #2)
> Thank-you for the patch.
> 
> > That behaviour is different to _every_ other terminal emulator
> > program I know. 
> > ... - again, unlike any other terminal emulator :-( 
> 
> I do not generally consider "everybody else does it like this" to be a good
> argument for making/not making any change on its own - although I appreciate
> the benefits of consistency.  The sheep mentality irritates me.  The legitimate
> issues with Compiz are much more interesting.

Yes, but the other terminal emulators definitely have reasons for doing so ;)

> > The lack of that information, besides not allowing proper constraining
> > of the window size by the WM, has a bad side effect on compiz for me:
> > in a resize mode that does not immediately resize the window
> 
> With a WM which resizes immediately, Konsole can display the current size of
> the window in lines and columns as the size changes for those who wish to know.
>  Even with your patch I'm sure the on-screen display would be a lot easier to
> work with than resizing the window bit-by-bit.  Doesn't Compiz have an option
> to do non-incremental resizing?
> 
It does, but resizing tends to be pretty slow in composited environments due to the needed texture copy operations, which is the whole reason for non-immediate resizing to exist. I also could enable immediate resize for konsole and use non-immediate for all other windows, but I'd prefer using non-immediate for all windows.

Please note that I didn't have the chance to actually _test_ this patch so far because I failed at compiling KDE so far. I think I got a compile environment set up now, so I will test if the patch is complete already (I think for it to be really meaningful the base size must be set to (size of scrollbar + size of menu bar + size of tab bar) as well. I will report back as soon as I have a confirmed patch.
I just wanted to know if konsole on purpose doesn't set the resize increment hints, which doesn't seem to be the case judging from your answer.

> I just wanted to know if konsole on purpose doesn't set the
> resize increment hints, which doesn't seem to be the case judging
> from your answer. 

That is indeed the case - there hasn't been any explicit discussion about resize hints.  The majority of my users are using KWin as their WM which probably explains why this hasn't come up before.

Furtherly looking at what konsole can do, I dont think resize increment hints can be sensibly set on konsole windows at all. Especially the function of having multiple VTs with different font sizes in a single window makes it impossible to set a proper resize increment. Thus I'm closing this bug report myself and am using immediate resizing for konsole windows from now on ;)