我遇到了几个程序,这些程序具有统一的启动器,但是在启动后再创建一个单独的图标。发射器能否跟踪其生成的窗口以更好地组织?还是这是Unity本身的错误?
可能无关紧要,但是此特定程序是Mono程序,并且生成的图标列在面板中。
这样的问题与Unity的应用程序匹配框架有关。为了简化技术细节,程序窗口和应用程序是Ubuntu的两个独立部分。Ubuntu需要“猜测”哪个应用程序拥有特定的窗口。有时,这种猜测会失败,并且启动器中会出现一个问号。
失败的原因可能是:
问题(KeePass2)中显示的应用程序遇到了类型1问题,该问题已报告给相应的错误跟踪器。
以下示例是技术性的,面向希望自己的应用程序在Ubuntu启动器中正确显示的程序员。
为了使应用程序与Unity集成(也就是说,可以在Dash中搜索并放置在启动器中),它需要具有一个桌面条目。这样的条目被放置在/usr/share/applications/
,/usr/local/share/applications/
和$HOME/.local/share/applications/
(后两者是用于第三方软件,系统范围和用户只分别地)。它们以.desktop
扩展名结尾并遵循以下基本格式:
[Desktop Entry]
Type=Application
Name=My Application's Name
Icon=/file/path/of/my/icon
Exec=/file/path/of/my/executable
此项通过调用Exec
可执行文件来启动程序。每当该程序显示窗口或对话框时,Unity都会注意到其可执行文件“属于”此应用程序描述,Name
并Icon
在启动器中使用给定的和。
这是一个准系统的例子。在正式的规范涵盖了许多先进的功能。
让我们假设它my_app.desktop
存在于有效的应用程序目录中,但是:
/file/path/of/my/icon
在文件系统中不存在。/file/path/of/my/icon
不是图像。在上述任何一种情况下,Ubuntu将无法在启动器中正确列出应用程序窗口。
从Ubuntu 11.10开始,BAMF存在许多错误,这些错误会阻止正确的应用程序匹配。常见的(临时)陷阱包括:
Exec
路径是一个符号链接,而不是一个常规文件在这些情况下,程序员别无选择,只能使用替代方法,例如删除符号链接抽象或直接链接到可执行文件。桌面条目规范本身都不要求这些。
本文收集自互联网,转载请注明来源。
如有侵权,请联系[email protected] 删除。
我来说两句