Doesn't identify clip source app name or icon

[hanaral]

It seems to never be able to correctly identify flatpak apps, which is a problem because flatpak is now the default format

[hezral]

Yeah, i had to do some workaround because the main API i used before is not working anymore. Do you mind to share what app that was? i know Appimage won't work unless it has a .desktop in one of the .desktop paths. Some apps may/may not be identified since i'm using matching.

[hanaral]

I think AppImages and Snaps should not be given priority, as that isn't going to be the main (native and integrated) app format on elementary OS. The app you see there oddly enough is actually terminal, which obviously isn't a flatpak (yet). Another app that doesn't seem to work (at least right now it's not even detecting copys) is Code, which I have installed with the flatpak. As far as I can tell(tm), you will need a few things to detect app names:

• Full IPC access (I think from this you can get process names(paces)?)
• Potentially full DBus access
• Obviously X11 and Wayland access (but you alr need that just to show the app)

My only experience with flatpaks is from making manifests for others, so I'm afraid I cannot give tips on how to actually do any of that besides just the permissions in the manifest. @Marukesu Sorry for tagging you out-of-the-blue, but would you happen to know how possible this is? (I saw your work on the elementary flatpak platform 💙️)

[hezral]

Thanks, from what I've researched before, this is somewhat due to sandbox of course. If you know the app AppEditor, it's using the same api as i was using and it too broke in flatpak and they only have a half hacky workaround which I didn't want to do.

As for terminal, i did noticed it as well now and it should be fixed now with the latest pull.

I don't think i want to go as far as IPC and DBUS just to get the active app window though since my current workaround method is working I'd say 90% of the time. I can adjust it as i find newer apps that isn't standard.

And yes i mentioned AppImage just for info. Though i am able to get info for Snap apps

For Code, I have not tested it with the flatpak version but it should still work. Can you test with the latest pull

For info, the api i was using before flatpak was Gio.AppInfo to get all installed applications, I'd be happy to switch back when/if i find the proper way to use it in flatpak

[hanaral]

What's the current solution? It would be pretty bad to be relying on something that is going to/could be removed in the future...

[hezral]

It's using xlib and scan of the desktop launcher paths which is standard for major desktop environments. this should be fine plus i've made it modular so i can just switch to whatever works. Wayland would break this of course but so will the clipboard api in Wayland and Gtk4 believe.

[Marukesu]

The problem is, sandboxed apps aren't meant to known about others installed apps, the only way is appending the desired directories to the PATH and XDG_DATA_DIRS like AppEditor do.

about the IPC, it's necessary for the x shared memory extension to work from the sandbox. so i think it would be good to add it to the manifest anyway.

[hezral]

Thanks @Marukesu for confirming my doubts 👍🏻

and i did exactly that which is to read the XDG_DATA_DIRS and parse the .desktop files

i'm not familiar with IPC and whether my app needs or not, so far its working but i'll add it in.

[hezral]

@hanaral i've tested with flatpak version of Code and it works now. fixed the match algorithm used.

[hanaral]

@Marukesu Since appcenter (I presume) isn't trying to stop other devs filling in or extending non-existent or partially existent OS functions (such as a clipboard history app like this), maybe there should be a portal to allow such functionality? (with some pretty heavy limits to what apps can see)

[Marukesu]

IMHO, that would be a design conflict with flatpak

[hezral]

Closing this as original issue is fixed