build: Fix Python applet bindings under Meson

[vkareh]

Meson introspection step stripped the MatePanelApplet prefix, so Python applets failed to load with a missing factory_main attribute. This only affected mate-panel built with meson, autotools worked fine.

This fix matches the symbol/identifier prefixes with autotools so the introspection data is generated correctly.

[lukefromdc]

Where are we still using python in panel applets? The invest applet was ported to C when it was brought back, so this may be used only by community supported applets. Not having any of those I am not sure how to test this

[vkareh]

The main candidates that come to mind are the "Advanced MATE Menu" (mate-menu) and the "MATE Dock Applet" (mate-dock-applet) - both are Python and rely on those bindings, and both are part of Ubuntu MATE.

I've seen folks in the old ubuntu-mate.community website creating and sharing little python applets for various things, so I think it's useful to have since a lot of folks that want to tinker with MATE are much more comfortable with Python than with C.

[lukefromdc]

I don't have either of these applets, what's the best way to test this?

[vkareh]

I think those are the only two python applets in the Debian repositories, to be honest. I would suggest mate-menu since it's more lightweight and has no other dependencies. Source is https://github.com/ubuntu-mate/mate-menu

[lukefromdc]

Both these applets are out of process only and thus can only be used in x11. Since they predate most of the wayland use adding them silently fails

[lukefromdc]

Building this went fine, but I was unable to get Ubuntu's version of mate-menu to show up even in the x11 session. I'm wondering if this is the real reason for Debian and Ubuntu staying on 1.26? I tested adding
Platforms=X11; in /usr/share/mate-panel/applets/org.mate.applets.AccessxStatusApplet.mate-panel-applet and that didn't fix the problem.

[lukefromdc]

This was with ubuntu's build of the applet, I was not able to build the applet locally due to this error:

Traceback (most recent call last):
  File "/home/luke/Desktop/Development/MATE_Development_Work/mate-menu_22.04+git20260903/setup.py", line 27, in <module>
    import DistUtilsExtra.command.build_extra
ModuleNotFoundError: No module named 'DistUtilsExtra'

Note that I have very little python experience

[vkareh]

I don't think this is related to 1.26, since this only affects the meson build which landed very recently anyway.

Do you have the python3-distutils-extra package installed? Should be in the Debian repos and it's needed if you build the applet yourself at least (not sure if it gets pulled automatically as a dependency from the deb repos though).

[L-U-T-i]

I've successfuly built the current git snapshot (master branch) of mate-panel with this PR (and some other - #1578, #1580 and #1581). It is not a meson build, but "the old" autotools one (if it matters).

In "out of process" build of mate panel (and all other Mate Desktop components), the "Advanced MATE Menu" can be added to the panel and it seems to function as expected.

The only thing I've noticed is I suddenly can not freely move panel icons (applets) as before, but is has absolutely nothing to do with this PR (if I try to drag them, it does nothing; if I right click and select "move", I can make them to jump somewhere over some other icons / applets, but can not set the position not precisely - it sticks right next to something else, to the left or to the right side of it...). I notice the same behavior also in some older builds, but have to investigate at which release it started to be like that. In any case, I really hate it (I loved to have applets positioned precisely over the panel according to my desire, in some logical groups with a small or larger distance between them).

[lukefromdc]

Out of process applets normally do work in a panel with its native applets in-process. If the panel is running in x11 it is supposed to support mixing in and out of process applets freely. None the less I was unable on my setup to use the advanced mate menu even in an x11 session.

Hopefully someone else can get a functional test of this PR

[L-U-T-i]

My setup is the panel and all applets being built "out-of-process" (running of corse in X11). No problem to install and use advanced mate menu.

About my complain as above, I suspect it is the commit #7f62c16 from Jul 28, 2026 which is intentionally causing exactly that. I will try to rebuild everything with just this commit reverted, to see if I get back what I want.

[L-U-T-i]

I managed to rebuild the current git snapshot with slightly modified (adapted to PR ##1581 code change) complete PR #1567 reverted, getting the behavior I like back.

I've switched from gnome to Mate Desktop exactly because such annoyances (I really hate some applets being squashed too tight together, in particular the ones with a variable width - as NetSpeed for instance) and I just hope Mate desktop will not pull too much from recent Gnome versions!

Shall I open an issue - feature request - with a requirement to get the "old" applet positioning back as an option (to be chosen during a build time or even through settings)? I mean, are there any chances to get the free-move of applets back as an option (wor such weirdos as I am ;-)) or would I just clutter the isues with such a request?

[lukefromdc]

We get a choice between the ugly mis-spaced panel items (a guaranteed source of bug reports) and the decades-old issue that some users not all get applets moving on a new session it seems Personally I much prefer the old behavior, but I didn't have the random moving applets problem. Let's see what others think, so go ahead and open that PR

[L-U-T-i]

@lukefromdc, what exactly do you mean by "ugly mis-spaced panel items"?

I am using Mate desktop since about 1.20 (at least), and can't recall to ever have any such issue? Applets are not moving on my panel, and can't remember ever to notice something like that.

As said, probably the optimal solution would be for user to have a choice (can switch to zones in case of serious issues with free moving applets).

Or, at least to be able to build both versions (select through a configure switch), and install one or another...

I'm happy you also prefer the old behavior too - meaning I am maybe even not sooo weird... :-)

[lukefromdc]

The new panel applet placement code is no longer in pixels but uses a pack system. Looks like crap on my setup because some issue is preventing all launcher icons from being allocated the same space.

[lukefromdc]

Seeing this only affects meson builds, as expected this didn't create any problems in a test build here with the C applets, that it is needed by 3ed party applet builders who use python, and it comes from a proven team member here I am proceeding to merge it.