Por que as configurações de proxy funcionam no terminal mas não num launcher de desktop

Você exporta um proxy num terminal. Um comando iniciado ali usa-o. Clicar no ícone do desktop ainda dá outro caminho. O ícone não se tornou filho desse terminal.

Uma sessão de desktop inicia aplicações através da sua própria maquinaria de arranque. Esses processos herdam esse ambiente, não cada edição posterior feita dentro de uma shell não relacionada. Isso pode explicar uma diferença sem provar que o pacote da aplicação está defeituoso.

Exec é uma descrição de comando, não um script de shell

A especificação Desktop Entry define um executável e argumentos para Exec. Não promete expansão de variáveis de shell nem comandos internos da shell.

Para um programa externo que lê a variável de ambiente em causa, um arranque deliberadamente delimitado pode ter esta forma:

Exec=env https_proxy=http://proxy.example:8080 /path/to/application

Substitua tanto o ponto final como o executável. Isto demonstra a entrada do arranque, não a garantia de que uma aplicação arbitrária leia essa variável. Um navegador com a sua própria política de proxy explícita pode ainda escolher outra fonte de configuração. Para o Chrome, guarde o seu argumento de proxy num launcher de utilizador.

Não escreva Exec=export ... e espere que o desktop o interprete como a sua shell de início de sessão. Tenha também em conta as regras de aspas e os códigos de campo suportados da entrada do desktop; são outro analisador.

Verifique se foi arrancado algo novo

Algumas aplicações enviam o pedido para uma instância já em execução. Algumas entradas usam ativação por D-Bus, que tem o seu próprio caminho de arranque. Um novo clique no ícone não estabelece um processo novo com o ambiente Exec acabado de editar.

Identifique a instância que faz o pedido e a configuração que realmente possui. Um arranque novo e controlado pode estreitar a comparação quando for adequado. Evite reinstalar a aplicação antes de estabelecer se o ambiente pretendido alguma vez chegou até ela.