Created attachment 3645 patch to fix debian bug 624475 In the xfwm4-4.8.1 package that is currently in Debian unstable, doubleclicking with the left mouse button on the edge of a shaded window corrupts the window's height and can also move the window's title bar. When the window is unshaded, the window height is not correctly restored, leading to windows with greatly reduced height -- sometimes, zero height. The attached patch takes one approach to fixing the problem by interpreting a button-1 or button-3 edge doubleclick as an unshade request when the window is shaded. regards, Paul
This is still an issue in 4.11.1, and has literally been the one thing stopping me from using Xfwm for about 4 years now. Is anyone going to ever apply this patch or fix it in a different way?
(In reply to Matthew Caron from comment #1) > This is still an issue in 4.11.1, and has literally been the one thing > stopping me from using Xfwm for about 4 years now. Is anyone going to ever > apply this patch or fix it in a different way? 4.11.1 is long dead and I hope nobody in their right mind is using a development snapshot from 2 or so years ago on any of their system. That been said, it's probably not fixed. Truth is I completely overlooked this bug/patch. Although I am not entirely sure what "corrupts the window's height and can also move the window's title bar" really mean. Double clicking on an edge will invoke "filling", ie expand the window until it reaches other windows. It works the same with shaded windows, it will indeed move and resize the window, not really a corruption, just expected behavior. I am not sure if it should unshade (as the patch does) or simply do nothing when shaded. Oh, and at last, I honestly find it weird that such a corner case would prevent you from using xfwm4...
(In reply to Olivier Fourdan from comment #2) > (In reply to Matthew Caron from comment #1) > > This is still an issue in 4.11.1, and has literally been the one thing > > stopping me from using Xfwm for about 4 years now. Is anyone going to ever > > apply this patch or fix it in a different way? > > 4.11.1 is long dead and I hope nobody in their right mind is using a > development snapshot from 2 or so years ago on any of their system. Xubuntu 14.04 LTS. (mattc@E2-06L) ~$ apt-cache show xfwm4 | grep Version Version: 4.11.1-2ubuntu2 If you say it may be fixed in 4.12, I'd be happy to use the backport PPA and give it a go. > That been said, it's probably not fixed. Truth is I completely overlooked > this bug/patch. That's fair, it happens. I think I first noticed it in 4.8 as well, though I am not certain. > Although I am not entirely sure what "corrupts the window's height and can > also move the window's title bar" really mean. I'll try to describe it, but if I fail to do so, I can easily replicate it and will furnish a series of screenshots. > Double clicking on an edge > will invoke "filling", ie expand the window until it reaches other windows. Ah, that's the key. If I can disable this behavior (I've never known about it, so it's no loss for me) then it would be a good workaround. Anyway, when it's shaded, it does this and hits the top of the next window. So, for example, when unshaded, I have two overlapping windows, with Window 1 offset vertically by approximately the height of the title bar. I shade Window 1 and get something like this, right? [Window 1] |Window 2| | | |________| Now, if I double click Window 1's bar, it unshades correctly, overlapping Window 2. If, however, I misclick, and get the double click the bottom of Window 1's bar (actually the bottom border, but you can't tell), it tries to fill the vertical space between its bottom and the top of Window 2 - which is maybe 5 pixels. > It works the same with shaded windows, it will indeed move and resize the > window, not really a corruption, just expected behavior. Expected behavior that totally breaks the value of windowshading, because if you double click the wrong spot, you now need to manually resize your window and put it back where it was. This is further compounded by the fact that, with most themes, the window border and title bar are all the same color, so you can't tell which of the clickable region is the border and which is the title bar. I also tend to use really thin window themes, which further exacerbates the issue. > I am not sure if it should unshade (as the patch does) or simply do nothing > when shaded. Either is preferable, but I have another possible solution - don't have any of the window borders visible. So, if I have a shaded window, there is ONLY the title bar. The borders are all hidden, which means that no window resizing is allowable until unshaded, which also means that no accidents can happen. > Oh, and at last, I honestly find it weird that such a corner case would > prevent you from using xfwm4... Your corner case happened to me 5 times today alone, and that was after I realized what was causing it and was trying to be careful - before it would happen several times per hour. This is tremendously disruptive when trying to focus on development, because now I need to derail my train of thought to rearrange the window that has now jumped across the screen and gotten it's geometry all changed around. I simply cannot afford to be that unproductive. Hence IceWM (which has its own problems, namely it misbehaves with some Qt5 apps).
-- GitLab Migration Automatic Message -- This bug has been migrated to xfce.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.xfce.org/xfce/xfwm4/-/issues/56. Please create an account or use an existing account on one of our supported OAuth providers. If you want to fork to submit patches and merge requests please continue reading here: https://docs.xfce.org/contribute/dev/git/start#gitlab_forks_and_merge_requests Also feel free to reach out to us on the mailing list https://mail.xfce.org/mailman/listinfo/xfce4-dev