Mattias Gaertner schrieb:
On Sat, 17 Mar 2012 17:40:58 +0100
Hans-Peter Diettrich <drdiettri...@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


--
_______________________________________________
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Reply via email to