[Lazarus] Drag, Dock and Layout

[Hans-Peter Diettrich]

Paul Ishenin schrieb:

Thanks for your hints on the platforms :-)

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

Right, I'm just what is possible, and how it could be done without 
restriction to my only well known platform (Windows).


>> 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?

To some degree (no drag-dock...), and I do not yet like that layout 
model, because it looks too irregular to me. From my experience with 
layouts (and Oberon) I prefer strict horz/vert arrangement with a 
transparent management with regards to resizing etc.

I also don't understand why every TWinControl should have docking 
capabilites, and prefer a strict separation of dedicated container 
controls (forms, panels...) from other controls. But okay, if somebody 
has other ideas, I'll not block additional implementations...



>> 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.

In my docking experiments with Lazarus I found no way to undock a docked 
form again :-(

Also I couldn't make properly work docking of multiple forms into a 
single dock site. Does there exist a working demo project for drag-dock? 
I'd be interested in a program that allows to create and drag-dock forms 
into the main form, and then allows to undock the forms again. If 
somebody already made that work, then there's not much left to do for me :-)
[If you have Delphi at hand, try to make the Demo\Docking sample work 
with Lazarus, somehow. Then you'll see yourself what remains to do :-]


>> 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?

Yes, and it looks like overkill to me and, if you look into the source 
code, it is not really used at all :-(

I'd use a list of docking planes (or levels), where the planes have 
alternating horizontal (alLeft/alRight) and vertical (alTop/alBottom) 
arrangement. Or the site contains only one docked client without an 
arrangement (alClient), or it is/contains a tabbed control or other 
layout (alCustom), like anchored docking. Every plane is represented by 
an according container control (e.g. TPanel), which already implements 
what currently should go into the DockTree.

I also feel a need for centralized handling of drag operations. A static 
singleton would perfectly fit all requirements, since only one drag 
operation (mouse capture...) can be active at any time. All mouse 
messages could be routed through that singleton, when it signals a drag 
operation in progress. Such an implementation should make Lazarus and 
the applications much more stable...


>> 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.

(Not) breaking existing code is one of my problems, since I cannot test 
the changes on all platforms. Another problem is the lack of multiple 
edit window, which was and is my primary goal to achieve.

And now, when I've started the reorganization of the Controls unit, I 
have more (beginner) problems with making the changes compile. Can you 
suggest an way to edit, syntax check and finally compile a standard 
unit, like Controls.pp? An application project will ignore the changes 
and use the original units, as linked into Lazarus. What do I have to 
edit, in order to rebuild Lazarus with added units?


> While 
> doing your redesign please have in mind that we need to stay compatible 
> with delphi.

Errr, you want *me* to implement the Delphi interface, which never has 
been implemented in Lazarus? ;-]


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

Thanks for this hint, normally I prefer to compose and translate my 
ideas offline. But IRC would be nice when I'm stuck on a specific 
problem. I only never used IRC yet, can you give me hints on how to 
start? (on Linux)

DoDi