Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / lazarus / 2010-12

Made dockable IDE work :-)

5 messages · 2 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Hans-Peter Diettrich

Today I could find another workaround for the last severe bug in the dockable IDE. Now it's possible at least to drag and dock the IDE windows with the mouse :-)

How to proceed?

Some of the problems:

My work is based on Graeme's Git repository, so that it's not easy to supply SVN patches.

My patches are workarounds for several problems, in detail with TControl, TWinControl and the DragManager. More analysis is required, in order to find out the real reasons of the misbehaviour[1].

Many bugs only manifest in the IDE, not in ordinary applications or the DragManager examples, what makes it even harder to find the appropriate cure, that does not break other application or component code[2]. Many patches have to be applied before it's even possible to start debugging the IDE. Afterwards every fix may result in different remaining problems, possibly not covered by the remaining workarounds.

Last not least I'm still offline, and cannot report the many observed bugs one by one. I only can try to write down the observed misbehaviour during my recent work, and let somebody else care for the rest.

[1] One of my experiments resulted in a refactored (stripped down) DragManager, with the Performers removed and their code moved into the DragObject classes. An according patch can be applied easily, because it essentially exchanges the dragmanager.inc by a very new version, and extends dragobject.inc. OTOH it has to be applied as a whole, impossible to break it down into smaller steps.

[2] Since many bugs can be observed only in the IDE, they also should be fixed in the IDE code. This is not so easy, due to the many methods and event handlers that may be involved. Many bugs definitely originate in the TControl and TWinControl implementation, where I suspect workarounds for other components (IDE, csCaptureMouse, anchor docking...). Removal of these workarounds may cause malfunction of the affected components, perhaps only in specific widgetsets. Nonetheless I'd suggest to trim that code, to achive the Delphi compatible behaviour again, and then think about a separate or combined implementation of platform-independent (Lazarus specific) dragging.

DoDi

Reply by email

Sven Barth
to Hans-Peter Diettrich
Hans-Peter Diettrich wrote 45 lines
Today I could find another workaround for the last severe bug in the dockable IDE. Now it's possible at least to drag and dock the IDE windows with the mouse :-) How to proceed? Some of the problems: My work is based on Graeme's Git repository, so that it's not easy to supply SVN patches. My patches are workarounds for several problems, in detail with TControl, TWinControl and the DragManager. More analysis is required, in order to find out the real reasons of the misbehaviour[1]. Many bugs only manifest in the IDE, not in ordinary applications or the DragManager examples, what makes it even harder to find the appropriate cure, that does not break other application or component code[2]. Many patches have to be applied before it's even possible to start debugging the IDE. Afterwards every fix may result in different remaining problems, possibly not covered by the remaining workarounds. Last not least I'm still offline, and cannot report the many observed bugs one by one. I only can try to write down the observed misbehaviour during my recent work, and let somebody else care for the rest. [1] One of my experiments resulted in a refactored (stripped down) DragManager, with the Performers removed and their code moved into the DragObject classes. An according patch can be applied easily, because it essentially exchanges the dragmanager.inc by a very new version, and extends dragobject.inc. OTOH it has to be applied as a whole, impossible to break it down into smaller steps. [2] Since many bugs can be observed only in the IDE, they also should be fixed in the IDE code. This is not so easy, due to the many methods and event handlers that may be involved. Many bugs definitely originate in the TControl and TWinControl implementation, where I suspect workarounds for other components (IDE, csCaptureMouse, anchor docking...). Removal of these workarounds may cause malfunction of the affected components, perhaps only in specific widgetsets. Nonetheless I'd suggest to trim that code, to achive the Delphi compatible behaviour again, and then think about a separate or combined implementation of platform-independent (Lazarus specific) dragging.

