Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mintreport does report that XApp Status applet is missing even if is already added #39

Open
RudahXimenes opened this issue Dec 29, 2019 · 19 comments

Comments

@RudahXimenes
Copy link

Mintreport is oddly reporting that XApp Status Applet isn't added to the panel, but in reality it is.

image
This screenshot shows the applet added and the Mintreport tray icon saying, in Brazillian Portuguese, that XApp Status Applet is not added to the panel

If I click at the icon in tray, Mintreport opens and the tray icon vanish. Until last cinnamon update, yesterday (28/12/2019), mintreport didn't show anything when opened. Today is showing to add XApp Status Applet, but is already added.

image
Mintreport asking to add XApp Status Applet and Applet Configuration showing XApp Status Applet added

I updated my Mint from Linux Mint 19.2 using Update Manager, as recommended, and now I have up-to-date Linux Mint 19.3.

I'm using:
OS: Linux Mint 19.3 Tricia x86_64
Kernel: 5.0.0-37-generic
DE: Cinnamon 4.4.6

I don't know how to reproduce this bug, once it happend apparently random, but constantly.

Thank you all in advance!

@samilanki
Copy link

Same issue with 32-bit lap top.

@mtwebster
Copy link
Member

Hi can you paste the output of this command in a terminal:

dbus-send --session --dest=org.freedesktop.DBus --type=method_call --print-reply /org/freedesktop/DBus org.freedesktop.DBus.ListNames | grep org.x

and then, the output of this:

python3 -c "import gi; gi.require_version('XApp', '1.0'); from gi.repository import XApp; print(XApp.StatusIcon.any_monitors());"

Thanks

@RudahXimenes
Copy link
Author

RudahXimenes commented Jan 6, 2020

Unfortunately I crashed my old system uninstalling pulseaudio, so I made a new clean install with 19.3 and this bahavior is not showing up.

Maybe @samilanki could keep tracking this bug.

@snemes
Copy link

snemes commented Jan 6, 2020

Happened today again, here is the command output:

$ dbus-send --session --dest=org.freedesktop.DBus --type=method_call --print-reply /org/freedesktop/DBus org.freedesktop.DBus.ListNames | grep org.x
      string "org.x.StatusIcon.PID-2119-0"
      string "org.x.StatusIconMonitor.PID-2089-0"
      string "org.x.editor"
      string "org.x.StatusIcon.PID-2629-0"
      string "org.x.StatusIcon.PID-31533-0"

$ python3 -c "import gi; gi.require_version('XApp', '1.0'); from gi.repository import XApp; print(XApp.StatusIcon.any_monitors());"
True

@HelloMrKrinkle
Copy link

dbus-send --session --dest=org.freedesktop.DBus --type=method_call --print-reply /org/freedesktop/DBus org.freedesktop.DBus.ListNames | grep org.x
string "org.x.StatusIconMonitor.PID-1460-0"
string "org.x.StatusIcon.PID-1507-0"
string "org.x.StatusIcon.PID-1511-0"
string "org.x.StatusIcon.PID-1759-0"
string "org.x.StatusIcon.PID-1619-0"
string "org.x.StatusIcon.PID-1917-0"

@mtwebster
Copy link
Member

Hi, there's a new version of xapps (1.6.10) that should be available, if not now, very soon (depending on your download mirror).

Thanks

@HelloMrKrinkle
Copy link

so far so good since the update

@KHeilen
Copy link

KHeilen commented Jan 14, 2020

Quoting from the referenced issue #181 about the same issue:

So far no more false alert has been raised by Mint System Report to add the xapps-status-applet, after
libxapp1:i386 1.6.10+tricia
xapps-common 1.6.10+tricia
had been installed on 09-Jan-2020 21:00 CET.
Keeping my fingers crossed.

@adam4235
Copy link

I seem to be getting this issue too after just installing Linux Mint 19.3 XFCE version. Here is the output of those commands.

adam>dbus-send --session --dest=org.freedesktop.DBus --type=method_call --print-reply /org/freedesktop/DBus org.freedesktop.DBus.ListNames | grep org.x
string "org.xfce.Terminal5"
string "org.xfce.Xfconf"
string "org.x.StatusIcon.PID-26552-0"
string "org.x.StatusIcon.PID-26456-0"
string "org.x.StatusIconMonitor.PID-2959-0"
string "org.xfce.Panel"
string "org.xfce.PowerManager"
string "org.xfce.FileManager"
string "org.x.StatusIcon.PID-26881-0"
string "org.xfce.SessionManager"
string "org.xfce.Thunar"
string "org.xfce.SettingsDaemon"
adam>python3 -c "import gi; gi.require_version('XApp', '1.0'); from gi.repository import XApp; print(XApp.StatusIcon.any_monitors());"
True
adam>

