My experience with the 0.9.30.4 and trunk versions suggests that docking will be discontinued in Lazarus?

The LCL, IDE and Win32 widgetset contain code that breaks Delphi compatible drag-dock deliberately, for no obvious reason or benefit. It looks to me as if none of the core developers understands the implementation and use of dragging in general and drag-dock in detail. Postponing required fixes to rev. 0.99 will make it almost impossible to support a dockable IDE any more, due to the many breaks in the current IDE code.

While a dockable IDE can be achieved in 0.9.30.4 with a few simple patches, I could not find out what breaks docking in the trunk IDE at all - the dockable IDE windows simply disappear, including the source editors and messages windows :-(

Can we agree to make the IDE dockable again *now*, or should I stop waiting for another usable IDE?

DoDi

Hans-Peter Diettrich wrote

Can we agree to make the IDE dockable again *now*, or should I stop waiting for another usable IDE?

From a usability standpoint one of my two major gripes with Lazarus are floating windows. It looks unorderly in my eyes for every panel to have its own window and just be floating randomly somewhere. I definitely like the default Delphi layout better with docked panels. I think that Lazarus should be working towards this.

Wont hijack this thread with my other issue.. ;)

Anders

I'm currently trying to fix some 0.99 bugs. I hope to find some time for docking too. But it is a complex topic, has a big risk of breaking things and needs a lot of time.

Mattias

Please create bug reports and point which exact revisions broke what.

Although there are many minor irritations, on the whole docking works fine for me
for more than a year now.

I also never experienced any problems; I don't use it in the IDE, but in other apps.

Michael.

I use a docked IDE since years on windows, linux/qt, linux/gtk2 and carbon.
But there are some problems. For example focus problems in the IDE, closing windows could be easier, design windows are not yet dockable and there are some issues with anchordocking.

Mattias

Now I don't understand anything. Some have problems (like Dodi), and some doesn't have any problem ... so where is problem exactly ? ;)

zeljko
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120317/4371da52/attachment.html>

17.03.12 20:19, zeljko ???????:

Dodi has implemented an own vision of docking while delphi like docking still works.

Best regards,
Paul Ishenin

Thanks.

zeljko
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120317/b40c5928/attachment-0001.html>

I'm currently trying to fix some 0.99 bugs. I hope to find some time for docking too. But it is a complex topic, has a big risk of breaking things and needs a lot of time.

I'd like to assist, if you give me some clues. I think that you know that, so I wonder why you want to do everything yourself?

DoDi

The breaks are known for 0.9.30, where only docking itself is affected.

In the trunk IDE the IDEWindowIntf is so obscure, that I didn't succeed in finding clues. Currently the reported default window positions are almost Top=10, Left=0, Right=4, the Bottom is typically bigger. Since the docked extents are managed by the DockMaster, it looks as if the herefore required methods are no more called.

DoDi

Now I don't understand anything. Some have problems (like Dodi), and some doesn't have any problem ... so where is problem exactly ? ;)

One problem may be an undefined environment, i.e. which FPC version should be used for Lazarus trunk. I'm just trying to use FPC 2.6 for Lazarus trunk, but with any number of setup problems. Perhaps I have to remove all older versions from my system, in order to get anything work. For some reason I had no problems in using FPC 2.7 and Lazarus trunk with applications, so far, but the release setup and the IDE seems to be heavily affected.

DoDi

Dodi has implemented an own vision of docking while delphi like docking still works.

Please explain?

What's "Delphi like docking", and in how far is it different from the EasyDockManager implementation?

How did you make work "Delphi like" docking in the IDE?

DoDi

My current biggest gripe with AnchorDocking is that it totally messes up the layout when I change the display size (i.e. plug a monitor). I dislike that it resizes proportionally all controls (even border-docked ones) when the parent is resized, but fortunately Mattias informed it this is an configurable and the IDE is now storing it correctly. I also remember easily triggering crashes while changing the layout, but I just can't trigger one right now :)

-Fl?vio

Maybe you can help.
I would start with the annoying focus problems. For example when closing a source editor file, the cursor is not shown. This happens under linux/gtk2 and carbon. I fixed it some time ago for qt. Another one is when a lpk is opened under linux/gtk2 the package editor window is behind the source editor, but the pe is focused. You have to focus the se and then the pe to bring the pe to top. Sometimes this happens with the search results too. My guess is the bug is in the IDE code.

