Increase invisible area for grabbing window border for resizing by mouse

[archont00]

Would it be possible to increase the invisible border around windows (marco, no compositing) to make window resizing easier for users on high dpi screens? Enlarging the visible border is not an optimal solution.
The issue is well discussed e.g. here: https://bugs.launchpad.net/metacity/+bug/160311 and it seems resolved in Ubuntu (Unity).

I am not sure if this can be done for GTK2, but at least I would welcome the feature in GTK3 and preferably without need of compositing manager (any hw accellerated window management works very bad for remote desktops).

I am aware about the workarounds (alt + right-mouse-click OR alt + F8).

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[raveit65]

+1

[muktupavels]

You can not have invisible area for borders without compositing manager...

In X world we have InputOnly windows - they are invisible (with or without compositing manager), but it is not possible to reparent InputOutput window in InputOnly window.

[fbarriga]

There is an easy workaround but this increases the window border size:
https://bugs.launchpad.net/metacity/+bug/160311/comments/11

[raveit65]

Already done for our default themes ((Blue)-Menta themes).
https://github.com/mate-desktop/mate-themes/blob/master/desktop-themes/BlueMenta/metacity-1/metacity-theme-2.xml#L25

[ghost]

So are there any changes to a compositing backend?

This is the single major difference that makes Gnome 3 a lot less hassle to use, even despite all its other shortcomings (JavaScript bloat, lack of settings, ...). It would mean a lot of this could be somehow made to work.

Forgive me, but I don't know much about X11: but if you can simply render a larger border in the theme, couldn't you somehow also render an invisible border? X11 supports windows with 1bit alpha transparent areas I assume? (since Windows XP could already do that)

[sc0w]

This feature works with mate desktop + compiz

[rdiez]

I just upgraded to Ubuntu 20.04.1, which sports MATE Desktop 1.24, and I would like some clarification about this fix.

I normally disable the compositing window manager, because I want a lean, fast, stable desktop environment, instead of fancy 3D effects that tend to trigger obscure graphics driver bugs. On the MATE Desktop, I go to "Control Center", Group "Look and Feel", then I open "Windows", "General", and disable "Enable software compositing window manager". Also open "MATE Tweak", "Windows", and change the "Window manager" to "Marco (no compositor)".

However, with those settings, the fix for this bug does not work.

What is this "software compositing" setting? Does it have any effect?

This fix is only implemented in mode "Marco (Adaptive compositor)", right? How about the other 2 modes, "Compton" and "Compiz"?

Is this fixed tied to the window shadows? By the way, can you disable those window shadows somehow?

[lukefromdc]

A shadow area around windows is only possible with a compositor as otherwise the entire rectangle containing the shadows around the window renders black. You can remove all shadows in the GTK theme, though if you do this you will find that in many themes, CSD windows rely on shadows as their only borders and thus can become indistinguishable from oneanother if the window contents are the same color (e.g white for CSD text editors such as gedit)

[rdiez]

First of all, thanks for you quick answer.

However, most of my questions above remain unanswered. I do not quite understand what you wrote either. Let me try to clarify at least your answer below.

1. "You can remove all shadows in the GTK theme"

I guess you mean manually editing some esoteric files, right? Or is there a way to easily disable shadows with some GUI configuration setting?

2. "CSD windows rely on shadows"

I wonder how that can be true. I normally run with "Marco (no compositor)", which displays no shadows. I never noticed any problems with any application with regards to its borders.

I just installed gedit to test your claim, and it does show a normal border without a compositor.

I then switched momentarily to "Marco (Adaptive compositor)", and the window border is still there, the shadows are only an extra. That is also true with gedit.

[lukefromdc]

That depends entirely on the theme. Some themes (notably some versions of Adwaita) rely only on the shadows for CDS borders, but this is entirely under the control of the theme author.

Shadows are set in the css files used by a theme. You can override anything in any of these by creating or editing ~/config/gtk-3.0/gtk.css
the test code to temporarily disable ALL shadows (remove this code after testing) would be:

