¿Cómo funciona Drag & Drop en Linux?

¿Debería aprender primero la implementación del portapapeles, o drag and drop (D & D) es completamente independiente?

¿Qué componentes contienen código, que está relacionado con D & D? (El enlace a .svg será la mejor respuesta)

¿Es necesario parchear DE para implementar la function "arrastrando a la barra de tareas para restaurar la window antes de soltar"? En caso afirmativo, ¿es suficiente para cubrir Gnome, KDE y XFCE?

¿Cuáles son los problemas con la opacidad / transparencia de windows y controles durante el arrastre? (¿Qué impide que el Diseñador de WinForms se termine)?

https://bugzilla.novell.com/show_bug.cgi?id=323819 

¿Cómo funcionan las teclas ( Shift , Ctrl , Alt , Win ) y sus combinaciones para la modificación de las operaciones del punto final?

Paces más útiles de respuestas y varios lugares:

 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) 

Las API Drag n 'drop se implementan en las bibliotecas de widgets GUI, que están construidas sobre algo más (en Linux, Xlib ).

¿Es suficiente apuntar a Qt (KDE), Gtk (Gnome) y XFC (XFCE)?

Qt y Gtk son bibliotecas de GUI distintas. Si escribe una aplicación GUI (que es el único context en el que tiene sentido drag and drop), elige una biblioteca , no dos o tres de ellas. Nunca había escuchado que alguien creara y mantuviera versiones Qt y Gtk de algo porque no tendría mucho sentido: son portátiles para el mismo set de plataforms. Si tiene una versión Gtk, probablemente se ejecutará en sistemas que ejecutan Qt, y viceversa.

Las aplicaciones Qt y Gtk se ejecutarán sin problemas en cualquier dispositivo Linux DE. No están limitados a GNOME y KDE. Si usa KDE, probablemente tenga algunas aplicaciones Gtk en su escritorio de todos modos. Si usa GNOME, puede tener algunos Qt. Así es como funciona una stack de software .

Si bien es posible escribir aplicaciones de GUI utilizando solo Xlib, es bastante inusual 1 por varias razones; es poco práctico, derrota el propósito de las jerarquías modulares en el layout de software, etc.

Parte del punto de las bibliotecas más portátiles y de más alto nivel (Gtk, Qt) es que abstraen el nivel más bajo, más específicos de la plataforma, como Xlib.

¿Debería uno aprender primero la implementación del portapapeles?

Dudo que el portapapeles Xlib tenga algo que ver con eso, pero en cualquier caso, una vez más, no hay necesidad de aprender mucho sobre Xlib si quieres escribir aplicaciones GUI para Linux. Empiezas con una de las bibliotecas de nivel superior.

Si desea una introducción a la API de drag n drop para Gtk, con un guiño rápido a las instalaciones Xlib sobre las que está basado (en sistemas que usan Xlib), eche un vistazo aquí .


Has dicho que estás interesado en universalizar una característica como "arrastrar a la barra de tareas para restaurar la window antes de soltar". Este tipo de comportamiento es, de hecho, el dominio de DE o del administrador de windows (WM: todos los DE requieren un WM , pero los WM no requieren DE), mientras que el mecanismo DnD real está más abajo. Es un comportamiento que solo involucra un tipo particular de caso de uso para el mecanismo. Sin embargo, debido a que está en el ámbito superior de la ED, está fuera del ámbito de la aplicación individual. Si está escribiendo una aplicación GUI, esto no es algo que deba preocuparse en absoluto.

Linux se diferencia de Windows en que sus interfaces de escritorio son heterogéneas; parte de lo que eso significa es que universalizar un comportamiento de alto nivel como ese es intencionalmente problemático (nadie quiere un anillo que los vincule a todos). No es más apropiado preocuparse por la mecánica de windows heterogénea en el nivel de aplicación que preocuparse por cómo se ven exactamente los bordes y las barras de título; DE / WM se encarga de esto para crear una apariencia integrada que el usuario configura para todo el escritorio. No es apropiado o fácil de usar para las aplicaciones individuales tratar de controlar este control desde el usuario final y DE para que se comporte de la manera que desee para que Windows funcione en su elección de escritorio. Porque quiero usar su aplicación no significa que también quiera vivir según las reglas de comportamiento de la window WRT. Las aplicaciones no tienen que estar involucradas en eso, y en su mayor parte, no deberían. No hay una buena razón para rebelarse contra este model; puede ser desagradable para usted, pero es presumiblemente apreciado por los usuarios del sistema operativo al que está tratando de llegar. A los usuarios de Apple les molestaría que los progtwigdores de aplicaciones intenten hacer que su computadora de escritorio actúe como Windows, los usuarios de Windows probablemente no apreciarían a los progtwigdores de aplicaciones que intentan hacer que su escritorio funcione como KDE, etc.

Dicho esto, no hay nada de malo con algún tipo de biblioteca adicional de "gestos", aunque, de nuevo, esto parece ser algo más apropiado de implementar dentro de un DE, y algunos de ellos tienen gestos configurables. Puede que le interesen las sugerencias extendidas de administrador de windows , que es un bash de crear un protocolo universal de alto nivel para ayudar a las aplicaciones a invocar ciertos types de comportamiento (sería necesario un protocolo universal solo para identificar una barra de tareas en este context). Tenga en count que el cumplimiento de EWMH es, por supuesto, voluntario y variará de WM a WM.


1. También es posible escribir aplicaciones GUI comenzando con bare metal: usted crea su propio sistema operativo e inicia desde allí. Pero, de nuevo, ese no es el enfoque ortodoxo.