[Lazarus] Lazarus make me create better apps

[Hans-Peter Diettrich]

Razvan Adrian Bogdan schrieb:

> Lazarus could be so much better but because it inherits some old design 
> issues would probably be better if it was redesigned, made more modular 
> and follow some strict code writing rules. It needs a clear architecture 
> so that anyone can find his/her way into the code without digging for 
> days deeply into the sources.

Good documentation is expensive, at least for those people that should 
make it. The lack of a fixed concept can invalidate existing 
documentation at any time, when somebody found that things better have 
to be implemented differently, for some reason.

> Lazarus is still a great project but if we want more people to 
> contribute, it needs standards of doing things just like VCL has, code 
> must be intuitive if we want people to like doing what they do, also the 
> team should not restrict the abilities of the LCL but extend them on all 
> platforms if possible. Looking at other similar projects and borrowing 
> ideas wold only help the project become more attractive. Lazarus must 
> make it simple for people to write CrossPlatform code in a 
> non-restrictive way, allowing people to port Delphi stuff with little 
> modifications but not restrict itself to Delphi's abilities.

There exist so many different ways to design platform independent 
applications or GUI (fpgui), or multi-platform applications (LCL), or 
widgetset specific applications (Qt...). It's near impossible to fit all 
these models into one library. IMO the only general solution were a 
strictly decoupled GUI management, so that e.g. fpGui, LCL or Qt could 
be used, instead of only LCL. Then it would be possible to define some 
of theses models more precisely, and to develop the libraries according 
to these specifications - but the LCL most probably will never reach an 
stable state, that also could cover all future widgetsets or platforms; 
every new widgetset will add further incompatibilities, so that the set 
of everywhere available features will *shrink* all the time, and the 
widgetset specific differences will increase.

> The mobile world is now a perfect place for Lazarus to "sink it's teeths 
> into" if it knows how to occupy this space where there is 
> little competition on the RAD side of things. On the web part after many 
> years of Java slows apps, PHP code that let's you hit you fingers with a 
> big hammer and ASP.NET <http://ASP.NET> technology that seems to be so 
> hard to learn, Lazarus has a big change to make something that 
> integrates easily on the Server and the Client side, maybe using NaCL on 
> the client to build safe apps or simply "compile" to JS, Flash and 
> Silverlight.

This would mean to have a "Lazarus for LCL", another "Lazarus for 
Silverlight" etc., like "Delphi for PHP". Nice to have, but essentially 
these are very different projects.

> Now is the time to either write a new IDE (not the whole LCL) or 
> redesign the existing one using all the best features LCL has to offer, 
> the LCL itself could be made less object oriented on the API abstraction 
> part, and maybe the RTTI system if it is responsible for the big 
> executables.
>
> Lazarus could even replace technologies like Flash and Silverlight with 
> the right approach on the client side, i think some people are trying to 
> do just that with things like VGScene/DXScene.

All these could become such new projects, perhaps based on the current 
IDE and parts of the widgetsets, but each with a new component library. 
As a very first new project we could refactor the IDE and the LCL 
binding (designers...), into a new base for use with very different 
component libraries. This should include project management additions, 
to allow for a separation between general application code, and any 
number of additional GUIs, that can be switched at design time.

A new designer for the application-GUI interface may be added, that will 
allow to specify the project specific interface between both parts, and 
that can provide means to create skeletons for both sides (like class 
completion does). This will be the place where Actions come into the 
play, which already allow to define an abstract interface from the GUI 
to application code. The opposite direction should be supported as well, 
i.e. how application code can access parts of the GUI (show forms, read 
entry values...).

Just some ideas...

DoDi