The debugger (frontend) needs to very closely work with at the very least:
If I understood the Interface units correctly the/one purpose is to connect different parts of the IDE. The good about is that you do not all the dependencies in one unit and that GUI and functionality are separated. So (without checking the code) it would be possible to provide all the functionality in an editor interface and a debugger interface (Set breakpoint), which could be core. How everything is displayed (I mean the GUI part) would be part of another IDE package which does not have to be core and thus can be replaced if required. The editor and debugger GUI part would then only have to reference the interfaces instead of each other.
The debugger interface currently indeed acts as an API. (But not to the IDE)
The debugger interface does not set a breakpoint to the source editor (or IDE). It does the opposite: If a breakpoint was set in the IDE, then it tells gdb to set this breakpoint too. (or instead of gdb, whatever debugger backend is running).
The debugger interface was created to allow work on fpdebug. (gdb replacemnt)
----
There already is a package IDEIntf, which has various ...Intf units. (Like SourceEditorIntf)
Those units allow 3rd party code to interact with the IDE. (But they do not (yet) include the IDE parts of the debugger).
Also IDEIntf is LGPL, while IDE is GPL. This means you can write close sourced packages for the IDE, as long as you only need IDEIntf.
Maybe I should explain how I came to write this post. I read the discussion about the Free Pascal logo on the mailing list. (For all not the mailing list) Someone proposed a new FP logo and the idea was that it would motivate more young developers when the logo and the website look more modern.
As I wrote on a previous post of this very thread:
That promise - any promise of the kind "Do this, and it will bring new users/contributors" - has been made before. Plenty of times. And when some of the demanded things had been done, the promise
never was fulfilled.
Sure there are places in the sourced that could be improved. And the docs have even more potential for improvements.
But it is a vicious circle. Once a person worked through the sources, they start doing other work on the sources....
Also splitting the sources will not make it that much easier. You then need to add hooks, extra calls, .... And overall you still have the same amount of code. (Documentation could help so. If it is kept up to date, so probably needs to be in the source, and really short / comments on the function declaration)
Example:
A separate package for the IDE frontend of the debugger, would still be full of interaction with the rest of the IDE (because the debugger affects so many parts). And it would still have interaction (calls and events) with the debugger backend.
In fact, all the code that you need for the asm window, is in the folder "debugger", and one unit in the ide folder: "ide/debugmanager.pas". That is as good as a package of its own, don't you think?
(Of course, even though the backend is already a package, it probably needs design changes, to support a really good solution. But for a quick fix, you may be able to ignore this.)
And yes context menus for the source editor are defined in the source editor. That can be moved. And while it will be a better design, it will mean to split the menu creation into many packages. This may make it harder to understand.
You still need to understand those interactions, or changes you make may have really bad side effects.
You can not suppress all uses of the asm window (maybe you can on your local copy). Because if the user opens it from the menu, or pop up menu (could be in the IDE or the debugger), or dedicated short cut, in all those cases it must still work.
Still, yes. If it can be made easier, then cool. I am all for it.
====
Edit:
Don't get me wrong. I know I sound very critical of the idea, but I am not against it.
I simple think that the outcome to be expected from such work, may be less than you advertise.
On the other hand there are other good reasons that can be added:
- re-usability
- ability to add tests