When maximizing xfce4-terminal using Kwin there is a padding mostly at the top and the bottom and 1px at the sides I think. Similar report https://bugs.launchpad.net/ubuntu/+source/kde-workspace/+bug/1300841 Reproducible: Always
please provide both xprop and xwininfo output on the xfce4-terminal window.
Created attachment 88709 [details] xprop of maximized xfce4-terminal window
Created attachment 88710 [details] xwininfo of maximized xfce4-terminal window
make a rule (special window setting) to disobey geometry restrictions for this window. *** This bug has been marked as a duplicate of bug 265568 ***
I don't understand... is it a bug in xfce4-terminal then? Should I report it there? Thanks.
(In reply to Philip P. from comment #5) > I don't understand... is it a bug in xfce4-terminal then? Should I report > it there? no, it's neither a bug in xfce4-terminal, nor in KWin. It's behaving exactly as expected (I expected this, just asked for the output to confirm my expectation). The window is requesting a base size and a resize increment. According to ICCCM section 4.1.2.3 a window manager is supposed to calculate the geometry as: width = base_width + (i * width_inc) In the case of the output you provided it is: width = 18 + (i *9) so with i == 140, you get 1278 = 18 + (140 * 9) Given the restrictions the window requests, it's not possible to e.g. maximize it. AFAIU the idea is to have the window always in a multiply of the monospace font size used in terminal applications.
Thanks martin I kind of understand. However, how is it that other window managers accomplish this task? Do they stretch the content? Also konsole has monospaced fonts, too... why isn't it happening there?
> However, how is it that other window managers accomplish this task? Do they > stretch the content? they probably ignore it, but that can result in problems. I remember that gnome-terminal used to shrink due to KWin setting a size, gnome-terminal updating, KWin setting a new size and so on. In the end that's how ICCCM suggests to do it. It's not mandatory, just "preferred", but well, if the client asks for it, we honor it. > Also konsole has monospaced fonts, too... why isn't it happening there? konsole is not requesting a size increment: WM_CLASS(STRING) = "konsole", "konsole" WM_PROTOCOLS(ATOM): protocols WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_PING, _NET_WM_SYNC_REQUEST WM_NORMAL_HINTS(WM_SIZE_HINTS): user specified size: 579 by 696 program specified minimum size: 139 by 64 window gravity: Static
> In the end that's how ICCCM suggests to do it. It's not mandatory, just "preferred", but well, if the client asks for it, we honor it. Yes there I aggree, so it's acutally "bad design" by xfce4-terminal authors. So what they actually would need to do is keep that value while normal resizing, but ignore the size increment for maximize. I'm not a programmer, but I guess this would only be possible if the "Maximize" function is a seperate request than a "resize". If "Maximize" relies on "resizing to a certain value" this might be a problem. Again I'm not a coder... am I correct in my assumptions? Thanks in advance!
Or it could acutally ignore the size increment when the desktop resolution is reached, couldn't it?
On Monday 15 September 2014 17:02:27 you wrote: > https://bugs.kde.org/show_bug.cgi?id=339096 > > --- Comment #9 from Philip P. <nucrap@hotmail.de> --- > > > In the end that's how ICCCM suggests to do it. It's not mandatory, just > > "preferred", but well, if the client asks for it, we honor it. > Yes there I aggree, so it's acutally "bad design" by xfce4-terminal authors. > So what they actually would need to do is keep that value while normal > resizing, but ignore the size increment for maximize. > > I'm not a programmer, but I guess this would only be possible if the > "Maximize" function is a seperate request than a "resize". If "Maximize" > relies on "resizing to a certain value" this might be a problem. maximize is a state which the window is informed about. So, yes: the terminal could remove the restriction if maximized is requested.
>maximize is a state which the window is informed about. So, yes: the terminal could remove the restriction if maximized is requested. Thanks Martin, I will file a bug report about it to the xfce4 butracker then.
To put some more background into this: the gtk+ terminal class as well as xterm "abuse" the increment values of WM_NORMAL_HINTS because the ICCCM suggests "Window managers are encouraged to use i and j instead of width and height in reporting window sizes to users." Iow, they want the WM to display the window size in characters, rather than pixels. Konsole does not make use of this, but (optionally) displays the terminal size internally, because the currently used WM may be not available (ie. doesn't show window sizes at all or always shows them in pixels) or the user does not want the WM to show window sizes (on geometry changes) for each and every window. So basically the geometry restriction is there for purely visual reasons (plus, actually the maximized window cannot really make use of the additional space) Otoh, there are windows like video players, image displayers etc. that make use of those restrictions for good reasons - you'll find that a WM which stretches your terminal to arbitrary sizes on maximization will do the same w/ eg. mplayer and friends, which in return will get you a squeezed image. The default behavior in KWin was altered at least twice in the past - atm. we honor by default and require a rule to do not (rather than requiring a rule on mplayer to honor its demands) @Martin Since the terminal classes care about the base inc while visual representation rather cares about the aspect ratio, we could *possibly* reverse the default for the former but keep it for the latter by adding a second rule check before the "xSizeHint.flags & PAspect" branch of ::sizeForClientSize() and move the present one into that branch. This way the base_inc based calculation would be killed (or we'd rather omit it in the first place ;-) by default but the paspect one be preserved by default. emacs'/gvims "i can resize myself" attempts are to be defeated by a rule to ignore the clients size requests (and protected during maximization anyway), so this has no impact in this context.
> @Martin > Since the terminal classes care about the base inc while visual > representation rather cares about the aspect ratio, we could *possibly* > reverse the default for the former but keep it for the latter by adding a > second rule check before the "xSizeHint.flags & PAspect" branch of > ::sizeForClientSize() and move the present one into that branch. This way > the base_inc based calculation would be killed (or we'd rather omit it in > the first place ;-) by default but the paspect one be preserved by default. I don't think that this is enough of a use case for adding a special branch in KWin core. But we could include a kwin rule by default.
Hi again, it appears that I have found a "real" issue now, being tightly conncected to this one: When I maximize the Window using the "Maximize"-Button and then try to unmaximize it by dragging the window bar, the window doesn't shrink and simply gets moved. As a result also the edges + glow are cut out (since a maximized window doesn't have this stuff) and consequently it's also not possible to resize the window by dragging the edges - the window is still maximized in the end, just shifted. Strangely this *does not* happen when I maximize the window by dragging it to the top. So to my understanding this is now indeed a KWin bug, although obviously caused by a sloppy xfce4-terminal design. If needed, I can create a new bugreport for this.
More a decision than a bug. "Quick maximization" isn't considered the same as "maximization" and only implicitly aligned if the window is maxmized touching the upper screen border because it's this edge that triggers the "quick" state change. Second part is that non-arbitrarily sized maximized windows are centered on the screen. Proof on all this: explicitly "quick maximize" the window - it should unmaximize as expected when moving it away from the screen edge.
Sorry, but even though this all this sounds technically resonable this is still a bug. The user in the end doesn't care for this but just wants his system to work properly. What I see is that maximize and "quick maximize" does the same. Consequently they should act the same. So this is actually no excuse at all. Sometimes it is important to "think" from *users* perspective and not always from the developers view - the VDG is a good example for this.
There's a difference between "bug" and "behavior you don't like" The behavior is no accident but intended. > What I see is that maximize and "quick maximize" does the same. > Consequently they should act the same. Actually I tend to agree here, but since I do not even use this feature, am not qualified to reason on the topic. All I can say is that they exist as independent modes in the code.
>There's a difference between "bug" and "behavior you don't like" >The behavior is no accident but intended. I don't know maybe I wasn't clear actual bug, to sum it up: The problem is that after unmaximizing by drag the window *lacks a proper border*, making it impossible to resize. Also the window doesn't get unminized at all but simply "shifted", so after clicking on the maximize button again, the window doesn't maximize but unmaximizes. Also the bug only happens to to Application requesting "size increment" (e.g. xfce4-terminal)... on "normal" applications it doesn't matter by which "function" the window gets (un)maximized. So at the least, the is a clear an inconsistancy. I can't believe this is a desired behaviour.
> The problem is that after unmaximizing by drag the window *lacks a proper > border*, making it impossible to resize. Also the window doesn't get unminized > at all but simply "shifted" Yes, you're really just repositioning a (still) maximized window because the quick un/maximization logics do not apply in this case. The window does not get unmaximized for altering the position, the deco doesn't add back borders. If you switch off quick maximization, moving any maximized window will act the same.
>Yes, you're really just repositioning a (still) maximized window because the quick un/maximization logics do not apply in this case. Nice, so finally we are of one mind. I hope this gets fixed.
>Yes, you're really just repositioning a (still) maximized window because the quick un/maximization logics do not apply in this case. Could you explain to me why the logics apply to all standard apps, but not for programs requesting resize increment?
(In reply to Philip P. from comment #22) > Could you explain to me why the logics apply to all standard apps, but not > for programs requesting resize increment? That's not the crucial part - quick maximization only applies if the window touches the top edge, geompetry.cpp:~2390 (line won't be 100% correct) if (options->electricBorderMaximize() && r.top() == clientArea.top()) ^^^^^^^^^^^^^^^^^^^^^^^ quick_tile_mode = QuickTileMaximize; Reasoning will be that the quick maximization feature is toggled by that edge (while i have to admit that i personally am not very fond of "moving a window implicitly alters its states/size" altogether) Options: 1) keep it this way 2) top align size restricted windows 3) completely merge QuickTileMaximize and MaximizeFull @Martin I'd probably like 3 best and 2 least, but don't know why theere's a difference in the first place.
Yes I'm also very interested in the technical reasoning behind spliting those two features, considering that they do exactly the same and both have the exact same "end-state".
#1 (just tried ;-) Maximized cinemascope mplayer, and moved the (initially centered) window to the bottom to keep a terminal above for interaction while watching the video. -> It would really suck if it automatically unmaximized (which is not relevant for windows which cover all screen)
On Friday 19 September 2014 15:19:07 you wrote: > @Martin > I'd probably like 3 best and 2 least, but don't know why theere's a > difference in the first place. Refactoring this code base is somewhere on my todo list ;-) I consider it a little bit too complex (I noticed that when working on kdecoration2)