Window adjust "grab-zone" size - Issues

[ericmarceau]

This earlier post discusses the issue of the difficulty in "grabbing" the edge or corner to adjust sizes of windows.

Another post raised the same issue, again seemingly without much success!

There is mention there that the related bug report was deemed closed. However the OP did state that the issue was still unresolved.

I would like to report that in UbuntuMATE 22.04 LTS (using Marco with no compositor), the issue still exists, with the size of "grab-zone" being 1 pixel, which is an absurd value for default.

I am trying to identify where I could modify that setting in my relevant theme files.

• My theme for Controls is: Yaru-bark-dark
• My theme for Window-border is: Yaru-dark

If I look for Yaru-dark among file names using my utility, I have this result:

After glancing at the first 3 files, I found nothing of value.

--------- start of edit ----------
Glancing at #4 led me to

/usr/share/themes/Yaru-dark/gtk-2.0

where I see this:

--------- end of edit ----------

If I were to replace the "1' in the line

GtkWidget::focus-line-width = 1

to the value of 5 or 7, would that take effect immediately, or only at next reboot, if at all ?

If this is not where we can control/customize the size of the grab-zone, where can we do that?

If not the above name for the parameter, what is the proper parameter/variable reference to be used when searching?

When I searched for main.rc on the MateDesktop site, I did not find any reference in the code tree. So I figured I would ask here?

Any ideas? or suggested alternate sites to approach?

[ironfoot]

Hi, @ericmarceau!

@ericmarceau

I would like to report that in UbuntuMATE 22.04 LTS, the issue still exists, with the size of "grab-zone" being 1 pixel, which is an absurd value for default.

It was partially fixed. Unluckily for you, the fix only works for Marco with built-in compositor. It creates some invisible draggable border around windows, but invisibility requires compositing.
You can play with theme files to make the borders thicker and stay with the compositing disabled.

[ericmarceau]

Thank you, @ironfoot.

If I have to have a thicker visual border, I can tolerate that more than wasting almost 10 seconds every time I try to grab to get the grab and adjust.

Is the issue that

• the theme itself is not able to integrate that as an option (i.e. not class object to connect with), or
• is that an option developers feel should ONLY be available with compositors, or
• is it simply that they never considered that as a need for simple basic themes?

-------- edit ---------
When I look under

/usr/share/themes/Yaru-dark/gtk-3.0

I don't see the main.rc but, instead, only a

gtk.gresource

which appears to be in some binary format described as

gtk.gresource: GVariant Database file, version 0

This posting on StackOverflow basically implies I shouldn't be trying to "decode/encode" that file for viewing/editing directly, stating that there should be XML files elsewhere.

Can anyone suggest where I should go for those?

Are gtk-3.0 and gtk-4.0 using the file under gtk-2.0 (main.rc, etc.) ?

----------- 2nd Edit --------------
So, I tried the edit on main.rc, but that had no effect.

The changes I tried were as follows;

root:/usr/share/themes/Yaru-dark/gtk-2.0# diff main.rc main.rc.Oasis
10,11c10,11
<   xthickness = 1
<   ythickness = 1
---
>   xthickness = 7
>   ythickness = 7
17,18c17,18
<   GtkWidget::focus-line-width = 1
<   GtkWidget::focus-line-pattern = "\2\1"
---
>   GtkWidget::focus-line-width = 7
>   GtkWidget::focus-line-pattern = "\7\7"
23c23
<   GtkWidget::tooltip-radius    = 3
---
>   GtkWidget::tooltip-radius    = 5
55c55
<   GtkRange::stepper-size      = 0
---
>   GtkRange::stepper-size      = 10
59,61c59,61
<   GtkScrollbar::stepper-size                 = 0
<   GtkScrollbar::has-backward-stepper         = 0
<   GtkScrollbar::has-forward-stepper          = 0
---
>   GtkScrollbar::stepper-size                 = 10
>   GtkScrollbar::has-backward-stepper         = 1
>   GtkScrollbar::has-forward-stepper          = 1
722a723
>     ### EAJM
726c727
<       border   = {1, 1, 1, 1}
---
>       border   = {7, 7, 7, 7}
2630c2631
< widget_class "*<GtkNotebook>*<GtkCellLayout>"                       style "text"
\ No newline at end of file
---
> widget_class "*<GtkNotebook>*<GtkCellLayout>"                       style "text"
root:/usr/share/themes/Yaru-dark/gtk-2.0# 

Some of those parameters may not have been relevant, but I did what I could with what I could find about each one (not very much).

If I edited the wrong file, can someone point me in the right direction ?

Thank you.

[ericmarceau]

Just to keep everyone in the loop, I made the following submissions:

• Width of "grab-zone" for window edges/corners is too small (1 pixel) · Issue #4104 · ubuntu/yaru

• Fix synthetic keybinding/button-grab window by vkareh · Pull Request #342 · mate-desktop/marco

• Increase invisible area for grabbing window border for resizing by mouse · Issue #248 · mate-desktop/marco

[ironfoot]

Hi, @ericmarceau !