* {
    box-shadow: none;
}

You will then find that on many themes, with a text file in gedit that does not create a right side scrollbar the white background is not distinguishable from a white background in another window.

Also note that many themes automatically distingush CSD windows when compositing is NOT being used by the .solid-csd style class, and draw borders what would not be used in a composited window.

Been a while since I've worked on all this due to the utter mess in my country though...

[rdiez]

Thanks for the information about disabling shadows. Manually editing CSS files is not for the standard user, so I guess the answer to my question "is there a way to easily disable shadows with some GUI configuration setting" is actually "no". I consider this a weakness in MATE (and in most other environments), but that does not bother me much.

I guess a theme can decide that it does not want to have any shadows. Is the new feature described in this issue, namely "Increase invisible area for grabbing window border for resizing by mouse", tied to the presence and size of the shadows?

In case any "speed readers" are eager to close this bug, this is just a reminder that the other questions I wrote in the following previous comment remained unanswered: Previous comment

[lukefromdc]

Invisible borders are added to the frame geometry, the original commit hardcodes them to 10px rather than relying on the shadows which expand the underlying window to accomodate them. I would assume these invisible borders force a minimum size to the composited window even if shadows are not drawn by a theme. To enlarge them for hidpi should just require multiplying that hardcoded value of 10 by the window-scaling factor

[rdiez]

Thanks for the information. If I understand it correctly:

1. The "resizing border" is invisible and has nothing to do with the theme shadows. This is actually as expected.

2. The original commit with the hardcoded 10px is in fact still the current state. That means there is no support for hidpi in the invisible resizing border, which will make it hard to resize windows in very high-resolution displays.

In case any "speed readers" are eager to close this bug, this is just a reminder that the other questions I wrote in the following previous comment about the different compositor settings remained unanswered: Previous comment

[JorgeStolfi]

This "improvement" makes no sense. If there is a 10 px wide region around a window where clicks go to that window, it is useless and very misleading to show the underlying stuff in that region. I keep clicking on the invisible border when I am trying to click on some underlying button or title bar.

Users who need an extra-wide resize border should just configure their windows manager to have an extra-wide VISIBLE window frame. It will not really waste more screen space, because the underlying stuff cannot be clicked on anyway.

This solution would also let users choose the width of the resize border. Many users do not need any extra width. For many others, 1-2 extra pixels may be enough. For most users, 10px is too much: it is no more helpful than 2px, but a lot more annoying.

On a more general level: whenever such an "improvement" is made to a widely-used user interface, an easy way for users to disable it should also be provided.

[raveit65]

Disable compositor = no invisible borders

[rdiez]

This "improvement" makes no sense. If there is a 10 px wide region around a window where clicks go to that window, it is useless and very misleading to show the underlying stuff in that region. I keep clicking on the invisible border when I am trying to click on some underlying button or title bar.

You are right, of course. An invisible area around a window is a bad idea indeed.

Users who need an extra-wide resize border should just configure their windows manager to have an extra-wide VISIBLE window frame.

Well, that is the trouble, there is no easy way to achieve that. The inability to comfortably resize windows is a serious usability issue, and the MATE Desktop is lacking in this respect. I have written detailed notes about this.

I myself have got used to the Alt+Mouse resizing method, but that does not work well when using remote desktop clients like Remmina or libvirt's Virtual Machine Manager (with the SPICE remote desktop protocol).

Besides, it is very uncomfortable with a laptop's touchpad.

The right answer would be a visible border, and an easy way to configure its width. But that is apparently too much to ask nowadays.

Until a configurable, visible border is implemented, please keep the invisible border feature, because the alternative is worse.

Disable compositor = no invisible borders

That is short sighted indeed. A compositor serves other purposes, and this is an all or nothing approach.

[ell1e]