Would you please tell me what type of docking you are using? I am using anchor docking without any problems with docking and undocking windows (on Linux as well as on Win32). I have also tried easy docking on Win32 at first, but while docking and undocking itself worked it had some other troubles (I don't say that anchor docking has no problems, but they are less troublesome ^^).

Regards,
Sven

Reply by email

Hans-Peter Diettrich
to Sven Barth
Would you please tell me what type of docking you are using?

Ordinary drag-dock (using my EasyDock... ;-)

I am using anchor docking without any problems with docking and undocking windows (on Linux as well as on Win32).

Does this mean that anchor docking now allows for drag-dock?

I have also tried easy docking on Win32 at first, but while docking and undocking itself worked it had some other troubles (I don't say that anchor docking has no problems, but they are less troublesome ^^).

The EasyDockTree was the first really working implementation of an dockmanager in Lazarus. It took years to convince the developers of providing the required support in the LCL, and perhaps some more years to fix the remaining problems. [Today I noticed that the docksites are not initialized properly, a manual resize of the parent is required for that]. Breaking drag-dock instead seems to be a matter of only a few weeks. OTOH this demonstrates that docking is almost unused, probably due to the problems arising all the time.

Currently I'm thinking again of an installable DragManager, so that the LCL must not be recompiled for every minor change (like adding debug messages). But this project requires access to the protected methods in TControl and TWinControl, and persistent storage of the registered docksites (not destroyed when another dragmanager is installed). In my own Lazarus version I can change that without problems, but it requires that every interested user has to patch the "official" LCL for that.

DoDi

Reply by email

Sven Barth
to Hans-Peter Diettrich
Hans-Peter Diettrich wrote 6 lines
Sven Barth schrieb: > Would you please tell me what type of docking you are using? Ordinary drag-dock (using my EasyDock... ;-)

Ok.

Show quoted text 5 lines
> I am using anchor docking without any problems with docking and > undocking windows (on Linux as well as on Win32). Does this mean that anchor docking now allows for drag-dock?

Seems so. At least I can grap a docked window (e.g. Messages) and move it to another part of the main window or make it float :)

Show quoted text 13 lines
> I have also tried easy docking on Win32 at first, but while docking > and undocking itself worked it had some other troubles (I don't say > that anchor docking has no problems, but they are less troublesome ^^). The EasyDockTree was the first really working implementation of an dockmanager in Lazarus. It took years to convince the developers of providing the required support in the LCL, and perhaps some more years to fix the remaining problems. [Today I noticed that the docksites are not initialized properly, a manual resize of the parent is required for that]. Breaking drag-dock instead seems to be a matter of only a few weeks. OTOH this demonstrates that docking is almost unused, probably due to the problems arising all the time.

Anchor docking seems to work better than EasyDockTree currently. I tested that one at first, but I had problems to get the "windows" to the positions I wanted them and to keep them there (especially when saving and reloading a layout). With anchor docking I haven't experienced that problem.

But the following problem appeared:
I had docked the object inspector into the docked code explorer (thus creating a page control containing the two) and saved that layout. I then restarted the IDE which used the default layout (worked) and then loaded my saved layout. I then got a "loop detected" error somewhere when creating the object inspector, the code explorer or the area of the page control (I don't know the reason exactly, cause I haven't done extensive tests on this topic yet).

Regards,
Sven

Reply by email

Hans-Peter Diettrich
to Sven Barth: Would you please tell me what type of docking you are using? I am using anchor docking…
Show quoted text 5 lines
I am using anchor docking without any problems with docking and undocking windows (on Linux as well as on Win32). I have also tried easy docking on Win32 at first, but while docking and undocking itself worked it had some other troubles (I don't say that anchor docking has no problems, but they are less troublesome ^^).

Now I managed to make EasyDocking work again on Win7 with the Lazarus trunk, and also in the IDE :-)

Unfortunately I only could produce an big patch, covering all updates to the examples/dockmanager, LCL and IDE. I attached it for all curious users, and hope that it will not be removed by list restrictions.

The patch addresses (amongst others):

+ Full screen extent (including negative origin) in TScreen.Bounds, Options:Windows and in the IDEDockManager.

+ Better IDEDockManager integration, some methods added, general ShowAllForms etc. procedures check for the presence of an IDEDockManager. This could be further extended, so that the IDE does not have to care at all about an DockManager.

+ Fixed some DragManager flaws, in detail CaptureChanged and DockForm.

+ Improved TControl.Floating, using a new TFloatHost base class for all floating sites.

+ Seems to work with AnchorDocking as well.

Enjoy :-)

DoDi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dockpatch0.zip
Type: application/x-zip-compressed
Size: 21804 bytes
Desc: not available
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20101226/8b00c2c9/attachment-0001.bin>

Reply by email