Have you actually tested the released fix for Marco with the built-in compositor? Switching to this mode can make your life easier. Also, test the following hotkeys: Alt+LeftMouse to drag a window and Alt+RightMouse to resize a window.

@ericmarceau

Is the issue that

• the theme itself is not able to integrate that as an option (i.e. not class object to connect with), or
• is that an option developers feel should ONLY be available with compositors, or
• is it simply that they never considered that as a need for simple basic themes?

Are you talking about some ideal theoretical software architectural solutions here? Complex software is usually split into different components / layers with different functionality. In this particular case, the window manager layer (Marco in MATE) is responsible for handling window resizing. It shall work flawlessly with ANY theme, and moving this logic outside the window manager layer is a bad architectural decision.
As far as I understand, the invisible border solution was backported to Marco from Metacity or Compiz. I don't know if this was the gold standard solution to the problem or just the easiest approach to implement. You may want to re-read the threads from your initial post, especially the comments from @vkareh, who was working on the fix.

[ironfoot]

@ericmarceau

I don't see the main.rc but, instead, only a

gtk.gresource

How Do I open a gresource file

[vkareh]

@ironfoot

As far as I understand, the invisible border solution was backported to Marco from Metacity or Compiz. I don't know if this was the gold standard solution to the problem or just the easiest approach to implement. You may want to re-read the threads from your initial post, especially the comments from @vkareh, who was working on the fix.

This is certainly not a "gold standard" solution - it was just significantly easier to backport (even with years of code drift) than to implement this solution from scratch in Marco.

I agree with the solutions posted in this thread:

• enable compositor, or
• use Alt+RightClick to resize

[ericmarceau]

Thank you, @ironfoot, @vkareh, for responding.

@ironfoot, thank you for the suggestion, but I have never liked key-combination actions and don't want to start learning, or using those (the reason why I don't use emacs). Also thank you for the URL about gresource. I'm backing away from that, given everything else that has been said. For the record, I've tried the Marco(X-Render) option, and yes it resolves the grabbing zone issue, but now I am stuck with animations again ... which I do NOT want!

@vkareh,

@vkareh

it was just significantly easier to backport

I really don't understand the position that a no-compositor configuration is deemed to be a "backport". It is a fundamental configuration option. Therefore, all "basic" windows-related functionality should be available in that basic configuration.

--- general feedback/rant ---

My issue is that I do not want animations, and the only way to stop those, apparently, is to not use the compositor. (Even that is not 100%, but I am not going to waste my time on getting what remains resolved.)

Now I am being told that what was an inherent functionality in older "basic" installs, has now been stripped out of those "basic" configurations and deemed within the scope of advanced functionality (compositor) by what I consider to be "misguided" developers. I am sorry but that, from this simple user's experience having worked with UNIX/HP-UX since 1984, and Linux since 2006, seems that developers have drifted away from a user-caring approach to a more take-it-or-leave-it approach!

No, I don't want to be an OS developer, but I feel like I try my best to give sensible advice on how things should be from a "run of the mill" user's perspective, not depending on high-powered hardware.

In my view (and I am sure it is shared by many who have not seen the value in raising their voice and be counted), the current stance regarding what is required to be able to do edge grabbing is disrespectful of users. It is NOT intuitive unless you use a compositor! Why???

I truly appreciate all the work that goes into developing and improving Linux (I was briefly involved in non-Linux work during my career) and prefer now (as retiree) to remain at arms length as a user offering constructive, and detailed, feedback, as part of the two-way street that I perceived such cooperative development to be.

Adopting 22.04 now seems like a bad move. I should have frozen my system at 20.04 and left it at that.

Not happy with what is now being forced on me!

(No! I will not revert, now that I have migrated to 22.04. I have to find an acceptable patch-work. Not happy. )

[vkareh]

@ericmarceau

I really don't understand the position that a no-compositor configuration is deemed to be a "backport".

That's not what a backport means. In this context, I took the code from metacity/mutter and backported it to work with Marco. That code required a compositor, and so that's where it landed.

With regards to basic functionality, the theme I use (TraditionalGreen) has no issues without compositor, since the border is wide enough. However, if you want to grab an invisible border, you need a compositor.

So maybe yet a third suggestion is to use a different theme that has window borders. Perhaps the real issue is expecting traditional behaviour from a theme designed with compositing in mind.

[ironfoot]

@ericmarceau

I've tried the Marco(X-Render) option

Are you using the built-in compositor or picom? The suggested option in MATE Tweak is named Marco (built-in: Xpresent). Also, disable animations in MATE Tweak. With these two options, I do not observe any animations, just light shadows around windows. Please, explain, what do you call "animations".

[ironfoot]

Hi, @vkareh,

thank you for coming back here and clarifying things!

[vkareh]

@ericmarceau

No, I don't want to be an OS developer, but I feel like I try my best to give sensible advice on how things should be from a "run of the mill" user's perspective, not depending on high-powered hardware.