@JorgeStolfi @rdiez just fwiw, GNOME 3 which is probably the most widely adopted environment has had this since 2011 already. While a personal opinion is fair, I would say arguing it's obviously not an improvement or "many users do not need any extra width" (really? is that the majority though?) is a bit silly. I think arguing just a fatter border will not waste any screen space in particular is just weird, of course it makes an objective difference if I can not only no longer click a screen area but on top of things also no longer see it. Doesn't mean you personally need to care, but it's an obvious difference if even so tiny. As a result, I also find the "An invisible area around a window is a bad idea indeed" as a supposedly obvious conclusion quite debatable.

Nevertheless, I'm not opposed to an option/toggle. But it seems like to me this might be more a reaction to a change you're not used to, and less an obvious usability degradation for the majority when it works fine for GNOME 3 users for so long already, so I don't get the calls for removal at least.

[lukefromdc]

We should remember that MATE and GNOME3 have different userbases with different preferences as to how their DE should look and reach

[JorgeStolfi]

I had to disable compositing. Browsing through the MATE window styles I found decent-looking one with a 3 pixel wide frame. That is adequate for me (real mouse with a 1366 x 768 14" laptop display), although 1 pixel more may have been better. I definitely do not need 10 px.

So maybe it is just a matter of providing some more window frame styles with wider margins, for people who have to use a mousepad or a capybara instead of a mouse?

Clicking on a visible button or headbar and having the click it ignored because of the invisible border is really annoying. That happened to me more often than the need to resize a window.

By foiling the user's expectation, that GUI behavior creates a "surprise" that distracts from the user's real work. It breaks the universal GUI metaphor "clicking on a button does that button's assigned task".

The workaround for that problem (move the offending window out of the way, click on the button, move the window back) is the same that he would need to use if the resize border was a visible frame obscuring the window below.

Lack of response here on GitHub does not mean much. 99.99% of MATE users will not even know what "GitHub" is.

[ell1e]

For what it's worth, the lacking invisible border is the reason why I gave up on Mate after testing it for a day. I liked it otherwise. So it can really go both ways

[raveit65]

I had to disable compositing. Browsing through the MATE window styles I found decent-looking one with a 3 pixel wide frame. That is adequate for me (real mouse with a 1366 x 768 14" laptop display), although 1 pixel more may have been better. I definitely do not need 10 px.

Yes, we ship different metacity themes with larger edges for people who don't use the compositor.

So maybe it is just a matter of providing some more window frame styles with wider margins, for people who have to use a mousepad or a capybara instead of a mouse?

See https://github.com/mate-desktop/mate-themes/tree/master/desktop-themes
They called .........-border.
You can select them via the edit button in mate-appearance-properties

Clicking on a visible button or headbar and having the click it ignored because of the invisible border is really annoying. That happened to me more often than the need to resize a window.

By foiling the user's expectation, that GUI behavior creates a "surprise" that distracts from the user's real work. It breaks the universal GUI metaphor "clicking on a button does that button's assigned task".

The workaround for that problem (move the offending window out of the way, click on the button, move the window back) is the same that he would need to use if the resize border was a visible frame obscuring the window below.

Lack of response here on GitHub does not mean much. 99.99% of MATE users will not even know what "GitHub" is.

Congratulation, you are 0.01% of Mate users :)

Without jocking, i think more linux users knows what git and github is.

[rbuj]

In the Mate control panel? I see no such field there, only a menu of predefined window borders.

You can find more information about how to create a custom theme on Desktop User Guide » Configuring Your Desktop » Look and Feel:

Feel free to submit your feedback to the documentation team at https://github.com/mate-desktop/mate-user-guide

[rdiez]

They called .........-border.
You can select them via the edit button in mate-appearance-properties

I am using Ubuntu MATE 20.04.1, and I do not see a way to select the xxx-border variants. In the Git repository you linked, there are for example variants BlueMenta and BlueMenta-border, but in Ubuntu MATE there is only BlueMenta.

Following the instructions above I could not see a way to select thicker or thinner borders either. In the "Window Border" tab there are no such xxx-border variants either.

Furthermore, a fixed border size is probably not enough. After all, some people like bigger fonts but smaller borders, others have HiDPI (4K or even 8K monitors). I think the only sensible solution is a user-configurable border size, maybe as a fixed pixel value, or as some percentage of the font size, or whatever may work well.

[rbuj]

Screenshot taken on debian:

[rbuj]

@rdiez you're right, these variants are not available on Ubuntu MATE 20.04.

[JorgeStolfi]

In the Mate control panel? I see no such field there, only a menu of predefined window borders.
You can find more information about how to create a custom theme on Desktop User Guide » Configuring Your Desktop » Look and Feel:

As others noted, the thick-border frames are not available in my menu. (the "about MATE" says 1.24.0)

[JorgeStolfi]

A suggestion: when the user has the wide resize regions enabled, make them transparent gray instead of invisible. The effect will be the same -- the user will be able to see the stuff behind, but not click on it -- but will not be "surprised" when the clicks are ignored.

[ell1e]

Maybe something alike to gnome shell's super soft surrounding frame shadow effect might be worth a consideration? (Technically I would think that can probably be rendered with 4 quads per side and another 4 per corner, so hopefully should be lightweight enough in case there's already a compositor running)