Then I would implement some theming for the anchordocking headers. And finish the options for hiding the headers.
Then fix the page restore bug.
Then saving/restoring the bounds of the floating windows (anchordocking).
Then find a way to handle the tricky main ide bar. But that is really complex.

There are more issues, but I guess if the above points are done, docking would work well enough for a release.

Mattias

Mattias Gaertner wrote

Then fix the page restore bug. Then saving/restoring the bounds of the floating windows (anchordocking).

On that part, I wondered why the old layout stuff was totally abandoned.

Even in docking, a user might want to specify fixed positions (maybe undocked) for some windows, and restore last bounds for others. Could the objects for the layout not have been extended?

It also adds additional (still to be done) work, for restoring column width info (currently used by debug windows).

Since there is an obvious relation between the widths of columns (in a list on a window) and the window size, the column width is stored with the layout....

?

Even in docking, a user might want to specify fixed positions (maybe undocked) for some windows, and restore last bounds for others. Could the objects for the layout not have been extended?

Yes, I think that should be added to the anchordocking dockmaster.

Yes, and splitters.

Mattias

The classes in ideintf\idewindowintf.pas

But then an user config would be desired.

This is currently in the options / env / window

It allows to set if a column (or splitter) has a fixed width (always the same width if IDE starts), or restores last width

Every form can register any amount of "widths" (or heights or splitter pos)

18.03.12 1:02, Hans-Peter Diettrich ???????:

Please explain? What's "Delphi like docking", and in how far is it different from the EasyDockManager implementation?

At least the implementation of lazdocktree and easydockmanager is different.

How did you make work "Delphi like" docking in the IDE?

I did not make it work. Michael told about his own applications which are probably not based on easydockmanager.

Best regards,
Paul Ishenin

There exist more problems with switching between files, in detail with multiple editor windows. Frequently the CodeExplorer fails to notice the focus switch to a different window, and continues to show the information for the unit in the old window.

I also found a couple of ShowForm calls for every user action (keystroke, code completion, paste...), which IMO should not occur.

See above, ShowForm is called too often, from different places. This should be "normalized" somehow. I understand that there exists a precedence problem with e.g. pe/se, which should be handled in a well defined way.

Then I would implement some theming for the anchordocking headers. And finish the options for hiding the headers.

IMO the IDE should not rely on a specific docking model, or it should be restricted to anchordocking only. This decision will influence the remaining code. Please note that in a docked IDE it may be impossible to have distinct windows on-top at the same time, depending on how these are actually docked. At least I prefer docking different forms into notebooks, from which I can e.g. select Object/Procject inspector, depending on the current activity (editing forms or source code).

Then fix the page restore bug. Then saving/restoring the bounds of the floating windows (anchordocking).

AnchorDocking is not the way I'd go in the IDE. If this is your preferred model, I cannot assist much.

Then find a way to handle the tricky main ide bar. But that is really complex.

IMO the MainBar is not tricky, it only deserves a real structure (panels, frames...).

There are more issues, but I guess if the above points are done, docking would work well enough for a release.

I'd suggest a common base class for all IDE windows, best including the debug windows. Then much state information can be saved with every window, no lookups of FormCreators or other additional data structures all over. I already implemented such a base class for testing purposes, with no real problems, it only will affect a couple of form units (all IDE forms). Once the base class is defined, e.g. in IDEWindowIntf, it can be decided which information should go into that common class. Then e.g. ShowForm will become a method of that class, with no indirections through FormCreators or other global procedures, and a common ShowOnTop handler can be implemented for all IDE forms, which switches the focus etc. only when really required.

DoDi

Perhaps it turned out unusable?

Even in docking, a user might want to specify fixed positions (maybe undocked) for some windows, and restore last bounds for others. Could the objects for the layout not have been extended?

I'd put the form bounds into a common base class, so that it can be initialized whenever a new form (not yet part of the layout) is created, by overriding the virtual base class method. Afterwards the layout manager can move the (new) form to the saved/restored layout position.

It also adds additional (still to be done) work, for restoring column width info (currently used by debug windows).

I'd use a general column layout (object), for every list control, that eventually can be configured by the user (which columns should stay fixed, which should be subject to dynamic resizing. Then only the general layout information (model to use...) has to be saved and restored, while every list will auto-adjust its columns on every form change. A good design should not require that the user re-adjusts the invidual column widths with every change of the containing form bounds.

