mate-desktop / mate-panel

MATE panel
https://mate-desktop.org
GNU General Public License v2.0
185 stars 118 forks source link

Fail to load panel plugins #1402

Closed fulalas closed 1 year ago

fulalas commented 1 year ago

This commit breaks the panel plugins loading for me on Slackware 15.0.

By just reverting /usr/lib64/libmate-panel-applet-4.so.1.0.1 to the one from 1.27.1 fixes the issue.

GTK3 version: 3.24.31 classic

lukefromdc commented 1 year ago

Template ignored first of all.

We need more information to even begin to fix this.

Do you have the dictionary applet in the panel? Do you have any third party applets (not maintained by MATE) in the panel?

I assume by "plugins" you mean applets? This change should have NO effect if you do not have the dictionary applet in the panel, and if it is built out of process (the default and until recent commits the only option), only the applet should crash if there is a problem. In mate-panel, the string "mate_panel_applet_request_focus " appears only in mate-panel/libmate-panel/libmate-panel-applet/mate-panel-applet.c and in mate-panel/libmate-panel-applet/mate-panel-applet.h and in mate-panel/libmate-panel-applet/MatePanelApplet-4.0.gir (to allow use in 3ed party python applets).

The only place outside mate-panel but in any MATE package I have installed this string appears in in mate-utils/mate-dictionary/src/gdict-applet.c

lukefromdc commented 1 year ago

Also note if gdk_screen_get_default() isn't working in any distro that's a major bug somewhere and not in MATE.

If this is reverted, use of it will have to be restricted to out of process applets as there is no panel-plug to get anything from in with an in-process applet. Passing that to mate-panel would be an API break BTW, breaking any 3ed party applets using it.

Also the ONLY way I have found to avoid the code used within mate_panel_applet_request_focus to focus a widget in mate-dictionary's panel applet is to move the text entry off of the panel and onto the popup dialog, which is exactly what I did in wayland. Note that no out of process applet can be used in wayland as we do not have GtkPlug, which depends on Xembed

I could do that unconditionally for the dictionary applet, or for that applet whenever built out of process, and add a comment in the code that this function will crash if called from an in-process applet (to avoid the API break) but that deliberately leaves a crasher in the code.

We really need to know what's going on with this in Slackware.

fulalas commented 1 year ago

Sorry. I have been super busy lately and it was late in the night when I posted that. There are no third party applets. I don't have the dictionary applet enabled, only language, sound, clock and show desktop. Networkmanager Applet is also running, but it's not part of MATE.

Here are the messages:

After boot: Screenshot at 2023-09-05 14-40-58

The output when trying to reopen manually: Screenshot at 2023-09-05 14-42-14

I also tried to use standard GTK+3 (i.e. not the classic one) and got the same result. Later I'm going to try using a newer GTK+3.

EDITED: just tried with GTK+3.24.38 and it didn't change anything :(

raveit65 commented 1 year ago

1.27.x are developer package releases, you shouldn't use them on production system. For production systems you should use stable 1.26 branch. So, isn't your system a production system? Do you have all mate packages update to development 1.27.x package releases? Or do you use a mix of stable and unstable releases?

Last but not least, it is very annoying to ask so many questions only because you ignored the template and you don't provide much information as possible. Sorry, i was busy and it was late is only a cheap excuse........ For me posting a say nothing report is really disrespectful to developers.... Maybe you think we are a company? And you are not the only one.....

Any way, i hope we can help you in our spare time.

lukefromdc commented 1 year ago

We do not have a language applet in MATE, but I see you have the notification area installed and built out-of-process by the posted dialog. By "language" maybe you mean the keyboard layout applet that shows the flags of the countries two or more languages are associated with if more than one is set up in mate-control-center->keyboard->layouts ?

lukefromdc commented 1 year ago

I just tested an out-of-process build of the notification area with mate-panel 1.27.2 had had no issues with it.

fulalas commented 1 year ago

@raveit65, I understand what you're saying but you're getting this wrong. I'm also a developer and I have a Linux distro. I'm not here to help me because as I said I have already found a workaround. I'm here to help you guys, as I did a few times in the past. If you don't find this useful, never mind.

@lukefromdc, yes, sorry, the keyboard layout applet. There's only one set: US.

I built all MATE projects in the latest versions and this problem happens specifically when using current /usr/lib64/libmate-panel-applet-4.so.1.0.1. If I keep the whole system the same and revert just this file (to one version before the commit I told you in the first post) the issue doesn't happen.

