Clipman status icon acting strangely

Spass · 2018-09-20 11:01:28

I use Clipman 1.4.2 on my Xubuntu 18.04 and 18.10 and I've noticed that its status icon in the Notification Area is acting strangely. Note that I'm not talking about Clipman panel plugin here, just the status icon. One time it uses the proper icon (named "clipman" in the theme) and another time it uses the fallback ("edit-paste"). On fresh start it always uses proper "clipman" icon, but after a system reboot (or couple of them) it switches to "edit-paste". You can see the code regarding those icons here:
https://git.xfce.org/panel-plugins/xfce … con.c#n107

Screenshot - https://ibb.co/hykUEz

Left side - Xubuntu 18.04 with Papirus icons, right side - Xubuntu 18.10 with elementary Xfce icons. The top icon is a proper one, bottom one is a fallback.

Should I submit a bug or maybe there is a workaround for this (very minor) issue?

MountainDewManiac · 2018-09-20 15:17:37

By fresh "start," do you mean the first use of the distro after installation/reinstallation? If so, is the file that the icon is packaged in being updated by your distro's update manager software?

Regards,
MDM

Spass · 2018-09-20 15:49:45

Nope, just a fresh start of the application, from the Whisker Menu, after I've closed it before. The normal behaviour is when you don't close Clipman manually it adds itself to the autostart (as xfce4-clipman command). And then, when it starts automatically, it has problems with choosing/getting the proper icon. But it's somewhat random, so sometimes it chooses the right one. I think that it's not an icon theme issue, tested many times, on many icon themes, without updating icon themes in the process of course.

ToZ · 2018-09-20 16:37:54

According to the code, the decision is simple - if the current icon theme has a proper "clipman" icon it will use that, otherwise it will use the fall-back (edit-paste). There must be something askew with your system that the "gtk_icon_theme_has_icon()" function is failing.

Does this problem always occur when you are starting up with an autostart entry for xfce4-clipman? If so, maybe the app is starting before GTK and/or xsettings is properly initialized?

Does it ever happen if you start the app while the system is already up and running?

Spass · 2018-09-20 17:05:20

ToZ, that's what I was thinking, the code looks simple and straightforward. And the theme I'm using has a "clipman" icon for sure. My machine is probably not the culprit here, because I've tested it in the VM also (Xubuntu 18.10 with elementary Xfce icons visible on my screenshot from the first post).

This problem not always occurs when the Clipman is started from the autostart, but many times, it's more like a random thing. And it always choose the proper icon when started while the system is up and running.

So you're probably right, maybe it starts before xsettings (or some other important thing) and it gets "confused". Maybe I just should add some delay to the "xfce4-clipman" command in the autostart? That could be a good workaround, I think.

EDIT: Not sure if that information is relevant, but the "clipman" icon in my icon theme (Papirus) is a symlink. But it shouldn't matter, right?

Last edited by Spass (2018-09-20 23:34:58)

ToZ · 2018-09-20 17:09:17

Try with the delay to see if that makes a difference. It would be interesting to see if it has an effect.

Spass · 2018-09-20 20:05:04

OK, done some testing. I changed "Exec" in the ~/.config/autostart/xfce4-clipman-plugin-autostart.desktop launcher from xfce4-clipman to sh -c "sleep 10 && xfce4-clipman" and it worked fine. Clipman's status icon had the proper icon after the reboot. But... Clipman seems to automatically create / overwrite that launcher and it changes it back to xfce4-clipman.

I tried to disable (uncheck) that default autostart entry in Session and Startup settings and I created my own with "sleep", but after the restart Clipman enables itself (that default startup entry) again, so I had two active autostart commands - my custom one (with sleep) and the default one.

So delaying generally works, but I cannot make it permanent. Should I make the change somewhere else?

It seems that there's something wrong with the Xfce starting priorities and procedure overall. This reminds me another issue with doubled status icons (e.g. Network Applet, Redshift).

ToZ · 2018-09-20 20:10:46

Try this. Create the file /usr/local/bin/xfce4-clipman with the following content:

#!/bin/bash

sleep 10
exec /usr/bin/xfce4-clipman

...and make it executable.

This will interrupt the call to run /usr/bin/xfce4-clipman and add the sleep command. And it won't matter what the program does to the autostart entry.

Edit: to clarify, the interruption will only work if /usr/local/bin comes before /usr/bin in your PATH - which it does for most distros.

Last edited by ToZ (2018-09-20 20:12:06)

Spass · 2018-09-20 20:30:49

Thank you ToZ, it works. Yet another small hack to make my system "perfect" ;) Should I submit that as a bug on the Xfce Bugzilla? If yes, do you think it affects "xfce4-clipman" only?

ToZ · 2018-09-20 22:35:26

I actually don't think this a bug with clipman. I think the issue is related to why your system takes so long to load and initialize GTK and/or xsettings.

But perhaps you could create a bug report to see what the developer says.

Is there anything of interest in your ~/.xsession-errors file?

Spass · 2018-09-20 23:29:50

Yes, there are some messages regarding Clipman in the .xsession-errors file after a fresh reboot:

** (xfce4-clipman:1188): WARNING **: 01:04:51.112: Unable to register GApplication: An object is already exported for the interface org.gtk.Application at /org/xfce/clipman
(xfce4-clipman:1188): GLib-GIO-CRITICAL **: 01:04:51.112: g_application_get_is_remote: assertion 'application->priv->is_registered' failed
(xfce4-clipman:1188): GLib-WARNING **: 01:04:51.112: g_set_application_name() called multiple times

I removed your hack before the reboot and the icon was wrong again (fall-back "edit-paste"), so this log may potentially tell something useful. Here's the whole thing - https://paste.ubuntu.com/p/4ch25BwBXv/

I'll probably submit a bug, I know for sure that other Xubuntu users have this issue too.

ToZ · 2018-09-21 00:39:55

It looks like it's failing to start because it is already running. Are you saving sessions?

A bug report is probably a good idea.

Spass · 2018-09-21 01:15:13

ToZ wrote:

Are you saving sessions?

Nope.

I just checked that file on my VM install also (with "sleep" workaround in place) and it has exactly the same warning messages, just slightly lower in the log (obviously). And of course since the xfce4-clipman command is delayed, I see the proper icon. I'll submit a bug soon.

Thanks for all your help and for providing a workaround. Appreciate it.

EDIT: Issue reported here - https://bugzilla.xfce.org/show_bug.cgi?id=14711

Last edited by Spass (2018-09-21 14:37:00)

Xfce Forum

Sub domains

#1 2018-09-20 11:01:28

Clipman status icon acting strangely

#2 2018-09-20 15:17:37

Re: Clipman status icon acting strangely

#3 2018-09-20 15:49:45

Re: Clipman status icon acting strangely

#4 2018-09-20 16:37:54

Re: Clipman status icon acting strangely

#5 2018-09-20 17:05:20

Re: Clipman status icon acting strangely

#6 2018-09-20 17:09:17

Re: Clipman status icon acting strangely

#7 2018-09-20 20:05:04

Re: Clipman status icon acting strangely

#8 2018-09-20 20:10:46

Re: Clipman status icon acting strangely

#9 2018-09-20 20:30:49

Re: Clipman status icon acting strangely

#10 2018-09-20 22:35:26

Re: Clipman status icon acting strangely

#11 2018-09-20 23:29:50

Re: Clipman status icon acting strangely

#12 2018-09-21 00:39:55

Re: Clipman status icon acting strangely

#13 2018-09-21 01:15:13

Re: Clipman status icon acting strangely

Board footer