[Lazarus] Is Lazarus project in a downward spiral?
Thomas Lösel
thomas at softelan.com
Sat Mar 6 14:10:33 CET 2010
Dear all,
I'm not an active developer of Lazarus (hope to use it in the future)
but how it is about the following idea:
step 1: addition of a priority index in the list of open issues, e.g.
high = necessary for version 1.0
middle = necessary for later versions
low = just nice to have also
step 2: freeze the status of all developments with middle and low
priority and concentrate all effort for the actions with high priority
step 3: soon release a version 1.0
This is transparent and brings lazarus in an upward spiral imho.
Thomas
Am 06.03.2010 um 13:51 schrieb Juha Manninen:
> 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
> --
> _______________________________________________
> Lazarus mailing list
> Lazarus at lists.lazarus.freepascal.org
> http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20100306/da59243f/attachment-0004.html>
More information about the Lazarus
mailing list