[Lazarus] Dockable IDE

[Hans-Peter Diettrich]

Mattias Gaertner schrieb:
> On Sat, 17 Mar 2012 17:40:58 +0100
> Hans-Peter Diettrich <DrDiettrich1 at aol.com> wrote:
> 
>> Mattias Gaertner schrieb:
>>
>>> 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?
> 
> 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.

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.

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

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