[Lazarus] Generalized DragDrop
Michael Van Canneyt
michael at freepascal.org
Sat Jan 22 16:04:34 CET 2011
On Sat, 22 Jan 2011, Hans-Peter Diettrich wrote:
> In fpGUI Graeme implemented an interface for inter-process dragging. It would
> be nice to have a similar interace in the LCL, that extends the current
> intra-process dragging.
While it is correct that Graeme did this, I still have not seen in action.
i.e. I have used the application-specific DnD, but I wouldn't know how to
handle the intra-app DnD.
> Why that?
> - A more general approach could solve the known problem with docking forms,
> by including dragging by the window manager.
> - Drag-drop of files or other objects as an alternative to an OpenDialog.
>
> - Embedding of shared objects (COM, CORBA...)
>
> What's required?
>
> - A generalization of the DragManager, so that visual (DragImage...) and
> application feedback (events) are not restricted to application-internal drag
> sources and implementations. This is not hard to do, all that can be handled
> in the already existing or added specialized DragObjects, instead of the
> (superfluous) DragPerformers.
>
> - A DragObject should include a SourceType property, so that the targets can
> handle more source types, e.g. filenames or COM/CORBA objects, in addition to
> controls. Mime types (strings or enum) can be used for that purpose. Further
> information for inter-process dragging can be added (source PID, HWND...), so
> that an application can distinguish internal references (to controls...) from
> references to objects in other processes.
>
> - The event handlers must have access to the extended source information.
> This is also no problem, since only one drag operation can be active at any
> time, so that a global DragObject reference can be used everywhere. A
> predefined DragObject can be used whenever an external object is being
> dragged over an application form.
>
> - More drag and drop types should be defined, in addition to "drop" and
> "dock", e.g. "open files", "link" or "embed". Eventually specialized drag
> targets must register themselves, for e.g. accepting files or embedding
> objects, in addition do DockSite registration.
I'm all for it.
Although I'm not sure that this can be implemented in a cross-platform way.
On Windows, the intra-app drag/drop is handled using OLE/DDE.
On Linux, there is no such thing, and I think it depends on the used desktop software (KDE vs Gnome).
I don't know how it is done in Mac.
But your suggestion is at least a step in the right direction.
I would implement support in 2 objects:
TFileDragObject (external files, as dropped by file managers)
TExternalDragObject (external app DnD)
Both are created whenever an external DnD is found.
I don't like the idea of SourceType as a general property. I would make it an enumerated
(stInternal,stFiles,stExternal) and the TExternalDragObject object can have a MimeTypes property.
The TFileDragObject can have a 'FileNames' property of type TStrings; it's all it needs.
Putting everything in the base class is IMHO not necessary, and only complicates things.
Michael.
More information about the Lazarus
mailing list