[Lazarus] Is Lazarus project in a downward spiral?

Juha Manninen juha.manninen at phnet.fi
Sat Mar 6 13:51:23 CET 2010


Hi!

> 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.

I have had the same ideas, this kind of cleared my thoughts.

*** Now, the future goals for Lazarus: ***

1. Stabilize the current features for 1.0 release.
  Nothing special here, I think everyone agrees.

2. Make different GUI-specific target modes for Lazarus!
  Three such modes would be:

  a) LCL-mode, the current (more or less Delphi compatible) interface. It 
would have only (light?) native widget bindings like Windows and MacOS and a 
future *nix widget binding (maybe based on fpGui). GTK* and QT bindings would 
be dropped.

  b) QT-mode. This would implement QT-lib classes, methods, properties and 
signals in a thin, one-to-one mapping. The programs would not be Delphi 
compatible but they would be more like QT compatible, just using pascal 
instead of C++. This mode would compete with dynamic language bindings for QT.

  c) GTK2-mode. Again, a thin mapping for GTK2. However, it could improve the 
weird programming model of GTK2 and be fully object oriented.

-------------

Those modes would implement different component sets and also different (or 
modified) form designer. It is not a small task and so the target is Lazarus 
2.0 (many years...).

However, this is a design change that must be done because the current binding 
design sucks, at least for big GTK2 and QT libraries. This is a known issue 
but nobody has suggested how to fix it except for hacking more and adding more 
spaghetti code.

I just tried to find a bug in QT combobox which occurs in my machine but not 
in QT-bindings maintainer's machine. See Lazarus-QT list for reference.
The fact is that much of the control's behavior is re-implemented in the 
binding code to make it behave just like LCL has it  (separate droplist and 
edit controls re-implemented).
And QT-bindings are in good shape, GTK2 is worse...
This design is brain-dead! Please ask any SW-design expert if you don't agree.

Note: I am not criticising the binding maintainers. They have done a good job 
given the brain-dead design goals.

My experience with programming is that a design problem should be fixed as 
early as possible. If you build more features on a flawed base then you need 
to make more ugly hacks and the problems accumulate.
You must change the design, refactor, change some more and refactor again...
It may feel like waste of time at that moment but it pays off at the end. It 
makes the difference between a high quality SW and an "almost good" or "so-so" 
quality SW.


Regards,
Juha Manninen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20100306/ff4e50ab/attachment-0004.html>


More information about the Lazarus mailing list