为什么某些打开的应用程序在Unity启动器中显示为“问号”？
我遇到了几个有统一发射器的程序的问题，但是在启动之后又创建了一个单独的图标。 发射器是否可以跟踪它产生的窗口以更好地组织？ 或者这是Unity本身的错误？
这可能没关系，但是这个特定的程序是单声道程序，产生的图标被列为面板。
发生了什么
这样的问题与Unity的应用程序匹配框架有关。 为了简化技术细节，程序窗口和应用程序是Ubuntu的两个独立的东西。 Ubuntu需要“猜测”哪个应用程序拥有特定窗口。 有时候猜测会失败，并且启动器中会出现一个问号。
失败可能是由于：
- BAMF中的一个错误（上面提到的应用程序匹配框架）。
- 错误的应用程序描述 （也称为“.desktop”文件）。
- 根本没有任何应用程序描述。 启动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 。
这是一个准系统的例子。 正式规范涵盖了许多高级function。
问题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 nitro）也软件中心（也许其他图标也不会）从图标打开（仅来自终端命令）。 我找到了推荐卸载并重新安装gnome软件的建议。 自从我这样做以来，整个系统已经100％稳定，没有更多的灰色图标和完美的工作。 当我在这次更改后重新启动时，它看起来很可怕 – 重启时会发出大量系统消息 – 所以请自行承担风险。
sudo apt-get autoremove gnome-software && sudo apt-get install gnome-software