[Lazarus] nonlcl basic issue: is codetools LCL dependent?

Giuliano Colla giuliano.colla at fastwebnet.it
Fri Jun 27 20:53:36 CEST 2014


Il 27/06/2014 19:08, Juha Manninen ha scritto:
>
> On Friday, June 27, 2014, Giuliano Colla <giuliano.colla at fastwebnet.it 
> <mailto:giuliano.colla at fastwebnet.it>> wrote:
>
>     But given this possibility, I find much more interesting and
>     stimulating the attempt to take advantage of this feature, than
>     the boring task of converting hundreds of Kylix applications to LCL!
>
>
> Is it a boring task? It could be relatively easy because there are not 
> many 3rd party libs for Kylix and the code does not call WinAPI 
> extensively.
> The converter in Lazarus is tested mostly with Delphi code, I would be 
> interested in your experiences with Kylix code.
>

My experience of migrating Kylix code to Lazarus has been quite 
frustrating. My applications aren't classical database applications, 
where once you have a working DBGrid you're done.
They provide a human interface to complex machinery, which take largely 
advantage of visual features, to provide a comfortable visual feedback, 
visibility from distance, touch screen operation etc.
You need tons of workarounds to make them work under Lazarus, and to 
comply with native widgesets features and bugs. Just to mention a few:

  *

    I must provide forms with a background image, which can't be solid
    color for better readability, and this feature is missing from LCL.
    Painting the background of a form, and keeping it updated, without
    losing a lifetime, is quite a challenge, and what works with Lazarus
    0.9.29 doesn't work anymore with Lazarus 0.9.31, because of some
    changes somewhere, which don't affect DBGrids.

  *

    Whenever you need a form to "stay on top" you never know if it'll
    work or not. For Gtk2, it did work on Lazarus 1.0.8, but it stopped
    working since Lazarus 1.1. This means that a user may lose an alarm
    which pops up, because he inadvertently touched the larger form.

  *

    A lot of components are built run-time, and this again is a sort of
    nightmare. The interaction between LCL and widgetset makes that LCL
    properties are out of synch with actual widget at creation time. If
    two components are created at run time and must have a position or a
    size relative one to the other, it's again a fight, where frequently
    you end up as a loser.

The list might go on for pages, but that's the general idea. Basically 
for each visual component I must find a work-around, and this is long, 
frustrating and boring.

All of that is not because Lazarus developers are incompetent. They pay 
attention to what the majority of users requests, and they're always 
working on quicksand, because of always changing Gtk or Qt whims, they 
can't control, but must only obey to.
As a result I can use Lazarus for some applications which aren't too 
much demanding in terms of visual features, but not for hundreds of 
Kylix applications.

Giuliano
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20140627/b5924963/attachment-0003.html>


More information about the Lazarus mailing list