[Lazarus] Is Lazarus project in a downward spiral?

[Hans-Peter Diettrich]

Graeme Geldenhuys schrieb:

> [...If you are easily offended to what I normally write, stop reading now...]

I'll add some more possibly offending opinions :-]

> This worrying issues is more visible lately than ever before. I'm
> starting to worry that Lazarus team is trying so hard to catch a
> moving target (delphi) and trying to implement many fancy features,
> that nothing actually ends up becoming stable or compatible for long.

ACK :-(


> Then developers like myself, which try and promote FPC and Lazarus IDE
> in the corporate environment, hoping to catch a break and get some
> corporate sponsorship for Lazarus, is having an endless battle. I
> personally have run out of options in what to recommend to such new
> clients/developers. The supposed to be stable "fixes" branch is
> broken. The "trunk" branch is changing to much for corporate on
> independent developers to use in commercial environment because it's
> often broken after a svn update or features are partially implement
> (expected from a trunk branch I supposed). But that leaves no real
> stable working version of Lazarus!

I've never tried to implement a "serious" project with Lazarus, only 
working on test applications for docking and related issues. So I don't 
know about its overall usability.

> I just feel there seems to be no clear direction or goal in the
> Lazarus project any more. What was the initial goal? To be Delphi
> compatible? But to which version: Delphi 7, Delphi 2005, Delphi 2007,
> Delphi 2009, Delphi 2010? Seriously you guys don't think you can keep
> up with a commercial funded company and still implement your own
> unique features. Lazarus needs it's own set of goals, not the goals of
> Embarcadero. And things are just going to get worse when Embarcadero
> releases their cross-platform compiler and toolkit in a year or so.

ACK. I'd say that the LCL should be compatible with D7. Until D2007 IMO 
there was nothing essentially new in the VCL, and later Unicode versions 
are not widely accepted, including new features like extended RTTI. So I 
see Lazarus as the follower of D7, for all people that are not willing 
or capable of paying so much for the Embarcadero products.


> Make no mistake, after all I have said, I still think Lazarus IDE is a
> great developer tool. It's just a bit harder to find a stable working
> build. We have resorted to to maintaining our own stable branch in our
> company by cherry-picking select commits as we need them, but this
> requires even more time. I just feel Lazarus project overall has NO
> goal! And a project with no overall goal has no future. It's not
> living up to what it could be. As a community member I thought it my
> duty to raise all these concerns. I want Lazarus to live up to it's
> full potential - only thing is, nobody knows what that is. :-(

I also feel an urgent need for some consolidated version of both the LCL 
and the IDE. My dream were a fully specified and documented version of 
both parts (at least of the LCL), to which only "certified" components 
are added. The envisaged certification of a component will include full 
documentation and examples for the verification of the implementation, 
on all supported platforms/widgetsets. Not all platforms must be 
supported by a component, or the known issues must be documented in a 
way that allows every *user* to determine the usability of the component 
on his target(s). Only "stable" features of the components should be 
officially supported, i.e. problematic features should be excluded until 
their implementation reaches an stable state.

The platform/widgetset interfaces should be documented, in a form that 
allows skilled users to contribute to the development. The problems with 
specific targets should be documented, in a form that allows to find 
target-independent solutions, if ever possible.

Perhaps we should have two branches, one for a common GUI for multiple 
targets, and one with dedicated components (and designers?) for distinct 
targets. The latter approach would use thin wrappers around the native 
components, so that the components themselves will not be subject to 
development efforts at all. This IMO will be the most attractive 
solution for commercial developers, stable and with a clear goal. With 
proper separation between GUI and worker code it should be easy to 
implement multiple widgetset specific GUIs for every application, if 
desired. It also would use the widgetset-specific layout management in 
the first place, with only stable extensions as conforming to the 
widgetset-specific procedures.

The IDE also should come in a stable version, possibly configurable for 
easy in/exclusion of unstable or unwanted features (auto formatting...). 
It should be extended to support multiple form designers (for dedicated 
widgetsets), multiple editor windows and docking. The IDE should become 
platform independent in so far, as it also should allow for multiple 
GUIs, or it can be considered a test case for the multi-target LCL version.

The stable LCL and IDE versions should be implemented bottom-up, by 
removing critical/unstable features in the first place, and by adding 
them later in an easily configurable way, with stable interfaces. This 
will allow to diagnose trouble sources and to delegate the solution of 
problems to the maintainer(s) of the spotted trouble source.

While there exist areas that deserve really detailed knowledge about 
multiple involved items, a detailed documentation should allow to
1) find inconsistencies in the existing implementation, and
2) allow other developers to contribute to, or maintain, specific areas 
(components...).


Finally Lazarus is an open source project, that should allow *everybody* 
to contribute, not only a number of gurus with secret knowledge. I'm 
willing to do some kind of QC, when it comes to the integration of 
components, patches and features into the stable versions. Perhaps we 
can start with Grames's GIT version, to decouple a stable version from 
the Lazarus releases...

DoDi