<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Il 27/06/2014 19:08, Juha Manninen ha
scritto:<br>
</div>
<blockquote
cite="mid:CAPN1EhBkxeCQrFoGCP_AJe-ofeAOi+XGGazb8DTSwzxJUpQJ8Q@mail.gmail.com"
type="cite"><br>
On Friday, June 27, 2014, Giuliano Colla <<a
moz-do-not-send="true"
href="mailto:giuliano.colla@fastwebnet.it">giuliano.colla@fastwebnet.it</a>>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
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!<br>
</blockquote>
<div><br>
</div>
<div>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.</div>
<div>The converter in Lazarus is tested mostly with Delphi code, I
would be interested in your experiences with Kylix code.</div>
<div><br>
</div>
</blockquote>
<br>
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.<br>
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.<br>
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:<br>
<ul>
<li>
<p>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.</p>
</li>
<li>
<p>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.</p>
</li>
<li>
<p>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.</p>
</li>
</ul>
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.<br>
<br>
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.<br>
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.<br>
<br>
Giuliano<br>
</body>
</html>