Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-devel / 2000-11

Systems 2000 report

14 messages · 6 people ·

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Sebastian Günther

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

Reply by email

md
to Sebastian Günther

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 156 lines
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 - http://lists.freepascal.org/mailman/listinfo/fpc-devel

Reply by email

Unknown author
to Sebastian Günther: what follows is a short report about these year's Systems, a major annual trade show here…
Show quoted text 15 lines
- 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.

Show quoted text 5 lines
- 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 ?

Show quoted text 21 lines
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.

Show quoted text 21 lines
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.

Show quoted text 12 lines
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.

Reply by email

Sebastian Günther
to md: you briefly reviewed KDevelop in your message. Give Codeforge a try. www.codeforge.com.…
md wrote 7 lines
Sebastian, you briefly reviewed KDevelop in your message. Give Codeforge a try. www.codeforge.com. I found it best when working with FPC.

Really? Didn't know this, sorry... But I will give it a try.

What might be good for KDevelop is its similarity to Visual Studio, which I like really much. But in the long term I hope to get a multiplatform graphical IDE for Free Pascal, so I didn't check all available C/C++ IDEs already available...

- Sebastian

Reply by email

Sebastian Günther
to Unknown author: This is not different from previous versions of Delphi, just the mechanism has been…
Show quoted text 6 lines
> - 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 ?

Not really, only people from Borland Germany.

Show quoted text 7 lines
> 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.

Hmm yes, but the question is wether we'd have to support Qt completely as well in this case. But I cannot say very much on this topic now, as I don't know the technical details of KDE 2 yet.

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.

Exactly. But OTOH, this will only be useful for us if KDevelop is more powerful than a usual text editor (mc's cooledit or whatever). We'll see... KDevelop 1.3 is C/C++ specific, so we'll have to wait for 2.0 (or until it gets in a more or less usable beta state).

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

Of course, but this has to be done. And to be able to compete with Kylix here, we'd have to develop some components which make the writing of Apache modules more easy.

- Sebastian

Reply by email

Sebastian Günther
to Stefan: The IDE _most definitely_ does *NOT* use Wine to run. Whoever told you, does not have a…
Stefan wrote 7 lines
: On Fri, 10 Nov 2000 14:44:52 +0100, Sebastian Günther wrote: >- The Kylix 1.0 IDE _will definitely_ use Wine to run. The IDE _most definitely_ does *NOT* use Wine to run. Whoever told you, does not have a clue.

I was told that this is the same situation as with JBuilder: The first version is based on old technology (i.e. the old Win32 IDE), and Kylix 1.0 will be used to develop the next version.

It doesn't make sense to discuss this here, as we'll have to wait for the first release. The version which was presented on Systems still was based on Wine, but looked quite good; I can only say what a Mr. Ua (strange name?) told me yesterday...

- Sebastian

Reply by email

Sebastian Günther
to Stefan
Stefan wrote
Bernd Ua.

yes, exactly

I have no idea how much he knows about Kylix, but the statement "The Kylix 1.0 IDE _will definitely_ use Wine to run" is false.

as I said, I cannot comment further on this... :)

cu,
Sebastian

Reply by email

Javier Ros
to Sebastian Günther: Really? Didn't know this, sorry... But I will give it a try. What might be good for…

I've seen this discusion, and althought you are surely aware of it, let me remember
thar source navigator is a very nice multiplatform GPL working environment
with support for various languages, and with an API that make support for new
languages easily available (documentation and examples included).

http://sources.redhat.com/sourcenav/

Javier Ros Ganuza. Dpto. Ingeniería Mecánica. Univ. Pública de Navarra. Campus de Arrosadia s/n. 31006 Pamplona. Tel. 34 948169307 Fax. 34 948169099

Reply by email

Unknown author
to Stefan: I am not certain how you got hold of this detail, but, in any event: This is incorrect.
Stefan wrote 6 lines
: On Fri, 10 Nov 2000 18:23:43 +0100 (CET), wrote: >It is unwind.so; this is a mechanism for working up the stack of the >procedure in which the exception occurred. I am not certain how you got hold of this detail, but, in any event:

I am not at liberty to say this.

>It means that all Kylix apps will need to ship with this library. This is incorrect.

And on what do you base this then ? If exception support is based on unwind.so (as it is according to my info) then a kylix app needs this lib, unless it is linked in statically, of course.

Michael.

Michael.

Reply by email

Unknown author
to Stefan: The IDE _most definitely_ does *NOT* use Wine to run. Whoever told you, does not have a…
Stefan wrote 6 lines
: On Fri, 10 Nov 2000 14:44:52 +0100, Sebastian G�nther wrote: >- The Kylix 1.0 IDE _will definitely_ use Wine to run. The IDE _most definitely_ does *NOT* use Wine to run. Whoever told you, does not have a clue.

Hah, have you seen the IDE ? have you run 'ldd' on it and checked that it does not use it ? until you can say that you did, I would be careful with saying that someone 'does not have a clue' .

Have a look at nntp://forums.borland.com/borland.public.kylix.non-technical

It most definitely DOES need that, it was even published on their web site, that initial versions of the IDE would use wine. I am not claiming that later versions (when the CLX is stable enough) will still use it, but it was said (don't have the URL anymore) that initial versions WOULD and indeed do use wine.

Applications produced with the IDE will not use it, since they will use Qt; but the IDE is another matter. The IDE is tightly bound to windows, with it's use of the registry, BDE, COM and so on; it would not be realistic to expect it to be ported in less than a year to a non-windows environment.

Michael.

Reply by email