5

Should one learn the implementation of clipboard first, or drag and drop (D&D) is completely independent?

Which components contain code, which is related to D&D? (link to .svg will be the best answer)

Is it necessary to patch DE to implement "dragging to taskbar to restore window before drop" feature? If yes, then is it enough to cover Gnome, KDE and XFCE?

What are the problems with opacity/transparency of windows and controls during dragging? (What prevents WinForms Designer from being finished)?

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

How keys (Shift,Ctrl,Alt,Win) and their combinations usually work for endpoint operations modification?

Most usefull peaces from answers and various places:

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)
  • The place where you should look for cross-desktop descriptions of those features is freedesktop.org and the EWMH (Extended window manager hints) that goldilocks already linked. You don't get to decide whether the window is restored when hovering the taskbar or pager (if the user even has one). You set the hints and the taskbar decides what happens. – Leiaz Feb 8 '15 at 14:42
4

Drag n' drop API's are implemented in GUI widget libraries, which are built on top of something else (on linux, Xlib).

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

Qt and Gtk are distinct GUI libraries. If you write a GUI application (which is the only context in which drag n' drop makes sense), you choose a library, not two or three of them. I've never heard of anyone creating and maintaining both a Qt and Gtk version of something because there would be very little point: they are portable to the same set of platforms. If you have a Gtk version, it will probably run on systems that run Qt, and vice versa.

Qt and Gtk applications both will run without issue under any linux DE. They are not limited to GNOME and KDE. If you use KDE, you probably have a few Gtk apps on your desktop anyway. If you use GNOME, you might have a few Qt ones. That's how a software stack works.

While it is possible to write GUI applications using only Xlib, it's pretty unusual1 for a number of reasons; it's unportable, it defeats the purpose of modular hierarchies in software design, etc.

Part of the point of the more portable, higher level libraries (Gtk, Qt) is they abstract away the lower level, more platform specific ones such as Xlib.

Should one learn the implementation of clipboard first

I doubt the Xlib clipboard has anything to do with it, but in any case, again, there's no need to learn much about Xlib if you want write GUI applications for linux. You start with one of the higher level libraries.

If you want an introduction to the drag n' drop API for Gtk, with a quick nod to the Xlib facilities it is built upon (on systems that use Xlib), have a look here.


You've said you are interested in universalizing a feature such as "dragging to taskbar to restore window before drop". This kind of behaviour is indeed the realm of the DE or window manager (WM -- all DE's require a WM, but WM's do not require DE's), whereas the actual DnD mechanism is lower down. It's behaviour that just involves a particular kind of use case for the mechanism. However, because it is in the higher realm of the DE, it is outside the realm of the individual application. If you are writing a GUI app, this is not something you should be concerned with at all.

Linux is unlike Windows in that its desktop interfaces are heterogeneous; part of what that means is that universalizing high level behaviour like that is intentionally problematic (no one wants one ring to bind them all). It is no more appropriate to be concerned about heterogeneous window mechanics at the application level than it is to be concerned about exactly how the borders and titlebars look; the DE/WM take care of this to create an integrated look and feel that is configured by the user for the entire desktop. It is not appropriate or user friendly for individual applications to try and wrestle this control away from the end user and DE to behave in a way you want to see windows work on your choice of desktop. Because I want to use your app does not mean I also want to live by your rules WRT window behaviour. Applications don't have to be involved in that, and for the most part, should not. There is no good reason to rebel against this model; it may be distasteful to you, but it is presumably appreciated by the users of the operating system you are trying to target. Apple users would resent application programmers trying to make their desktop act like Windows, Windows users would probably not appreciate application programmers trying to make their desktop work like KDE, etc.

That said, there's nothing wrong with some kind of add-on "gestures" library -- although again, this seems like something more appropriate to implement within a DE, and some of them do have configurable gestures. You may be interested in extended window manager hints, which is an attempt to create a high level universal protocol to assist applications in invoking certain kinds of behaviour (a universal protocol would be necessary just to identify a taskbar in this context). Note that EWMH compliance is of course voluntary and will vary from WM to WM.


1. It's also possible to write GUI applications by starting with bare metal -- you create your own operating system and go from there. But again, that is not the orthodox approach.

  • I want to implement common library on top of Qt, Gtk, etc (specifically - to fix bugs in Windows.Forms on mono). In order to implement some features, like "dragging to taskbar to restore window before drop" it is necessary to take DE's into work. – user1709408 Feb 7 '15 at 21:20
  • The DE's are a level above this and have nothing to do with DnD. Gtk implements DnD; GNOME pieces are implemented using Gtk, but GNOME and Gtk are not the same thing. Qt implements DnD; KDE pieces are implemented using Qt, but Qt and KDE are not the same thing. Realistically, and I am not trying to be mean: You do not understand enough to see whether what you are talking about is 1) Meaningful, 2) Possible, 3) Worthwhile. I'll say it is none of the above. You may want to consider: XY problem. – goldilocks Feb 8 '15 at 2:37
  • Sorry if I was a bit harsh. The behavior you're describing ("dragging to taskbar to restore window") is indeed the realm of the DE or window manager, I've added a few paragraphs about what that means and how this might be approached. – goldilocks Feb 8 '15 at 13:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.