Mailing List Archive

Am 2022-09-14 19:21, schrieb Grant Edwards:
> Meld just updated from 3.20.4 to 3.22.0 (I have ~amd64 set for meld),
> and now meld uses client side decorations instead of allowing the
> window manager to handle that stuff. This is extremely annoying, since
> meld looks/acts differently than everything else and a lot of window
> operations are now unavailable for meld.
>
> For now, I'm goint to revert to 3.20.4, but hopefully there's a way to
> get meld 3.22 to behave itself?
>
> --
> Grant

You might want to have a look at gtk3-classic [1] which includes the
functionality of the dated gtk3-nocsd [2] hack.
The former is available in the khoverlay as a patcheset.

Sincerely,
Meik

[1] https://github.com/lah7/gtk3-classic/
[2] https://github.com/PCMan/gtk3-nocsd

On 2022-09-14, Meik Frischke <meik.frischke@gmail.com> wrote:
> Am 2022-09-14 19:21, schrieb Grant Edwards:
>> Meld just updated from 3.20.4 to 3.22.0 (I have ~amd64 set for meld),
>> and now meld uses client side decorations instead of allowing the
>> window manager to handle that stuff. [...]
>>
>> For now, I'm goint to revert to 3.20.4, but hopefully there's a way to
>> get meld 3.22 to behave itself?

> You might want to have a look at gtk3-classic [1] which includes the
> functionality of the dated gtk3-nocsd [2] hack. The former is
> available in the khoverlay as a patcheset.

Thanks! I had found gtk3-nocsd. I initially ran across it many years
ago when trying to get evince to act like a good X11 app, but
switching from evince to atril solved that problem without having to
try gtk3-nocsd.

gtk3-nocsd was a seperate library that replaced a few GTK3
functions. It was used by setting LD_PRELOAD so that the gtk3-nocsd
library was searched first -- that way it could be applied only to
specific executables.

OTOH, gtk3-classic is a set of source patches that get added to the
"normal" gtk portage directory. Those patches are then used the next
time gtk3 is emerged. That means that it's a permanent, system-wide
change: all executables that use GTK3 will be using a library that has
the classic patches.

Am I undertanding the mechanisms correctly?

--
Grant

On 2022-09-14, Grant Edwards <grant.b.edwards@gmail.com> wrote:

> OTOH, gtk3-classic is a set of source patches that get added to the
> "normal" gtk portage directory.

I didn't state that very well -- the patches are installed into the
/etc/portage/patches directory for gtk+, not into the normal portage
db for gtk+.

--
Grant

Am 2022-09-14 23:14, schrieb Grant Edwards:
> On 2022-09-14, Grant Edwards <grant.b.edwards@gmail.com> wrote:
>
>> OTOH, gtk3-classic is a set of source patches that get added to the
>> "normal" gtk portage directory.
>
> I didn't state that very well -- the patches are installed into the
> /etc/portage/patches directory for gtk+, not into the normal portage
> db for gtk+.
>
> --
> Grant

Yes, the way the gtk3-classic ebuild in the overlay works is by placing
the patches in the portage patches folder. Once rebuilt, the patched
gtk+ library will disable CSDs by default, but the behavior can be
altered with the GTK_CSD environment variable. Please have a look at the
documentation for the details and further caveats.

Sincerely,
Meik

On 2022-09-14, Meik Frischke <meik.frischke@gmail.com> wrote:
> Am 2022-09-14 19:21, schrieb Grant Edwards:

>> Meld just updated from 3.20.4 to 3.22.0 [...]
>> and now meld uses client side decorations instead of allowing the
>> window manager to handle that stuff. This is extremely annoying, [...]

> You might want to have a look at gtk3-classic [1] which includes the
> functionality of the dated gtk3-nocsd [2] hack. The former is
> available in the khoverlay as a patcheset.

Brilliant!

I added khoverlay, emerged gtk3-classic-patches, re-emerged gtk3+, and
the new meld now behaves "properly" like all everything else.

--
Grant