[Lazarus] Drag, Dock and Layout

[Paul Ishenin]

Hans-Peter Diettrich wrote:
> In my attempt to understand the drag/dock implementation of Lazarus, I 
> came across some general questions. Is there a developer who is familiar 
> with the current implementation of these things?

Current implementation has been done by Marius, Mattias and me.

> 1. Model
> --------
...
> position, to adjust the drag image appropriately. Depending on DragKind, 
> the target should have UseDockManager=True or react on DockOver for 
> dkDock, or it should react on DragOver for dkDrag. The search for a 

It is not UseDockManager = True but DockSite = True .


> 2. Platform support
> -------------------
> 
> 2.1 Determination of the component at the mouse position.
> This feature should be available on every platform, since the system 
> itself must know which target window has to be notified of mouse events.
> Using this feature should allow to easily fill the white spots in the 
> current determination of the dock site.

Yes, this is available on all platforms. LCL gives apropriate functions 
to determine Control/WinControl at mouse position:
- FindControlAtPosition
- FindLCLWindow
- FindLCLControl
...

> 2.2 Mouse capture
> Every platform should support kind of mouse capture, i.e. sending 
> messages to a dedicated capture window, instead of informing the window 
> under the mouse position. Information about active capturing and 
> dragging should be stored in a dedicated place (Application object?), so 
> that it can canceld easily and properly, whenever required. I dunno 
> about the synchronization between the IDE and a debugger and debugged 
> application, but I assume that there exists according communication, 
> which should allow to properly cancel unrecoverable actions.

This is available on win32, wince, gtk1, gtk2 and qt. Dont know about 
carbon but suspect that too.

> 2.3 Visual feedback
> Every platform should at least support mouse pointer shapes, for visual 
> feedback about the actual target of a drag action. This primitive kind 
> of feedback also requires no special management of temporary images on 
> the screen, or in design state. More elaborated feedback can be added 
> for platforms with better support for dragging operations (drag images 
> etc.). Question is: how to deal with platform specific features in the LCL?

Yes, every platform (except wince iirc) support different mouse 
pointers. This is already implemented. Also if you look at 
lcl\interfaces code you will find that DragImageList is implemented on 
most platforms (though not working perfectly on evert platform) and 
DrawDefaultDockImage is done on most platforms too. LCL uses 
DrawDefaultDockImage to draw dock frame.

> Another kind of standard support could use the hint-window mechanism, 
> and drag around such a temporary window. Then the target of a dock 
> operation only had to supply the dock zone (RECT), so that the dragged 
> window can be properly resized and repositioned. This solution is really 
> useful only with transparent windows, which do not hide the possible 
> dock targets, both from the sight of the user, nor from the sight of the 
> system in the determination of the drag target. Perhaps not a good idea?

It is a problem to understand your idea at first :)

> 3. Dock zones
> -------------
...
> 3.1 Dock sites
> IMO dock sites could be implemented in dedicated container controls, 
> which react on docking events at all. These controls also can implement 
> support for floating themselves, e.g. as detachable frames or toolbars. 
> Delphi compatibility will not be affected, but a choice of ready-to-use 
> docking components can simplify the design of new Lazarus applications.

Mattias already tried to do this with anchor-docking?

> 3.2 Dockable components
> IMO the docking of simple components is useful only at design time, when 
> components are dropped from the toolbar onto a form. Docking at runtime 
> can be restricted to forms and other floatable components, like toolbars 
> or frames. Undocking of docked components requires that the structure of 
> the docked components stays intact, i.e. forms or frames must be 
> undocked in their original composition and framing. This forbids 
> unpacking the components of a form, when the form is docked. When a form 
> or frame instead is docked entirely, including a (small) title bar as in 
> Delphi, every docked item can be restored exactly into it's previous 
> appearance and behaviour, what currently simply is impossible.

When the form is docked - it stay as form but loses titlebar and has 
parent - nothing else happen with it. On different platforms this 
achieved using different means. Dont understand what is currently imposible.

> 3.3 Determination of the docking position.
> I'll not go into details here, it's mostly a matter of implementation of 
> the an docking manager. The default (tree) docking manager 
> implementation lacks many docking features which can hardly be added, or 
> even be made work, without a deep redesign of all related classes and 
> other data types.

What does it miss? Have you seen TLazDockTree class?

> Therefore I'd suggest a separation of any but the abstract TDockManager 
> from the Controls unit, eliminating the need for a rebuild of the IDE 
> after every change to the Controls unit. It also will show up the 
> undocumented dependencies between controls, messages, and the code that 
> implements the details of dragging and docking. I'm willing to perform 
> that separation myself, if no official developer is willing to do so - 
> but I'm not willing to spend much time when afterwards the new structure 
> doesn't become part of the trunk.

Dont see why it will not be commited if you improve current code and 
break nothing? Lazarus and LCL is always open for improvements. While 
doing your redesign please have in mind that we need to stay compatible 
with delphi.

ps:
If you need to discuss something in a more instant mode then use our irc 
channel.

Best regards,
Paul Ishenin.