Dialog box pops up now when double clicking on desktop icons in LXDE, asking for confirmation. Want to stop this behavior.
Hi, The subject pretty much says it. In the last week or so, the behavior of the icons on the desktop has changed to require confirmation before opening the application in LXDE. There is one icon, the one for spectacle, the screen capture application, that this does not happen for. So there must be a way to stop it from happening. Would this be an issue in X (LXDE still runs only on X as far as I am aware), LXDE, or maybe selinux or some other security app? There have been hundreds of updates in that time frame, so unless I absolutely have to, I'd rather not go back looking through them for a likely culprit.
Thanks for any help.
On 05/15/2018 08:06 AM, stan wrote:
The subject pretty much says it. In the last week or so, the behavior of the icons on the desktop has changed to require confirmation before opening the application in LXDE. There is one icon, the one for spectacle, the screen capture application, that this does not happen for. So there must be a way to stop it from happening. Would this be an issue in X (LXDE still runs only on X as far as I am aware), LXDE, or maybe selinux or some other security app? There have been hundreds of updates in that time frame, so unless I absolutely have to, I'd rather not go back looking through them for a likely culprit.
Check that the executable bit is set on those files.
On Tue, 15 May 2018 11:55:38 -0700 Samuel Sieb samuel@sieb.net wrote:
On 05/15/2018 08:06 AM, stan wrote:
The subject pretty much says it. In the last week or so, the behavior of the icons on the desktop has changed to require confirmation before opening the application in LXDE. There is one icon, the one for spectacle, the screen capture application, that this does not happen for. So there must be a way to stop it from happening. Would this be an issue in X (LXDE still runs only on X as far as I am aware), LXDE, or maybe selinux or some other security app? There have been hundreds of updates in that time frame, so unless I absolutely have to, I'd rather not go back looking through them for a likely culprit.
Check that the executable bit is set on those files.
It's strange, spectacle had no executable permission, and when I looked at the properties it says no one can execute it. The problem icons all had executable permissions, and the properties were anybody can execute. I removed the executable permissions, but no difference. When I have a chance, I'll try restarting X to see if it picks up the new properties of these icons, and they then have the same behavior as spectacle. I think you are onto something, since the executable permissions were such a match for behavior, if in a negative manner. Thanks.
On 05/15/2018 01:12 PM, stan wrote:
On Tue, 15 May 2018 11:55:38 -0700 Samuel Sieb samuel@sieb.net wrote:
Check that the executable bit is set on those files.
It's strange, spectacle had no executable permission, and when I looked at the properties it says no one can execute it. The problem icons all had executable permissions, and the properties were anybody can execute. I removed the executable permissions, but no difference. When I have a chance, I'll try restarting X to see if it picks up the new properties of these icons, and they then have the same behavior as spectacle. I think you are onto something, since the executable permissions were such a match for behavior, if in a negative manner. Thanks.
When I double-click a .desktop file in Nautilus, Gnome pops up a dialog box saying that the file is not trusted and do I want to trust it and execute it. After agreeing, the proper icon shows up instead of the basic file icon. I don't know where it stores the information, but it must save the path somewhere, because if you replace the file with something else, the new file is still trusted.
On Tue, 15 May 2018 14:18:35 -0700 Samuel Sieb samuel@sieb.net wrote:
When I double-click a .desktop file in Nautilus, Gnome pops up a dialog box saying that the file is not trusted and do I want to trust it and execute it. After agreeing, the proper icon shows up instead of the basic file icon. I don't know where it stores the information, but it must save the path somewhere, because if you replace the file with something else, the new file is still trusted.
Restarting X didn't work, but the above gave me the hint I needed. I deleted the offending icons and re-created them, and now they work like they always did. It seems some api changed, and needed the re-creation to configure it so it would work properly. That was one of the first things I tried, deleting and re-creating an icon. Then, it had the same behavior, now it works. The only difference between the two icons I can see is that the new one doesn't have a description or tooltip. What would the universe be without mysteries?
Thanks for your help.
On 05/15/2018 03:02 PM, stan wrote:
Restarting X didn't work, but the above gave me the hint I needed. I deleted the offending icons and re-created them, and now they work like they always did. It seems some api changed, and needed the re-creation to configure it so it would work properly. That was one of the first things I tried, deleting and re-creating an icon. Then, it had the same behavior, now it works. The only difference between the two icons I can see is that the new one doesn't have a description or tooltip. What would the universe be without mysteries?
You can go into the ~/Desktop folder and see the files that correspond to the icons. They should be .desktop files, but maybe they weren't before.
On Tue, 15 May 2018 16:02:12 -0700 Samuel Sieb samuel@sieb.net wrote:
You can go into the ~/Desktop folder and see the files that correspond to the icons. They should be .desktop files, but maybe they weren't before.
They are all desktop now. I'm pretty sure I would have noticed if they weren't before, since I was looking for inconsistencies. But, whatever they were, everything was working fine until the update that broke this. I still have no idea what that was, but at least everything is working now, so I'll just let it go.
-
Samuel Sieb -
stan