d0hb0y at lynq.com
Sun Jun 27 21:55:06 EDT 1999
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
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" ?
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 :)
At 09:29 PM 6/27/99 -0400, you wrote:
>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
>> 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:
>All of these than have the standard outlined or filled what color, 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.
>==== Programming my first best destiny! ====
>Michael A. Hess Miracle Concepts, Inc.
>mhess at miraclec.com http://www.miraclec.com
> To unsubscribe: mail lazarus-request at miraclec.com with
> "unsubscribe" as the Subject
> archives at http://www.miraclec.com/list_archives/lazarus
More information about the Lazarus