Local padrão para ícones indicadores não padrão?
Não há local padrão onde esses ícones são armazenados. Qualquer aplicativo (desenvolvedor) pode armazená-los onde for considerado apropriado.
No entanto , a boa notícia é que os indicadores geralmente não instalam listas intermináveis de arquivos e imagens. Podemos limitar nossa pesquisa (além de procurar no código) procurando na saída do comando:
dpkg-query -L <packagename>
No meu exemplo de
dpkg-query -L placesfiles
isso produziria, entre outras, as seguintes imagens:
/opt/placesfiles/images/dir_icon.png
/opt/placesfiles/images/placesfiles64.png
/usr/share/pixmaps/placesfiles.png
... O que tornaria a pesquisa bastante limitada.
Do homem dpkg-query
:
-l, --list [package-name-pattern...]
List packages matching given pattern. If no package-name-pattern
is given, list all packages in /var/lib/dpkg/status, excluding
the ones marked as not-installed (i.e. those which have been
previously purged). Normal shell wildcard characters are allowed
in package-name-pattern. Please note you will probably have to
quote package-name-pattern to prevent the shell from performing
filename expansion. For example this will list all package names
starting with “libc6”:
No caso do Radiotray , encontrei os seguintes .png
arquivos (em execução dpkg-query -L radiotray | grep png
):
/usr/share/radiotray/images/radiotray_connecting.png
/usr/share/radiotray/images/radiotray_on.png
/usr/share/radiotray/images/radiotray_off.png
/usr/share/radiotray/images/radiotray.png
/usr/share/pixmaps/radiotray.png
Se realmente precisamos descobrir, pesquisando o código
... podemos procurar nos arquivos instalados (dentro) por correspondências da string "icon". Muitos dos indicadores são escritos em uma das linguagens de script (como python
), o que significa que são muito bem pesquisáveis.
Um exemplo
Novamente usando o radiotray
exemplo
dpkg-query -L radiotray | xargs grep icon
na saída encontramos ao:
/usr/lib/python2.7/dist-packages/radiotray/SysTrayGui.py
self.icon.set_from_file(APP_ICON_CONNECT)
Examinando o arquivo SysTrayGui.py
, podemos ver:
from lib.common import APPNAME, APPVERSION, APP_ICON_ON, APP_ICON_OFF, APP_ICON_CONNECT, APP_INDICATOR_ICON_ON, APP_INDICATOR_ICON_OFF
A partir disso, podemos concluir que os ícones mencionados são definidos no módulo common
dentro do diretório (sub) lib
. (Veja aqui como o python encontra os módulos, seção Subdiretórios )
Neste módulo, podemos ler a seção:
# Media path
if os.path.exists(os.path.abspath('../data/images/')):
IMAGE_PATH = os.path.abspath('../data/images/')
else:
IMAGE_PATH = '%s/%s/images' % (datadir, APPDIRNAME)
# Images
APP_ICON = os.path.join(IMAGE_PATH, 'radiotray.png')
APP_ICON_ON = os.path.join(IMAGE_PATH, 'radiotray_on.png')
APP_ICON_OFF = os.path.join(IMAGE_PATH, 'radiotray_off.png')
APP_ICON_CONNECT = os.path.join(IMAGE_PATH, 'radiotray_connecting.gif')
APP_INDICATOR_ICON_ON = "radiotray_on"
APP_INDICATOR_ICON_OFF = "radiotray_off"
APP_INDICATOR_ICON_CONNECT = "radiotray_connecting"
...E aqui estamos...
Situações excepcionais
Com a prática de todos os meus indicadores, consegui encontrar os ícones correspondentes usando o (s) método (s) acima.
No entanto, é possível compilar imagens juntamente com o código em um único executável. Não é necessário explicar que, nesses casos, você não encontrará uma imagem separada, nem poderá substituí-la sem editar o código e recompilar.
O caso da owncloud parece ser esse o caso. O uso dos métodos acima mostrou que um conjunto de ícones foi instalado no interior /usr/share/icons/hicolor/<size>/apps
. Nenhum desses ícones acaba sendo usado no indicador no ubuntu .
O OP trabalhou bastante antes (e depois) ele fez essa pergunta. Um deles era correr:
gdbus call --session --dest com.canonical.indicator.application --object-path /com/canonical/indicator/application/service --method com.canonical.indicator.application.service.GetApplications
... o que nos fornece algumas informações úteis. A saída incluiu uma seção:
('146028888067', 2, 'org.kde.StatusNotifierItem-22055-1', '/StatusNotifierItem/menu', '/tmp/iconcache-50ePXx', '', '', '', 'owncloud', 'ownCloud')
Olhando para o diretório /tmp/iconcache-50ePXx
, encontrei os ícones exatos que foram usados pelo indicador:
... o que parece provar que esses ícones são gerados em tempo real; fechar owncloud faz com que o diretório e seus ícones desapareçam.
Acabou sendo possível alterar o ícone do indicador substituindo estes ícones:
o que prova que esses são realmente os ícones que estávamos procurando.
Entretanto, para automatizar o que eu fiz manualmente, seria necessário um script / wrapper, pois o nome do diretório criado é alterado toda vez que o owncloud é iniciado. A opção mais conveniente seria, obviamente, que o código do owncloud-client fosse alterado.
Veja também nossa discussão aqui .
Continua...
dpkg -L
faz a mesma coisa?