☰

拖放在 Linux 中如何工作？

tag-icon • tag-icon desktop-environment clipboard drag-and-drop
拖放在 Linux 中如何工作？

应该先学习剪贴板的实现，还是拖放（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)

答案1

拖放 API 在 GUI 小部件库中实现，这些库构建在其他东西之上（在 Linux 上，扩展库）。

针对 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 应用程序——您创建自己的操作系统并从那里开始。但同样，这不是正统的方法。

相关内容