Not sure how I can help more with the knowledge I have about MATE. If you guys think this bug report is useless, that's OK, feel free to close the issue. No hard feelings :)

raveit65 commented 1 year ago

@raveit65, I understand what you're saying but you're getting this wrong. I'm also a developer and I have a Linux distro. I'm not here to help me because as I said I have already found a workaround. I'm here to help you guys, as I did a few times in the past. If you don't find this useful, never mind.

@lukefromdc, yes, sorry, the keyboard layout applet. There's only one set: US.

I built all MATE projects in the latest versions and this problem happens specifically when using current /usr/lib64/libmate-panel-applet-4.so.1.0.1. If I keep the whole system the same and revert just this file (to one version before the commit I told you in the first post) the issue doesn't happen.

Not sure how I can help more with the knowledge I have about MATE. If you guys think this bug report is useless, that's OK, feel free to close the issue. No hard feelings :)

I can't reproduce the issue with fedora 38 and my crystal ball doesn't show you box. Did you compile panel and all applets in-process or out-of-process?

lukefromdc commented 1 year ago

First question: is the notification area the ONLY applet not loading? If you have the volume control set up as the tray icon not the panel applet(default in many distros), a crash of the notification area takes down both the sound and keyboard icons. Also takes down network-manager-applet, which is in the tray. If you also lose show desktop and clock (two different applets), you should get two more popups unless those applets are built in-process yet the notification area built out of process. In that case the whole panel would crash and restart.

Here's where it stands on my end: 1: I don't have a landline, so cannot download installers of other distros to test

2: I cannot duplicate this issue on Debian Unstable so cannot even begin to work on it.

We may have to set this aside, leaving it open but not attempting to fix it unless others report it and provide more information.

fulalas commented 1 year ago

No single applet gets loaded. The only thing that shows on the taskbar is the quick launch items and application menu. And, yes, the popup error shows a few times.

I'm not sure about this in-process vs out-process. I didn't change anything from 1.27.1 and 1.27.2. As I said, the offending commit/line is this one

lukefromdc commented 1 year ago

Thanks for closing, it's not possible to do anything about this without a lot more info. The crash you get looks impossible from the code barring a 3ed party applet provided by your distro by default I am not aware of, as that line should never even be reached without the dictionary applet in the panel unless an applet not provided by MATE is using it

fulalas commented 1 year ago

There is no third-party applet. This is what I have when I revert that commit:

Screenshot_2023-09-07_22-44-22

fulalas commented 1 year ago

One tiny correction: I actually have 2 keyboard layouts set: US and UK.

lukefromdc commented 1 year ago

OK, I can see that. While network-manager-applet is not directly part of MATE, it is normally used in MATE and I checked its source code for any instance of mate_panel_applet_request_focus and found nothing. I cannot see any reason you are getting this issue but obviously you are. Again, no way to fix it if nobody on the team can duplicate it nor more info can be sent.

In-process BTW means an applet runs as a shared library loaded by the panel and draws directly to the panel's window or a subwindow therof, while out of process means the applet runs as it's own process and uses a GtkPlug window added to a GtkSocket in the panel. As those are both wrappers around Xembed, out of process can only be used in Xorg and cannot be used in wayland.

fulalas commented 1 year ago

OK. I was wrong about which commit is causing the issue. I suspect it's this one, specifically the files mate-panel-applet-gsettings.c and mate-panel-applet-gsettings.h.

The way to replicate is to use a dconf file created before this commit, like this one: user.zip

If I remove my dconf file and reboot, it regenerates and all applets load without any issue.

Let me know if you can replicate the issue with the dconf file above. Also, if you know which dconf entries I should remove/change to keep using this dconf file without having to reconfigure everything from scratch, that would be nice too. :)

Thanks and sorry for the initial wrong suspicious. Always learning!

lukefromdc commented 1 year ago

I played no role in that commit other than some very basic testing and have very little understanding of that part of the code. I do not even use the current version of dconf-editor due to a UI I find forces me to work at a snail's pace, so I cannot do a whole lot with relocatable schemas.

I will have to leave this for other team members to work on for lack of knowledge about how that part of the code works.

raveit65 commented 1 year ago

tell dconf-edit about relocatable schemas was a general fix of the usage of dconf by mate-panel. Before this commit dconf usage was simply incomplete. I didn't get a problem with that commit. It looks like that a dconf entry was wrong in old config. If a new config works than everything is fine. But thanks for reporting it. It is possible that other users will run into the same issue when this commit goes into a stable release. Than we know a solution.