I posted this in the forums before finding this bug report:
https://forums.linuxmint.com/viewtopic.php?f=57&t=317984

@adam4235
Copy link

It seems that the relevant file is
/usr/share/linuxmint/mintreport/reports/045_xappstatusapplet-missing/MintReportInfo.py

I notice that file checks for the use of Cinnamon or XFCE. In my case although I'm using XFCE, I'm also using the i3 window manager with it and disabling some XFCE components, so my setup is a bit non-standard. Could I have hit an edge case as a result of my non-standard setup?

@adam4235
Copy link

Anyway I've worked around the problem by deleting /usr/share/linuxmint/mintreport/reports/045_xappstatusapplet-missing but a proper solution would still be good.

@adam4235
Copy link

adam4235 commented May 29, 2020

I was thinking, could this be a race condition based on when the panel starts and when mintreport starts? I notice my Application Autostart is what starts mintreport-tray ("System Reports"). If that report runs before the panel starts, then it would think XApp isn't present, right? In my case the panel is started from a saved session.

@mtwebster
Copy link
Member

Have you updated to the latest xapps? This is fixed in 1.6.10 -

dpkg --list | grep libxapp

@adam4235
Copy link

adam4235 commented May 29, 2020

Yes:

adam>dpkg --list | grep libxapp
ii  libxapp1:amd64                             1.6.10+tricia                                    amd64        XApp library

@adam4235
Copy link

What do you think of my race condition idea? When I tried running mintreport-tray after my computer starts up, the problem didn't happen. If you don't think that's the problem, then how does Mint usually guarantee that mintreport-tray is run after the panel has started?

@LinuxOnTheDesktop
Copy link

LinuxOnTheDesktop commented Jun 1, 2022

What do you think of my race condition idea?

I myself do see the problem - the prompting to enable an applet that is enabled already - only when MintReport is not run on a delay.

Seemingly then a fix would consist in either some change of the code or merely adding a delay to the autorun of mintReport. That second option would be easy for the devs to implement. I note that if an OS has many paper-cuts then users get a bad experience.

EDITED.

@k-lynx
Copy link

k-lynx commented Apr 7, 2024

Suddenly one of my 21.3 hosts exhibits this problem.

Here is the output of the commands requested in previous posts:

$>dbus-send --session --dest=org.freedesktop.DBus --type=method_call --print-reply /org/freedesktop/DBus org.freedesktop.DBus.ListNames | grep org.x

There was no output from this command.

$>python3 -c "import gi; gi.require_version('XApp', '1.0'); from gi.repository import XApp; print(XApp.StatusIcon.any_monitors());"
False

$>dpkg --list | grep libxapp1
ii libxapp1:amd64 2.8.2+virginia amd64 XApp library
$>dpkg --list | grep xapps-common
ii xapps-common 2.8.2+virginia all Common files for XApp desktop apps

System info-
https://pastebin.com/UcM48QiL

I'm not the most capable Linux user but can follow instruction. So any help to understand & correct my problem would be appreciated.

Thanks in advance.

@k-lynx
Copy link

k-lynx commented Apr 11, 2024

While awaiting a response, package updates have been installed; including an update to kernel 6.5.0-27. Performing previously requested commands again did have one different result as shown-

$>dbus-send --session --dest=org.freedesktop.DBus --type=method_call --print-reply /org/freedesktop/DBus org.freedesktop.DBus.ListNames | grep org.x
string "org.x.reader.Daemon"

The previously posted results to the other commands were unchanged.

@RudahXimenes
Copy link
Author

@k-lynx it looks like an unsolved and rare issue, so maybe people don't have any solution to it yer.

Reading this thread, I found an hypothesis that the issue could be the loading order of the apps in system while booting/logging in.

I remember that a clean install solved the issue to me (and I was forced to make one cause I hard crashed my system while ago). Nowadays I can't help you anymore because it has years since I moved from Mint to Arch.

Maybe @mtwebster could help you further.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

9 participants