If I understand correctly then, it would be theoretically possible for someone to "subclass" the standard GDK interface being written in native FPC for Lazarus. This then allows users to write apps that used KDE or GNOME specifically, as an option, thus bypassing the low-level GDK access provided natively.

Am I correct about this?

If this is true, this truely does give Lazarus the best of both worlds. I have heard several people complain about requiring QT or GNOME to run certain apps -- going with native Xlib calls would effectively allow you to compile the gui support directly in without having to install anything extra except for Xwindows itself. This would make those users happy. And for developers who want to build upon existing systems in QT/GNOME, or enhancements to the Desktop by using and subclassing QT/GNOME components, that option would also be available, theoretically.

Returning to Earth now... Realistically, although devloping Xlib interfaces will be more tedious than using QT/Gnome interfaces, I see Xlib offering a "stable" unchanging platform to develop this software. The last thing I think anyone would want to do is re-write something because QT changed to support some new whatchamacallit. (QT/GNOME may be more "unchanging" than this but I dont know :)

So, how long till I can drop a textbox and a command button onto a form and
write "Hello World" with one line of code:  text1.text := "Hello World" ?

*GRIN*

PS: Is it possible to steal code from QT or Gnome and port it into Lazarus, such that writing some screen components takes less time that writing em from scratch? All this open source software laying about ... maybe someone on QT or Gnome's development team would join in the effort to get more complicated objects "functional" in native lazarus code. (Worth a shot, anyway :)

== Ron

I'm not real familiar with XLib so let me ask this. Is the XLib the method that was used to write KDE and other GUI's? Or is it simply another component library?

If it's what's used in the desktop environments then using it would be great. It would again take some learning on our parts again. Can we then create a unit that has a CREATECOMPONENT and SENDMESSAGE and such that will interface with X11 library? I would think that's the best way to do it. The Forms.pp file would contain a class called TFORMS and in it's create constructor we would call a procedure called createform or createcomponent and pass a component type. In the X11 unit we write we would have that procedure call X11 stuff to get it done. I think that would solve some of the problems we are now having, like positioning the controls, resizing them, etc.

Shane

Shane Miller wrote

I'm not real familiar with XLib so let me ask this. Is the XLib the method that was used to write KDE and other GUI's? Or is it simply another component library?

Xlib is the X11 system. It is what was used to write the GDK. Then GTK was written using the GDK. Then Gnome is written using the GTK. The same kind of process goes for KDE. Qt's primatives (I don't know their name) are written to the Xlib. The Qt widgets are written to use the Qt primiatives. KDE is written using the Qt widgets.

What we are talking about is writting our own GTK or Qt or what we would call the FCL. Our FCL would talk to the Xlib directly. To skip some of this headache we could use GDK instead of going all the way down to Xlib.

Can we then create a unit that has a CREATECOMPONENT and SENDMESSAGE and such that will interface with X11 library?

We would be able to do ANYTHING we wish. All of the messaging component interaction would be written by us in the FCL. We would not be calling or using any other libs other than the standard X11 libs which you have to use even with GTK. The GDK might be easier to use as the low level graphics primatives since it already takes care of many of the headaches involved with accessing the X11 libs.

Think about it this way. If you look in the Delphi VCL most of the direct Windows API calls are only found within the Draw methods of any component. That is what we are talking about. All the rest of the component would be written entirely with FPC in Pascal. Only the Draw method would need to be written to address how the widget in question looks and is...well drawn. We could call Xlib directly or as I said overcome alot of Xlib headaches by using GDK. This is the "Graphics Drawing Kit" that is the basis of GTK. The other advantage to using the GDK is that it is already ported to Win32. If GTK has been ported to Win32, well then GDK has been as well. We would write our components once using GDK and any platform that has GTK/GDK would be able to use the FPC and the FCL. We still get the portability of the graphics primatives but aren't tied to the widget set of GTK.

The GDK has all your basics:

Draw Pixel
Draw Lines
Draw Rectangles
Draw Polygons

All of these than have the standard outlined or filled what color, etc. etc.

I think this way of doing the FCL gives us the most flexibility within FPC. We will not be tied to a limited widget set established by some other third party API.