use*_*408 6 desktop-environment clipboard drag-and-drop
应该先学习剪贴板的实现，还是拖放（D&D）完全独立？
哪些组件包含与 D&D 相关的代码？（链接到 .svg 将是最佳答案）
是否需要打补丁 DE 来实现“拖拽到任务栏以在拖放前恢复窗口”功能？如果是，那么是否足以涵盖 Gnome、KDE 和 XFCE？
拖动过程中窗口和控件的不透明度/透明度有哪些问题？（是什么阻止了 WinForms Designer 完成）？
https://bugzilla.novell.com/show_bug.cgi?id=323819
键 ( Shift, Ctrl, Alt, Win) 及其组合通常如何用于端点操作修改？
来自答案和各个地方的最有用的和平：
The X11 drag and drop protocol is called XDND:
http://www.newplanetsoftware.com/xdnd
API which gives an access to the protocol implementation (is it Xlib?):
https://en.wikipedia.org/wiki/X_Window_selection
Gtk (uses Xlib):
https://wiki.gnome.org/GnomeLove/DragNDropTutorial
Gtk# (uses Gtk):
https://github.com/mono/gtk-sharp/blob/master/sample/TestDnd.cs
http://my.safaribooksonline.com/book/programming/mono/0596007922/gtksharp/monoadn-chp-4-sect-8
mono WinForms implementation (Uses Gtk# ?)
http://www.mono-project.com/docs/gui/winforms/
D&D in client application (uses WinForms):
http://zetcode.com/gui/csharpwinforms/dragdrop/
guides to overview use cases:
https://en.wikipedia.org/wiki/Human_interface_guidelines
("four-finger drag" operation and similar things)
拖放 API 是在 GUI 小部件库中实现的，这些小部件库构建在其他东西之上（在 linux 上，Xlib）。
以 Qt (KDE)、Gtk (Gnome) 和 XFC(XFCE) 为目标就足够了吗？
Qt 和 Gtk 是不同的 GUI 库。如果您编写一个 GUI 应用程序（这是唯一可以拖放操作的上下文），您可以选择一个库，而不是其中的两个或三个。我从来没有听说过有人创建和维护某个东西的 Qt 和 Gtk 版本，因为这没什么意义：它们可以移植到同一组平台上。如果您有 Gtk 版本，它可能会在运行 Qt 的系统上运行，反之亦然。
Qt 和 Gtk 应用程序都可以在任何 Linux DE 下正常运行。它们不仅限于 GNOME 和 KDE。如果您使用 KDE，无论如何您的桌面上可能都有一些 Gtk 应用程序。如果您使用 GNOME，您可能会使用一些 Qt。这就是软件堆栈的工作方式。
虽然可以仅使用 Xlib 编写 GUI 应用程序，但由于多种原因，这非常不寻常1；它是不可移植的，它违背了软件设计中模块化层次结构的目的等。
更可移植、更高级别的库（Gtk、Qt）的部分要点是它们抽象出更低级别、更特定于平台的库，例如 Xlib。
应该先学习剪贴板的实现
我怀疑 Xlib 剪贴板与它有什么关系，但无论如何，如果您想为 linux 编写 GUI 应用程序，则无需了解更多有关 Xlib 的知识。您从更高级别的库之一开始。
如果您想了解 Gtk 的拖放 API，并快速了解它所构建的 Xlib 工具（在使用 Xlib 的系统上），请查看此处。
您已经说过您对通用化功能感兴趣，例如“拖动到任务栏以在放下之前恢复窗口”。这种行为确实是 DE 或窗口管理器的领域（WM——所有DE 都需要 WM，但 WM 不需要 DE），而实际的 DnD 机制较低。它的行为只涉及该机制的一种特定用例。但是，因为它在DE的更高领域，所以它在个人应用程序的领域之外。如果您正在编写 GUI 应用程序，这根本不是您应该关心的事情。
Linux 与 Windows 不同，它的桌面界面是异构的。这部分意味着普遍化像这样的高级行为是故意有问题的（没有人希望一个环将它们全部绑定）。关注应用程序级别的异构窗口机制并不比关注边框和标题栏的外观更合适。DE/WM 负责创建由用户为整个桌面配置的集成外观和感觉。单个应用程序试图将这种控制权从最终用户和 DE 那里争取到您希望看到 Windows 在您的系统上运行的方式是不合适的或用户友好的。桌面的选择。因为我想使用你的应用并不意味着我也想遵守你的 WRT 窗口行为规则。应用程序不必参与其中，而且在大多数情况下，不应参与其中。没有充分的理由反对这种模式；它可能会让您反感，但您尝试定位的操作系统的用户可能会欣赏它。苹果用户会讨厌应用程序员试图让他们的桌面像 Windows 一样工作，Windows 用户可能不会喜欢应用程序员试图让他们的桌面像 KDE 一样工作，等等。
也就是说，某种附加的“手势”库没有任何问题——尽管同样，这似乎更适合在 DE 中实现，其中一些确实具有可配置的手势。您可能对扩展窗口管理器提示感兴趣，它试图创建一个高级通用协议来帮助应用程序调用某些类型的行为（通用协议对于在这种情况下识别任务栏是必要的）。请注意，EWMH 合规性当然是自愿的，并且会因 WM 的不同而有所不同。
1. 也可以从裸机开始编写 GUI 应用程序——您创建自己的操作系统并从那里开始。但同样，这不是正统的方法。