Create fake app info for unknown windows #330
Conversation
|
I'm really nervous about implementing workarounds for apps that don't follow standards and the new bugs that might create |
|
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. 🤷 |
|
@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. |
|
@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. |
|
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. |
I get it, standards are nice for those that follows them as long as it is clear this is a fallback and eOS is not to blame for anything missing but doing best it can |
|
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 |
|
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:
***@***.***>
|
|
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. |
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.