Você pode usar um script de shell in-line para calcular o caminho:
Exec=sh -e -c "exec \"\$(dirname \"\$0\")/some_app\"" %k
Sim, dois níveis de escape são necessários.
Os arquivos .desktop tornaram-se o padrão de fato para acessar facilmente aplicativos em desktops Linux , com os executáveis não sendo facilmente inicializáveis a partir da GUI e muitos lançadores não usam o ícone do aplicativo, mas apenas o ícone especificado no arquivo .desktop.
Por que, então, não parece possível usar arquivos .desktop que especifiquem um caminho relativo para seu executável e há uma maneira de contornar isso?
Ao enviar um software que não é necessário forçar os usuários a instalar, os caminhos relativos são a única maneira de ativar isso.
O AppImage parece contornar isso instalando um arquivo .desktop ao ser executado pela primeira vez pelo usuário, o que parece ser uma maneira desajeitada de ativar ícones e ativadores de software com um caminho flexível. Caminhos relativos seriam uma maneira muito melhor de ir. Por que essa solução não é possível em desktops do Linux? Parece improvável que isso seja uma mera supervisão, mas, ao invés disso, estou sentindo falta da razão mais profunda por trás dessa decisão.
Você pode usar um script de shell in-line para calcular o caminho:
Exec=sh -e -c "exec \"\$(dirname \"\$0\")/some_app\"" %k
Sim, dois níveis de escape são necessários.
Para apreciar a situação, pergunte-se: "Relativo a quê?". Os arquivos .desktop são para uso em contextos de GUI, para os quais nenhum caminho base pode ser assumido para construir um caminho absoluto a partir de qualquer caminho relativo que você possa considerar colocar no arquivo .desktop .
Caminhos relativos são úteis apenas quando podem ser convertidos para um local definido (o caminho absoluto) e isso requer um ponto de referência. que não pode ser assumido em nenhum contexto genérico da GUI.