[fpc-devel]Systems 2000 report

[md]

Sebastian,

you briefly reviewed KDevelop in your message.  Give Codeforge a try. 
www.codeforge.com.

I found it best when working with FPC.

They will have even tighter integration with the compiler/debugger in
version 2.0.  The latest release is 1.6.

Mark Diener

Sebastian Günther wrote:
> 
> Hello *,
> 
> what follows is a short report about these year's Systems, a major
> annual trade show here in Munich, Germany. But be warned that most of it
> is Linux specific stuff.
> 
> I will cover the following topics:
> 
> - General remarks
> - Kylix
> - KDE
> - KDevelop
> - Apache
> - XFree86
> 
> General remarks
> ---------------
> Two years ago the 'LinuxPark' has been introduced at the Systems. As you
> might guess, this is an area dedicated to Linux projects and companies
> which do active development for Linux. Besides from the OS itself, Open
> Source is an important topic there, too, of course. So this is the right
> place to go for FPC members as well...
> BTW, one the one hand I'm really impressed how many people have heard of
> Free Pascal. But OTOH most of them don't really believe in its success;
> but this isn't very surprising when you talk with C/C++ developers... ;)
> 
> Kylix
> -----
> Borland presented the current version of Kylix a.k.a. Delphi for Linux,
> which is far ahead of the last Field Test, it seemed. They installed
> Kylix on two Linux boxes, and I was able to talk with someone from
> Borland for about 1 hour or so... Some facts: (perhaps not all are new,
> but nevertheless)
> 
> - Kylix 1.0 should be available in Q1/2001. They hope to get everything
> finished in January, but February should be more realistic.
> 
> - The Kylix 1.0 IDE _will definitely_ use Wine to run. While they have
> managed to fix all cosmetic problems by now (i.e. the IDE they presented
> looked quite good, including the fonts, and even worked quite stable -
> only the focus handling was a major problem...), this will result in
> high memory requirements, I think. The speed should be okay on a modern
> machine, but I expect that it will feel quite slow on lower-end machines
> which still would run Delphi fine.
> 
> - The online help is done via a WinHelp viewer for Unix from Bristol
> Technologies. The integration with the IDE wasn't implemented yet in the
> version they presented.
> 
> - While the IDE itself uses Wine, the form designer uses the Qt based
> components. (of course)
> 
> - shared objects: The initialization and finalization sections of units
> are supported
> 
> - 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.
> 
> - 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...
> 
> - 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...
> 
> 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.
> 
> 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)
> 
> 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.
> 
> XFree86
> -------
> At the XFree86 booth, they showed the usual stuff... X running on a
> Matrox 4-port graphics adapter (i.e. it controls 4 screens at once), and
> X running on different screens with different orientation at the same
> time...
> What's more interesting is XRender: Besides other things, this extension
> will enable applications to use anti aliased text. Everybody who knows X
> knows that the font rendering is a major annoyance. XRender will use
> FreeType2 to display antialiased TrueType fonts. Existing applications
> won't benefit from XRender, which one might see as a major problem; but,
> the XFree86 people had a convincing argument: Only the existing graphics
> libraries has to be adapted - i.e. modifications to Motif/Lesstif, Qt
> and GDK are necessary, and over 90% of all X applications will profit
> from XRender. For FPC it's clear that I have to extend fpGFX a little
> bit...
> 
> this should be enough for now... :)
> 
> - Sebastian
> 
> _______________________________________________
> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-devel