Register DBus method for interacting with applets

[vkareh]

This PR registers an 'Activate' DBus method that emits an 'activate' signal that any applet can connect to and perform whatever action it means to activate in that applet.

This allows users to control certain applet functionalities through DBus, like registering new keybindings, or integrating them with other software.

As an example, I've added the signal to the clock applet in this PR, so that it can be opened/closed through a dbus command:

$ dbus-send --session --print-reply --dest=org.mate.panel.applet.ClockAppletFactory /org/mate/panel/applet/ClockApplet/0 org.mate.panel.applet.Applet.Activate string:"toggle-calendar" uint32:0

You can even add that as a custom keybinding to have a quick keyboard-centric way of viewing your calendar.

My plan is to add this to a bunch of other applets eventually.

[lukefromdc]

I got this error from the Cpufreq applet with this applied, crashing the panel:

(mate-panel:245701): GLib-GObject-CRITICAL **: 23:37:02.746: specified class size for type 'CPUFreqApplet' is smaller than the parent type's 'MatePanelApplet' class size

(mate-panel:245701): GLib-CRITICAL **: 23:37:02.746: g_once_init_leave_pointer: assertion 'result != 0' failed
**
ERROR:mate-panel-applet.c:2457:_mate_panel_applet_factory_main_internal: assertion failed: (g_type_is_a(applet_type, PANEL_TYPE_APPLET))
Bail out! ERROR:mate-panel-applet.c:2457:_mate_panel_applet_factory_main_internal: assertion failed: (g_type_is_a(applet_type, PANEL_TYPE_APPLET))
Aborted                    mate-panel --replace

[vkareh]

@lukefromdc I don't usually have the cpufreq applet on my panel, but after recompiling mate-applets, the cpufreq applet worked just fine. What flags are you using to configure the builds of both mate-panel and mate-applets/cpufreq?

[lukefromdc]

My build options for mate-panel (normally packed into .debs and schemas compiled by the postinst script):

./autogen.sh --with-in-process-applets=wncklet,clock,fish,notification-area --prefix=/usr libdir=/usr/lib/x86_64-linux-gnu --sysconfdir=/etc --enable-shared=yes --enable-static=no --disable-maintainer-mode --disable-schemas-compile

My build options for mate-applets (again schemas compiled by the .deb's postinst script):
./autogen.sh --prefix=/usr libdir=/usr/lib/x86_64-linux-gnu --sysconfdir=/etc --enable-shared=yes --enable-static=no --disable-maintainer-mode --disable-schemas-compile --enable-in-process

[lukefromdc]

This could be different in or out of process

[vkareh]

hah, building mate-applets in-process breaks a bunch of things for me. Part of it is because of disjoint versions of libsoup, so I submitted mate-desktop/mate-applets#684 and #1520 to try to bring all MATE components to libsoup3 (those are the only remaining things in 2.4, after the port in libmateweather was merged this summer).

[lukefromdc]

This is still broken here on an in-process build, but since the clock change can be applied in-process without breaking the problem seems to be in the libmate-panel-applet changes

[vkareh]

@lukefromdc

This is still broken here on an in-process build, but since the clock change can be applied in-process without breaking the problem seems to be in the libmate-panel-applet changes

You might need to rebuild mate-applets against this new version of libmate-panel-applet - if it works for cpufreq, then it means we need to merge this, tag a release, then bump mate-applets to use the new version (I think).

[lukefromdc]

This does indeed work if mate-applets is rebuilt against it. This means we have an ABI break but not an API break.Mate-applets will need one change: to depend on the new version.

Doing some digging, I found that with an ABI break the normal rule is to also bump the soname, as every other package depending on it must also be rebuilt:

kristapsdz/lowdown#121

We have NOT however historically done that in MATE and it was one of Debian's complaints that delayed moving to 1.28. This however is not something I know a whole lot about

[lukefromdc]

Just tested applets from other packages with this.

Notifcation status (mate-notification-daemon) and the volume control applet work without a rebuild, presumably not calling whatever become ABI incompatable. The mate dictionary applet requires a rebuild, as does mate-power-manager's new mate-power-profiles applet and potentially either or both both of the other applets (not tested as running the wayland session at the moment).

I didn't find anything that was still broken after a rebuild

[lukefromdc]

I got this error on running the dbus-send test command, probably a difference in how my panel layout named the applet:

Error org.freedesktop.DBus.Error.UnknownMethod: Object does not exist at path “/org/mate/panel/applet/ClockApplet/0”

[lukefromdc]

I must have closed this trying to comment! I had absolutely NO intention of doing that. Assuming the problem running the test command is local to my machine, this is probably ready to go

[lukefromdc]

running dconf dump /org/mate/panel/applet/ on my system shows an empty directory. I found the applet instead under /org/mate/panel/objects/object-63/ but trying to run the test command on this gave

Object path was not valid: '/org/mate/panel/objects/object-63'

Note that my panel configuration file has not been reset/remade from scratch in a great many years, doing so would take over an hour to reset all my customizations.

I don't know much about dbus, so I cannot really do a functional test here but I can confirm nothing breaks if all applets are recompiled with no code changes required.

[lukefromdc]

Let's see if someone here with more understanding of dbus can have a look at this test.

[lukefromdc]

Any updates on this?