[raveit65]

I am using Ubuntu MATE 20.04.1, and I do not see a way to select the xxx-border variants. In the Git repository you linked, there are for example variants BlueMenta and BlueMenta-border, but in Ubuntu MATE there is only BlueMenta.

Sorry, we have no control about updating ubuntu or any other distro. This is usually in hands of distro maintainer.

But you can download latest mate-themes tarbal from https://github.com/mate-desktop/mate-themes/releases or
https://pub.mate-desktop.org/releases/themes/3.22/
Just extract the tarbal and copy the missing file to (example for BlueMenta):

[root@mother rave]# ls -la /usr/share/themes/BlueMenta-border/
insgesamt 52
drwxr-xr-x.  3 root root  4096 26. Mai 2020  .
drwxr-xr-x. 53 root root  4096 11. Feb 2020  ..
-rw-r--r--.  1 root root 34694 20. Nov 2019  COPYING
drwxr-xr-x.  2 root root  4096 26. Mai 2020  metacity-1
-rw-r--r--.  1 root root  1020 20. Nov 2019  README

BTW. mate-appearance-properties is the name of the application, Just type it in a terminal.

[ericmarceau-rogers]

Hello, could someone confirm whether the above solution applies to my situation as outline in by this issue under ubuntu/yaru?

If not, could someone explain the distinctions that make this case different from the one I am reporting and, if so, do I need to raise the issue here instead, or continue with my issue raised under ubuntu/yaru ?

Thank you for your consideration and advice/guidance.

[vkareh]

I posted an answer in ubuntu/yaru#4104

tl;dr: enable the compositor to fix, or use keyboard+mouse shortcut to resize

[lukefromdc]

We have "borders" versions of several MATE themes (but not all of them) for easier use without a compositor. Using any of them will solve this problem. A theme with NO borders used without a compositor will make resizing impossible using alt-right click, a theme with very narrow borders will make it difficult. The reason a compositor makes it so easy is that the entire shadow area is drawn on a slightly larger transparent window that becomes a wide border.

[ericmarceau-rogers]

Thank you, @lukefromdc.

Could you offer any suggestions for something that might offer that extra width but be equivalent to the Yaru-dark?

I am using that one because it was supposed to be the theme developed by Wimpress to become core theme for UbuntuMATE.

I previously had Ambiant, then AmbiantMATE-dark and never felt the need to move away).

[lukefromdc]

Offhand I would not know, as I mostly work in my own UbuntuStudio-Legacy theme. Look at the existing "borders" themes, which provide the metacity theme and depend on the main theme of the same name for everything else. Then diff the "metacity-1" or "metacity-3" files and apply similar changes to what you will name "Yaru-borders."

Alternately you could file this as a feature request issue against mate-themes. If you get a working yaru-borders theme it could even be added to mate-themes