Create fake app info for unknown windows

[lenemter]

Fixes #310 (Basecamp app)

Some windows run in portable mode (for example AppImages) and they do not provide any .desktop files by default. Right now Dock doesn't even show these windows. This branch constructs fake app info for them and always shows them.

I couldn't find a way to trick GLib.DesktopAppInfo into using fake data, so I created a wrapper for it.

[danirabbit]

I'm really nervous about implementing workarounds for apps that don't follow standards and the new bugs that might create

[leolost2605]

Only on a technical note, if we want it, I think it might be worth looking into shipping an io.elementary.dock.unknown.desktop file with Unknown as app name and either nothing or something like notify-send "Tried to launch unknown app" as executable and using that instead of wrapping GLib.DesktopAppInfo. 🤷

[lenemter]

@danirabbit I'm not sure about this as well. On the one hand I don't want to support apps that don't follow desktop file standards. But on the other it just feels weird that the dock displays 'apps' and not 'windows', that the dock windows list and the Alt+Tab list may not be the same. If you choose to not merge this, I'll be ok with that.

[lenemter]

@leolost2605 there's a flaw in this. The window might have a title. Using unknown.desktop file will always display it as "Unknown" where here it will be display a window title.

[leolost2605]

Ah right though since the dock shows apps not windows I guess it might be debatable whether the window title should be favored over an "app name" Unknown.
But another flaw would also be that windows belonging to different apps would show under the same "Unknown" app so maybe not optimal indeed.

[teamcons]

I'm really nervous about implementing workarounds for apps that don't follow standards and the new bugs that might create

I get it, standards are nice for those that follows them
but imho we're in an imperfect world, so best to make sure the experience for enduser is ok regardless of others mess-ups

as long as it is clear this is a fallback and eOS is not to blame for anything missing but doing best it can

[danirabbit]

Providing a .desktop file is like the most basic standard though. Not providing one is severely broken. It's not just having a hard time complying with a standard or something obscure. It is the most basic and ubiquitous standard of proving a launcher file on all desktop environments. It's an old standard. Not doing this is fundamentally broken. It's not even possible to do this if you ship your app as Flatpak. That's how broken it is.

So basically this is a workaround for unsupported system modification that won't even be possible to do if we move to image based

[teamcons]

I dont disagree. It is suck and bad and make kittens cry. But it's not eOS problem at hand eOS problem at hand is that theres no indication of any kind theres an issue with a desktop file, and thats perceived as a buggy dock where you cant switch to some apps Its not an uncommon issue either. gparted itself has it and is shipped in the live with its broken desktop file So like im fine with this not merging, but im not looking forward to explaining constantly to people why their app exist in only half the UI Btw on imagebased, our system was an image based one until september, there was still lots of off-the-beaten-path situations... Theres teething issues, and it is also not there yet. Id take the stance of not penalizing the user Danielle Foré ***@***.***> schrieb am Fr., 6. Dez. 2024, 01:45:

…

Providing a .desktop file is like the most basic standard though. Not providing one is severely broken. It's not just having a hard time complying with a standard or something obscure. It is the most basic and ubiquitous standard of proving a launcher file on all desktop environments. It's an old standard. Not doing this is fundamentally broken — Reply to this email directly, view it on GitHub <#330 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BDGRKT7CMCZP5D5QS2C5F4T2EDXSJAVCNFSM6AAAAABTC36AC2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMRRHAZTONBSGY> . You are receiving this because you commented.Message ID: ***@***.***>

[alainm23]

Regardless of the fact that the implementation is for a bug related to apps that don't follow the standard, I like the idea of creating a custom class to wrap around GLib.DesktopAppInfo. It gives us the opportunity to extend it by possibly adding features specific to Pantheon.

[Gabriel-p]

This does not affect only apps as far as I can tell. I work with Python and when I create a plot and show it (plt.show()) the window that pops up is not shown in the dock which is very inconvenient

[Gabriel-p]

So the decision is to make the Dock be 10x less useful because we don't want to recognize that there are apps or workflows out there that don't behave 100% the way eOS wants?

Ok

[lenemter]

@Gabriel-p There were too many conflicts with main so I redone this here: #419. And don't be passive aggressive please, I'm really trying to get this merged in ;)