[Lazarus] IDE forms [Two source code editors (bug?)]

[Hans-Peter Diettrich]

Martin schrieb:
> On 01/05/2011 01:43, Leonardo M. Ramé wrote:
>>
>> Well, I figured out how to move the files from the 2nd editor window to
>> the main one.
>>
>> Now, the 2nd editor window is empty...but every time I open my project,
>> that window is opened also. How can I eliminate that window from my
>> project?.
> 
> If you close the window (normal "X" close button), and save the project, 
> then it should be kept closed.

This seems to work, but currently I have the following issues with the
non-docking IDE:

IDE
---
02 MainBar extent should be configurable (at least not 100% wide).
03 Form positions should accept negative coordinates.
04 Forms should be moved (and clipped) into monitor bounds.
05 Save layout with *current* window positions.
06 Properly adjust with negative width/height values.

02 is a private wish for wide screens, where I prefer a 50% wide
MainBar, and a full-height editor window to its right.

03-05 are tightly coupled. In general the forms should allow for all
valid coordinates, i.e. also negative ones (my secondary monitor has 
negative Y coordinates). On exit the IDE should save
the current window positions, in a way that these are restored on the
next start. There seems to exist a problem with the default window
placement property, that is not always set to "custom".

06 is a trivial one, the form size currently is extended instead of 
shrinked (subtracting negative value).

I've almost fixed above issues, but currently I only can provide Git 
commits or patches. My SVN copy has too many unrelated updates in it, so 
that I cannot provide specific patches.


> However, if you use the docking manager, then it may not be so easy. 
> Last time I checked (quite a while ago though) the dockingmanager was 
> buggy, and didn't allow closing the window.

Anchor docking seems to work, when I tested it some time ago, but 
"normal" docking now is broken in several ways. Some problems seem to be 
added by the IDE, where e.g. docked forms cannot be undocked.

Dockable IDE
------------
01 FormCreators only should be used when a form is created, not later.
   Forms should be made visible/foreground by standard procedures.
02 Forms should be really dockable (dkDock, see also: docking).
03 Options:Windows should always show window positions.
04 MainBar should have all contents in a panel or frame, so that other
   windows can be docked into it (elastic sites).

01 may be a general problem, when the IDE (creators...) think that form 
coordinates are invalid and try to "fix" them - even if the form was 
moved by the user [see negative coordinates above]. Also a general 
MakeVisible method should be implemented, that works across tabbed and 
scrolling controls - this can not be done by a docking manager. 
ShowControl seems to be a good starting point for this feature.

02 may be related to the broken DragManager, or missing MakeDockable 
calls. I see no reason for MakeDockable at all, since a DockMaster knows 
what to do on ShowForm.

03 is required for debugging and repair of clobbered window settings.


For completeness I add the docking issues:

Docking
-------
01 DragObjects should replace DragPerformers.
02 DragManager should pass all messages to DockManager or DragObject,
   not to controls.
03 TDockWindow is unusable (on Windows).
04 Docked windows should be dkDock, to allow for undocking.
05 CaptureControl changes should not stop drag/dock.

01/02 are (optional) improvements, that allow for better integration of 
docking managers. The Delphi model allows to customize docking in 
special DockObjects, supplied by the user or by an 
DockManager/DockMaster. The Lazarus DragPerformers do not allow for such 
customization. Furthermore the Delphi model *and* the Lazarus 
implementation is too much fixed on TDockTree. E.g. a GetDockEdge method 
and DockAlign parameter is useless with other docking managers, and the 
Lazarus implementation contains many hacks, that may be required for 
AnchorDocking. Leaving all that stuff to concrete DockManager, 
DockMaster or DockObjects would increase the flexibility, with possibly 
multiple coexisting DockManagers; it also would assure that 
inappropriate handling of docking messages in TControl does not affect 
the operation of concrete docking objects.

03-05 are obvious, any attempt to start a docking operation hangs 
applications (including the IDE).


> A none docking IDE should only open the window, if there is at least one 
> unit to be loaded into it => so moving them all to the one primary 
> window, and restart should also solve it.

One problem seems to be the storage of even empty editor windows in the 
options. The window persistence seems to have be improved, but still 
suffers from above and possibly more problems.

DoDi