Sounds like an ideal scenario, but misses the mark due to the nuances involved in developing a traditional desktop on top of a modern software stack. MATE is still bound by the technology of the time - to run MATE in a modern distro implies that you're running it with the latest libraries available in said distro. And that means MATE has no choice but to evolve to use those libraries (or fork them all to create a brand new distro). Doing it any differently would mean creating a brand new desktop environment (of which there are many to choose from if MATE is not your cup of tea).

MATE's goal is not to run in low-powered hardware, but to provide a traditional desktop metaphor.

[ericmarceau]

Thank you, @vkareh, for your response, reflecting the patient tolerance I appreciate finding in many developers.

@vkareh

use a different theme that has window borders.

When I look at the GitHub tree,

It seems that there is a "border" version of the BackMATE theme, BlackMATE-border, but that is not listed in the available themes (UbuntuMATE on Ubuntu 22.04.4 LTS):

Assuming that theme incorporates what you were identifying as the missing extra border, would you be willing to offer guidance on where and how to get that installed?

Thank you in advance for your kind patience with this "dinosaur".

------------ edit --------------
I've copied the files from the GitHub repository into my /usr/share/themes directory.

I discovered the *.png files are "dummy" files.

I copied the corresponding files from the BlackMATE theme into BlackMATE-border, and set all ownerships/groups/permissions to those of BlackMATE.

When I open the Appearance utility to select that theme, what it presents this,

which suggests that it is not a "sane" configuration, so I did not attempt to use it.

Is there something that should be added/copied from BlackMATE into BlackMATE-border to make that a "sane" configuration ?

[vkareh]

I don't use Ubuntu these days, but Fedora. In either case, my copy of MATE is not from the repositories, but built directly from GitHub:

cd mate-themes/
./autogen.sh --prefix=/usr
make
sudo make install

If you've never built packages before, you'll need to fetch dependencies. For Ubuntu the easiest is to do this:

sudo apt-get build-dep mate-themes

[ericmarceau]

Thank you, @vkareh,

For what you outlined, can I download only the mate-themes branch and none of the others to do that?

Can I drop that tree anywhere in my filesystem (i.e. on a non-root disk) ?

I see there is a "ready-to-roll" bundle on GitHub:

Can I just unbundle the release bundle, and have that "-border" version work properly?

[vkareh]

@ericmarceau

For what you outlined, can I download only the mate-themes branch and none of the others to do that?

Yes, absolutely. Here's a modified script to download/build just the mate-theme bundle:

wget https://github.com/mate-desktop/mate-themes/releases/download/v3.22.26/mate-themes-3.22.26.tar.xz
tar xvf mate-themes-3.22.26.tar.xz
cd mate-themes-3.22.26/
./autogen.sh --prefix=/usr
make
sudo make install

@ericmarceau

Can I drop that tree anywhere in my filesystem (i.e. on a non-root disk) ?

Yes, but you still need to run the build process (unless you can parse out exactly where each asset goes in your distro - each distro is different).

@ericmarceau

Can I just unbundle the release bundle, and have that "-border" version work properly?

No, that bundle is the source code. The assets are in there somewhere, but you'd need to figure out the right location for each of them - the build process does that for you. I'd follow the build script above to make it easier.

[ericmarceau]

Thank you again, @vkareh, for your assistance.

I did all that just as you were answering and it shows in the Appearance applet without the Question Mark, selected it, and that works great!

Now I can revert to no compositor again!

Thank you so much!

Just to confirm, I can purge my "source/build" directory?

------ edit ------
Interesting observation:

The size of the grab-zone is larger for Marco(X-Present) than for Marco(no compositor).
Why is that, and can that be adjusted?

[vkareh]

@ericmarceau

I did all that just as you were answering and it shows in the Appearance applet without the Question Mark, selected it, and that works great!

Fantastic! Great work building the theme - not everyone dares build components of their desktop environment from source like that

@ericmarceau

Just to confirm, I can purge my "source/build" directory?

Yes. Keep in mind, though, that if your distro pushes an update the mate-themes package, it will likely undo your build changes and you'll have to run the same build steps as the previous post again.

@ericmarceau

The size of the grab-zone is larger for Marco(X-Present) than for Marco(no compositor).
Why is that, and can that be adjusted?

The XPresent compositor adds additional transparency around the window border. It can only be adjusted by changing the source code of Marco. Currently it's hard-coded to 10px, I think, and making it "live-adjustable" would break rendered windows without major code changes.

The no-compositor option just relies on the visible window border. That can be adjusted in the theme resource file (I think, but I'm not much of a themer myself).

[ericmarceau]

Thank you, @vkareh! I appreciate the further guidance.

Out of curiosity, I experimented by trying to replace the image for bar_unfocused.png with a darker substitute, to make my live window stand out more, but that didn't seem to take.

I used this

instead of this

I did the full rebuild after that change, but without impact.

I looked thru the build log and did not see any "reject" or "corruption" message related to that replacement file.

I even did a reboot to no avail.

Is there any reason why not?

[vkareh]

Sounds like titlebar_fill_unfocused targets only maximised windows for some reason.

Since you're changing asset files, make sure you run the autogen.sh in the build commands.