Since there is an obvious relation between the widths of columns (in a list on a window) and the window size, the column width is stored with the layout....

See above. IMO it should be sufficient to store the column layout *model* type, like a DockManager class type. A specific column layout manager object can be created whenever a layout is restored. The storage of eventual additional layout information then is up to the column layout manager of the list, the amount and type of the additional information should not be restricted or fixed in any way.

The stored layout information should be considered as a property resource stream, with type specific parts streamed in/out just like with .dfm or other resource files. The EasyDockMaster implements such streaming, with sub-sections stored as strings and prefixed by specific tags. XML could be used for that purpose as well, but it would introduce another level of indirection (mapping of tags to arbitrary property processors...).

DoDi

Really? This would explain why the EasyDockMaster will fail now, using the old stuff.

DoDi

These are only different implementations of the same (TDockManager) interface. I found LDockTree unusable, failing already on slightly nested layouts. It also lacks layout streaming, required in applications like the IDE. Dunno about the current state, though...

I'm still waiting for a justification of:

>

Dodi has implemented an own vision of docking while delphi like docking still works.
<<
I never implemented anything Delphi-incompatible, in contrast to anchor docking.

DoDi

No no no

you miss understand

They are not abandoned, they work well in none docked IDE (*and they store the column widths for debug windows)

Only AnchorDocking does not use them (EasyDock I have not checked, do not know)

See other mail. it is still in use

Well yes and no.
For every form layout info must be available.

I thought of creating such a base class. Bet in the end, I thought not do do it.
From a point of providing functionality and amount of work to do it, there is no real difference between having such an big-almighty class, or splitting functionality in individual classes (though I prefer the 2nd)

NOTE:
- I am not saying the current structure is the right solution.
- I am saying, that the right solution can be done with layout providers too (maybe even better)

Every window class must be registered to the IDE (or should), so when loading information, it can be recognized and the form can be created.

However, a window class may have more than one set of defaults. Source editor can be opened many times. Each has its own default. So SourceEditor should be registered with a LayoutInfoProviderCreator, that can be asked for the LayoutInfoProvider for each instance of source editor....

Every window currently registers columns with a callback, that can provide the info.

More info can be added as needed

Hans-Peter Diettrich wrote

At least I prefer docking different forms into notebooks, from which I can e.g. select Object/Procject inspector, depending on the current activity (editing forms or source code).

I'd like to have this feature.

I couldn't verify that column widths are stored in the undocked IDE. I only could verify that the IDE may not close any more, depending on unknown conditions :-(

Only AnchorDocking does not use them (EasyDock I have not checked, do not know)

Mattias provided the RegisterEasyDockMgr unit, it's up to him to adopt it to new conventions, or to document the interface in a way that somebody else can implement or use it.

DoDi

Alpthough you descend from TDockManager you don't descend from TDockTree which was a trial to implement delphi like dock manager.

I never implemented anything Delphi-incompatible, in contrast to anchor docking.

I did not mean that you made something incompatible, just that you made an own implementation which Michael probably does not use.

Best regards,
Paul Ishenin

The TDockTree and related TDockZone classes are not immediately applicable to the LCL and its Delphi-incompatible DragManager[Default] and TDragObject. In detail notebook-docking is not supported by the given TDockTree class, even Delphi uses further classes for that purpose, and for floating sites etc.

I found the TDockTree (and LDockTree) not really usable, that's why I used TDockManager as the base class of my DockManager. Neither TDockTree nor TLazDockTree support the Lazarus extensions to TDockManager.

TDockTree is not ready for use in applications, so every application has to specify an working dockmanager. The "no problems encountered" statement is meaningless until the used dockmanager, widgetset *and* the unproblematic use cases are specified. Currently (trunk and 0.9.30) not any dockmanager is usable with the Win32 widgetset, due to bugs in the LCL and TDragManager, which e.g. prevent undocking a control using the mouse.

The IDE (see topic) is not bound to an specific dockmanager, but I have the impression that currently only anchor docking implements the IDE interface properly (if at all). This is not a matter of an specific dockmanager, which only manages a single docksite, but of the management of all dockable forms and docksites pertaining to an application, including save/restore of layouts.

DoDi