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