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
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
