Mattias Gärtner ha scritto:
Zitat von Giuliano Colla <[EMAIL PROTECTED]>:
I'm trying to implement an usable port of CLX to Lazarus.
So I've created a CLX package which declares to provide the same as LCL.
So far it works as expected, but unfortunately CLX unit names are
different from VCL/LCL: QForms instead of Forms, QButtons instead of
Buttons etc. Unit names can't be changed less changing them in all
applications, which impairs easy porting.
The obvious consequence is that if a component is added on a form from
IDE, the IDE adds the unit it knows (e.g. STdCtrls) instead of the one
from the package (QStdCtrls). This is unavoidable, unless IdeIntf is
properly hacked. But it happens on the unit one is working with, so it's
easy to fix, at least temporarily. All what is required is to remove the
unit if it's already there with the Q prefixed name, or to prefix a Q to
the name if it wasn't there.
Correct.
I'm not sure how this should be solved.
Hacking IDEIntf has the drawback, that switching to a LCL project will not work.
If my project ever reaches an end (because there's an endless list of
small things to adjust), I was thinking to a very radical approach: a
Lazyx tree (hacked Lazarus for CLX), separate from Lazarus tree. If the
hacking can be achieved with a manageable number of ifdef controlled
includes, it shouldn't be too difficult to maintain it in parallel (just
deriving a new version from the main tree when appropriate). Then one
can use Lazyx for Kylix salvaging, and Lazarus for new projects. Not
very elegant, but acceptable IMHO.
I guess a the provides page must be extended with alias components. OTOH the
next problem are the properties. You need some other property editors to
show/hide the correct properties. And they must be loaded/unloaded whenever a
CLX project is loaded/unloaded.
If this opens the road to alternative component libraries (such as
fpGUI) then it could be an interesting and valuable enhancement, but I
don't believe it would be worthwhile just to support CLX. I do need it,
but CLX is based on a Borland hacked version of Qt 2 and therefore it
doesn't have a bright future in front. There's a port to Qt 3.2 from
Andreas Hausladen and Zeljko, while a port to Qt 4 hasn't been fully
successful. They could be exploited but currently with many question marks.
What's more annoying is that also the LCL dependency is added to the
project requirements although the CLX package declares to provide "LCL".
I found the bug. I will commit the fix tomorrow.
Thanks a lot.
Giuliano
--
Giuliano Colla
Whenever people agree with me, I always feel I must be wrong (O. Wilde)
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
