[fpc-devel]Systems 2000 report

[Michael.VanCanneyt at Wisa.be]

On Fri, 10 Nov 2000, Sebastian [iso-8859-1] Günther wrote:

> - WideString: A WideString is stored as reference-counted UTF-8 string,
> because someone at Borland is said to have found out that UTF-8 is the
> most usual encoding for Unicode strings. Technically, a WideString in
> Kylix seems to be identical to an AnsiString, plus some automatic
> conversions etc. added.
> 
> - Kylix will not feature anything XML based... (but Delphi 6 will get
> its own XML parser, independent from MSXML or similar libraries - this
> is different to the latest beta, btw)
> 
> - the database support looks quite good; perhaps a little bit
> complicated for beginners, but it is quite powerful. I don't know how DB
> support works in current versions of Delphi, but in Kylix you can buffer
> all modifications and commit them at once - mainly to reduce network
> traffic. Support for transactions can be added easily.

This is not different from previous versions of Delphi, just the mechanism
has been changed/extended a little. 

> 
> - The Exception Handling might be quite strange: It works exactly the
> way it works for Win32, and I was told they had to write a special
> library (an additional .so file) for exception handling. Unfortunately I
> got no further technical details...

It is unwind.so; this is a mechanism for working up the stack of the
procedure in which the exception occurred. Win32 provides this mechanism by
default. It means that all Kylix apps will need to ship with this library.

> 
> - Resources are not fully supported: While you can access a resource via
> its name, you cannot enumerate them. Sounds strange, but nobody knew
> further details...

Sounds like none of the developers were there ?


> 
> 
> KDE
> ---
> The usual KDE people were present; I tried to find out how far it is
> possible for future FPC projects (fpGUI etc.), to integrate with KDE
> (optionally of course!).
> While the KDE libraries have a C++ interface and cannot be used directly
> with FPC, KDE2 makes use of DCOP in many places. Strangely enough nobody
> was able to explain what DCOP exactly does, but it's something similar
> to COM/DCOM or CORBA, but quite lightweight and based on libice (ICE =
> X11 interprocess communication). As there is a C wrapper for the DCOP
> library, it should be easy for us to support DCOP. What's nice about
> DCOP is its dynamic structure, i.e. there is no persistent registry - an
> aplication or applet registeres itself at runtime, and can be discovered
> by other applications.
> 
> We'll see in which way future GUI libraries will be able to offer
> support for more advanced things such as tray applets in a platform
> independent way... But at least for KDE it looks quite good; for Gnome I
> don't expect any problems as well as it's C based.

Even Kylix uses a C wrapper for Qt, there is no problem in providing
something similar for KDE.

> 
> 
> KDevelop
> --------
> I talked quite long with Ralf Nolden from the KDevelop team - starting
> with general KDE topics, then about KDevelop itself. The essence: In a
> few months, KDevelop 2 should be available. While KDevelop 1.x is an IDE
> solely for C/C++ applications, they want to be totally open with
> KDevelop 2. It will have a modular architecture, which allows different
> languages to be supported; you will be even possible to specify the
> editor (Emacs, vi(m)...) to use (this is done by special embedding
> wrappers). Now they try to convince as many people as possible to write
> KDevelop support for their applications (icon editors, translation tools
> and so on); and of course he tried to convince me that adding Free
> Pascal support to KDevelop wouldn't be very hard. BUT it seems as such
> the plugins must be written in C++.
> Hmm... I don't know. It is really possible that it's better for us in
> the short term to use KDevelop, until we have our own graphical IDE. A
> major problem is that KDevelop will only run on Unices, but not on
> Windows. (It's not a problem for me personally, but I'm tired from the
> OS flamewars... so I recognise the demand for a graphical IDE for Win32)

I think the time needed to add FPC support to KDevelop would be better
spent on improving our own tools; like you said, 'in the short term', yes,
but in the long term: no.

> 
> 
> Apache
> ------
> As it will be possible to write Apache modules with Kylix, I just asked
> two Apache guys how complicated it is to translate the headers for FPC.
> This doesn't seem to be a big task: An Apache module just has to export
> a public symbol, which is a simple data structure containing some
> pointers. But it will be a little bit of work to translate the hundrets
> of API functions of Apache. BTW, as usual the Linux version uses 'cdecl'
> and the Win32 version 'stdcall'... but everything is plain C, so adding
> support for Apache modules to FPC is possible.

The apache header file translated is about 1000 lines; this is much less
than GTK, so it should be possible to do this.

Michael.