Como o Drag & Drop funciona no linux?

5

Um deve aprender a implementação da área de transferência primeiro, ou arrastar e soltar (D & D) é completamente independente?

Quais componentes contêm código relacionado a D & D? (link para .svg será a melhor resposta)

É necessário corrigir o DE para implementar o recurso "arrastando para a barra de tarefas para restaurar a janela antes de soltar"? Se sim, então é o suficiente para cobrir o Gnome, KDE e XFCE?

Quais são os problemas com a opacidade / transparência de janelas e controles durante o arrasto? (O que impede que o WinForms Designer seja concluído)?

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

Como as teclas ( Shift , Ctrl , Alt , Win ) e suas combinações geralmente funcionam para operações de endpoint modificação?

Peças mais úteis de respostas e vários 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)
    
por user1709408 07.02.2015 / 19:45

1 resposta

4

As APIs arrastar e soltar são implementadas em bibliotecas de widgets GUI, que são construídas em cima de outra coisa (no linux, Xlib ).

Is targetting to Qt (KDE), Gtk (Gnome) and XFC(XFCE) enough ?

O Qt e o Gtk são bibliotecas GUI distintas. Se você escrever um aplicativo GUI (que é o único contexto no qual arrastar e soltar faz sentido), você escolhe uma biblioteca , e não dois ou três deles. Eu nunca ouvi falar de ninguém criando e mantendo tanto uma versão Qt quanto uma versão Gtk de algo, porque não haveria muito sentido: elas são portáveis para o mesmo conjunto de plataformas. Se você tem uma versão Gtk, ela provavelmente rodará em sistemas que rodam o Qt, e vice-versa.

Os aplicativos Qt e Gtk serão executados sem problemas em qualquer DE do Linux. Eles não estão limitados ao GNOME e ao KDE. Se você usa o KDE, provavelmente tem alguns aplicativos Gtk em sua área de trabalho. Se você usa o GNOME, você pode ter alguns Qt. Isso é como funciona uma pilha de software .

Embora seja possível escrever aplicações GUI usando apenas o Xlib, é bastante incomum 1 por vários motivos; não é suportável, derrota a finalidade das hierarquias modulares no design de software, etc.

Parte do ponto das bibliotecas mais portáteis e de nível superior (Gtk, Qt) é abstrair o nível inferior, mais aquelas específicas da plataforma, como o Xlib.

Should one learn the implementation of clipboard first

Eu duvido que a área de transferência do Xlib tenha algo a ver com isso, mas em qualquer caso, novamente, não há necessidade de aprender muito sobre o Xlib se você quiser escrever aplicações GUI para o Linux. Você começa com uma das bibliotecas de nível superior.

Se você quiser uma introdução à API arrastar e soltar para o Gtk, com um rápido aceno para as facilidades do Xlib em que ele é construído (em sistemas que usam o Xlib), dê uma olhada aqui .

Você disse que está interessado em universalizar um recurso como "arrastar para a barra de tarefas para restaurar a janela antes de soltar". Esse tipo de comportamento é de fato o domínio do DE ou do gerenciador de janelas (WM - todos os DEs requerem um WM , mas os WMs não requerem DE), enquanto o mecanismo DnD é mais baixo. É um comportamento que envolve apenas um tipo específico de caso de uso para o mecanismo. No entanto, por estar no domínio superior do DE, está fora do domínio do aplicativo individual. Se você estiver escrevendo um aplicativo GUI, isso não é algo com o qual você deve se preocupar.

O Linux é diferente do Windows, pois suas interfaces de desktop são heterogêneas; parte do que isso significa é que universalizar um comportamento de alto nível como esse é intencionalmente problemático (ninguém quer um anel para ligar todos). Não é mais apropriado se preocupar com a mecânica de janelas heterogêneas no nível da aplicação do que se preocupar com exatamente como as bordas e as barras de título se parecem; o DE / WM cuida disso para criar uma aparência integrada e sentir que é configurada pelo usuário para toda a área de trabalho. Não é apropriado ou amigável para aplicações individuais tentar e lutar este controle longe do usuário final e DE se comportar de uma maneira que você quer ver o Windows funcionar em sua sua opção de desktop. Porque eu quero usar o seu aplicativo não significa que eu também quero viver de acordo com o seu comportamento de janela regras WRT. As aplicações não precisam estar envolvidas nisso e, na maior parte, não devem. Não há boas razões para se rebelar contra esse modelo; pode ser desagradável para você, mas é presumivelmente apreciado pelos usuários do sistema operacional que você está tentando atingir. Os usuários da Apple se ressentiriam dos programadores de aplicativos que tentavam fazer com que seus desktops agissem como o Windows, os usuários do Windows provavelmente não apreciariam os programadores de aplicativos que tentam fazer com que seus desktops funcionem como o KDE, etc.

Dito isso, não há nada de errado com algum tipo de biblioteca de "gestos" de complementos - embora, mais uma vez, isso pareça algo mais apropriado para implementar em um DE e alguns deles têm gestos configuráveis. Você pode estar interessado em dicas do gerenciador de janelas estendidas , que é uma tentativa de criar um alto protocolo universal de nível para auxiliar os aplicativos a invocar certos tipos de comportamento (um protocolo universal seria necessário apenas para identificar uma barra de tarefas neste contexto). Observe que a conformidade com o EWMH é obviamente voluntária e variará de WM para WM.

1. Também é possível escrever aplicativos GUI iniciando com o bare metal - você cria seu próprio sistema operacional e a partir daí. Mas, novamente, essa não é a abordagem ortodoxa.

    
por 07.02.2015 / 21:54