为什么某些打开的应用程序在Unity启动器中显示为“问号”？

我遇到了几个程序，这些程序具有统一的启动器，但是在启动后创建一个单独的图标。发射器能否跟踪其生成的窗口以更好地组织？还是这是Unity本身的错误？

可能无关紧要，但是此特定程序是Mono程序，并且生成的图标列在面板中。

发生了什么

这样的问题与Unity的应用程序匹配框架有关。为了简化技术细节，程序窗口和应用程序是Ubuntu的两个独立部分。Ubuntu需要“猜测”哪个应用程序拥有特定的窗口。有时，这种猜测会失败，并且启动器中会出现一个问号。

失败的原因可能是：

1. 中的一个错误BAMF（应用匹配框架上面提到的）。
2. 错误的应用程序描述（也称为“ .desktop”文件）。
3. 根本没有任何应用程序描述。启动Windows的可执行文件本身并不具有此元数据。

问题（KeePass2）中显示的应用程序遇到了类型1问题，该问题已报告给相应的错误跟踪器。

问题实例

以下示例是技术性的，面向希望自己的应用程序在Ubuntu启动器中正确显示的程序员。

问题3 –没有应用程序描述

为了使应用程序与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在启动器中使用给定的和。

这是一个准系统的例子。在正式的规范涵盖了许多先进的功能。

问题2 –错误的应用程序描述

让我们假设它my_app.desktop存在于有效的应用程序目录中，但是：

• /file/path/of/my/icon 在文件系统中不存在。
• /file/path/of/my/icon 不是图像。
• 该条目使用了一些错误的语法或无效的标签。

在上述任何一种情况下，Ubuntu将无法在启动器中正确列出应用程序窗口。

问题1 – BAMF中的错误

从Ubuntu 11.10开始，BAMF有许多错误，阻止正确的应用程序匹配。常见的（临时）陷阱包括：

• 该Exec路径是一个符号链接，而不是一个常规文件
• 可执行文件是启动主可执行文件的脚本。

在这些情况下，程序员别无选择，只能使用替代方法，例如删除符号链接抽象或直接链接到可执行文件。桌面条目规范本身都不要求这些。

如果已设置WM_CLASS属性，则窗口只能与应用程序匹配。要在X11中执行此操作，请使用：

XSetClassHint( display, window, &class_hints );

您需要将指针传递给具有字段“ res_name”和“ res_class”的XClassHint结构。

我在16.04上遇到了一些问题，包括灰色图标，有时触摸板会变得不稳定（Acer V15硝基），软件中心（也许还有其他图标）也无法从该图标打开（仅从终端命令打开）。我在某处找到了建议，以卸载并重新安装gnome软件。自从我这样做以来，整个系统一直都是100％稳定的，不再显示灰色图标，并且可以正常工作。进行此更改后，当我重新启动时，最初看起来很恐怖-重新启动时会有很多系统消息-这样做的后果自负。

sudo apt-get autoremove gnome-software && sudo apt-get install gnome-software