Forum > General
Making Lazarus IDE even better
soerensen3:
First I have to say I really love the Lazarus IDE and it is still unmatched in many places (I especially love the code editor) compared to other IDE's. However I think there is still room for more in some other places. Or to put it in another way, I see a lot of unused potential...
The good thing about Lazarus is that it is very extendable. That everything in theory could be changed if necessary. But some parts are kind of "hard coded" into the application which in my opinion should be or at least don't have to be.
When I tried to make a few changes to the Project Inspector and Package Windows to merge them into one window I found that it is rather complicated to simply change just one behaviour. You could of course change the original code but it is maybe not desired to do so, because some people like it the way it is now. So it is unlikely that this change is accepted for trunk. So the better approach is probably to make it a separate installable extension. This is however rather complicated because first you'd have to reimplement all the behaviour you want to keep by copying the code and make it work from inside your package and second you have to find a way to surpress showing the old windows which is at least not documented. It would be more intuitive if you had a package to begin with, where you can just play and get a feel for the functionality. I have been working first with Delphi and later with Lazarus for a long time but still changing the IDE feels like something with a steep learning curve. I presume this keeps a lot of developers from even trying it. For example the package inspector has had this stupid dialog to tell you that reordering the files via drag and drop is not supported, which is probably more annoying than the fact that it is not supported. I don't see it getting implemented soon anyway. But no one ever tried to change it, maybe because it is very complicated to dig through all the code of the IDE.
My idea is that it would be a lot easier if all the "Components" (as in parts of the IDE, not LCL components) would consequently be in separate packages which in theory could be removed or replaced if desired. Only the core functionality should stay in the main application. The only problem would be the communication between the windows but I think the solution for this is (at least for most of the cases) already there. The *Intf units provide a way to access the project and packages, as well as opened code buffers and forms, independent of the windows displaying them by access structures for reading/writing and by using hooks for events. So the only problem, as far as I see is moving some code portions to packages.
With the Installed Packages Dialog and Online Package Manager in mind it would be really simple to install other IDE extensions and configure the IDE the way you want it and make it as distraction free as possible. For example if you do not want the assembler window to show up because you have no clue about assembler anyway you can just remove the package (eg. http://forum.lazarus.freepascal.org/index.php/topic,40371.msg278868.html#msg278868). Or iff you only write non GUI applications you could simply remove all the GUI plugins and have a clutter free IDE (I think there were several request and approaches for a minimal IDE (eg. https://forum.lazarus.freepascal.org/index.php?topic=37464.0 or http://www.pascal-central.com/lwp/lightweight.html and I think there was an abandoned repo for a lightweight IDE somewhere but I can't find it) where people gave up after some time. Following the suggested approach would open the way for custom Lazarus Distribution (Which CodeTyphon is kind of) but make it more simple to maintain them. If design time packages would have some sort of tags what they provide it would even be possible to show conflicting packages (I'm thinking of something similar as with Linux packages). This would not be minor changes but I think a lot of the functionality is already there and I think it wouldn't break any compatibility with projects made in Lazarus and only a little with IDE plugins because the funtionality would still be there only moved to packages. As I said in the beginning I see a lot of unused potential. It would hopefully make it easier to develop IDE plugins and so encourage more developers to try.
I also understand if you say I don't want the IDE to change, I like it the way it is but if we move everything to packages it would not change visually. It would only be better structured and make way for extending it more easily.
Roughly the steps would be:
* Strip the IDE to only the core functionality (Plugin functionality, Help, Open/Close projects,..)
* (Optional) Create mockup packages to test the IDE
* Create/Replace the packages in form of IDE plugins to get back all of the functionality (Here a lot of people could contribute at the same time without getting in each others way)
Of course it would throw up a lot of questions, which parts should remain core. Also describing this sounds probably more simple than it is in fact so I'm really interested in your opinions. What do you think?
Also with plugins in mind: Right now every design time package is compiled into the application. What exactly keeps us from using libraries (.dll, .so, .dynlib) for plugins? This way if a plugin crashes it would not necissarily break the whole application and plugins could be loaded on runtime.
Pascal:
Sounds good to me :)
We probably have to extend the *Intf units. I had to make several extentions for my One-Click-Profiler-Addon.
Blaazen:
You should present your ideas on Lazarus mailing list. Not all developers follow the forum and only they can tell you whether these changes will be accepted and, if yes, how to do them at most feasible way.
engkin:
You will need dynamic packages which, AFAIK, is not implemented yet. And some people will object using this concept because it increases the time it takes the IDE to start.
Martin_fr:
Generally, there could be some benefits from modularization. Especially if parts that go into packages can then get test cases.
On the other hand: "Never touch a running system". Well at least not without need, that is not unless there is actual new work that requires the change. (Or hugely benefits)
The mere promise "this change will bring new developers to the project", well that promise has been made plenty of times. And some of the requests were fulfilled, yet there is not even one case were the promise was fulfilled. So that promise has no longer any value at all.
As for practical considerations...
There is the question of available men hours. The best chance of any such thing to happen is to find a developer (mailing list) that is willing to apply your patches (small steps that can be checked easily). For a developer to be willing to do this, there probably has to be a concrete benefit. E.g. a package you work on, that requires the changes, and that the developer thinks worth supporting.
About "small steps". It is also likely (actually it is sure) that not everything will be pulled out into package, but only small parts, for which a need can be shown.
---
my 2 cents.
Navigation
[0] Message Index
[#] Next page