At 11:57 PM 22/07/2005 -0600, you wrote:

>Is there some solid IBObject support for Kylix planned in the close near
>future ? If so when ?

It depends on what you mean by "solid". The current data access beta
works fine. You can write Kylix 2 or 3 apps with IBO-Kylix
connectivity. You can connect the TIBO-- components to the CLX TDatasource
and write GUI apps within the same limitations as any Kylix data-aware
GUI. You can work with the TIB_-- (native IBO) components with a
non-data-aware interface. That's the position with Beta 005, which is
built on IBO v.4.2Hc.

We have had the pieces of a Beta 006 around for several months now,
bringing IBO-K up to date with IBO 4.3Ab. Included there are some native
IBO controls, converted by Andrew Haines, that work, to some extent. They
will never be "just like IBO" because of the limitations of the underlying
controls mechanism (X, Qt and GTK) as compared to the Windows common
controls and the Win API that underlie the Windows controls.

For example, a TIB_Grid like the Windows one is probably out of reach; and
that affects other controls like TIB_LookupCombo...

The Linux version issues don't appear to be as big a deal at the moment for
ObjectPascal and Lester suggests they are for BuilderX. There is a wide
gulf between the version 8.~ distros of the main (Borland-supported)
distros and the versions 9.~ and above distros with respect to C++. I
believe that is a source of major headaches with later Linux distros. I
have K3 Delphi installed and running on Mandrake 10.1, with the
backward-compatibility packages for the glibc runtimes. The Kylix 3 IDE
runs in its own (old) version of the Wine server and accesses its own (old)
version of Qt 3. I haven't *so far* encountered any problems that are
obviously related to

The release of our Beta 006 is hung up, currently, waiting for an
architectural restructuring of the code tree to bring it into line with IBO
4.3 and above. If you are familiar with the IBO sources, you'll be aware
that Jason did this major restructure at IBO 4.3.

Decisions have to be made about the synchronisation of the two code trees,
in the light of issues like the differences between the underlying
architectures of the CLX and the VCL. It will not be a big deal to keep
the non-visual classes in sync with IBO: we can continue to do this with
includes, as we do now. Trying to sync CLX visual classes with the VCL
classes is much more problemmatical.

I have made some recommendations to Jason on these issues. However,
understandably, IBO-K hasn't been high on his priority list since Borland
admitted that they have abandoned development of Kylix for an unspecified
forseeable future. They deny that Kylix is a dead product but they can't
say when or if development will ever resume.

Helen