fulalas commented 1 year ago

I found the reason why you guys can't replicate this issue. If you have dconf-editor installed (especifically /usr/share/glib-2.0/schemas/ca.desrt.dconf-editor.gschema.xml) the issue won't happen.

I guess this commit tell dconf-edit about relocatable schemas is expecting dconf-editor to be present, which shouldn't be the case, I guess.

fulalas commented 1 year ago

Steps to replicate the issue:

  1. remove (or move out) /usr/share/glib-2.0/schemas/ca.desrt.dconf-editor.gschema.xml
  2. recompile glib schemas: glib-compile-schemas /usr/share/glib-2.0/schemas
  3. restart the panel: mate-panel --replace &

I haven't tried, but maybe removing these lines (from the given commit) should fix the issue (for testing purposes only, of course):

unregister_dconf_editor_relocatable_schema (subdir); register_dconf_editor_relocatable_schema (schema, path);

EDIT: most likely this specific line is messing everything: dconf_editor_settings = g_settings_new ("ca.desrt.dconf-editor.Settings");

It seems it's assuming this schema exists, instead of checking for it first. If we return when this schema is not present, I'm not sure how dconf-editor would behave if it gets installed after boot though. Maybe there was a reason why there was that hack before this commit.

lukefromdc commented 1 year ago

Note that I had to modify my legacy dconf-editor 3.18 install (I find the later UI a real hassle to use) with modified schemas to accomodate the tell dconf-edit about relocatable schemas changes. Didn't consider this a bug as this is a very old version of dconf-editor not shipped by any distro version that will include MATE 1.28 down the road.

fulalas commented 1 year ago

@lukefromdc, I see what you mean. Well, even using dconf-editor 43 the crash happens, so...

Here is my suggestion:

mate-panel-dconf-editor-patches.tar.gz

I tested and it fixes the crash.

Jakko3 commented 1 year ago

I also ran into this issue. I'm on distro postmarketOS edge (based on Alpine Linux edge). Installed versions: mate-desktop 1.26.1, mate-panel 1.27.2.

dconf-editor is not installed by default in the distro. Installing dconf-editor (45.0.1) solves the issue. However, this would mean mate-panel depends on dconf-editor.

Jakko3 commented 1 year ago

I posted my comment above too fast. I have two devices:

device No. 1: qemu virtual machine (amd64)

device No. 2: samsung-serranove (armv7)

Likely these are two issues. And probably only one of them (the one solvable by installing "dconf-editor") seems to fit to the issue report here.

The different behavior of the devices is not neccessarily related to the architecture, it could also be caused by ~different set of installed packages or~ different hardware (e.g. display size or ratio).         Edit: I compared the set of installed packages, they are basically the same on both devices.

lukefromdc commented 1 year ago

The options available to us here seem to be: 1: revert https://github.com/mate-desktop/mate-panel/commit/277418cea7b011520df9759301d416cd51709564 which is flatly named "tell dconf-edit about relocatable schemas (#1355) " and thus would seem likely to depend on dconf-editor

2: Formally depend on dconf-editor as we are interacting with it.

3: Return from the function calling ca.desrt.dconf-editor.Settings if it is not present, test behavior of installing dconf-editor after boot and document it. We cannot control dconf-editor's behavior ourselves but could work around it e.g trigger a panel restart if it is detected later.

4: Do not use relocatable schemas anywhere in the panel or in its applets, note that this might require coordination with 3ed party applet developers

raveit65 commented 1 year ago

2: Formally depend on dconf-editor as we are interacting with it.

+1

I don't see any reason not to install dconf-editor, which is the basic GUI for dconf. Not every user like to use command-line to edit schemas. In Fedora-Mate spin this is the default since years and i never got a report that a user complains about at rhbz. Mate-panel don't use static dconf configurations, so using relocated schemas is the right way. Apart from this rewriting the whole dconf schemas for mate-panel and other applets only for this report is a huge job. I don't see any volunteers who like to spend spare time on it. Saying i don't like install dconf-editor without good arguments is not a reason.

Btw. in general using a mix from stable 1.26 und unstable 1.27 packages is not supported and can cause problems.

Jakko3 commented 1 year ago

(Just for the record: In my last post I mentioned two issues. The first one is this one here. The second one turned out to be https://github.com/mate-desktop/mate-panel/issues/1385.)

raveit65 commented 1 year ago

Good, you could fix your issue. So we can close this.