[lazarus]
John Margaglione
jmargaglione at hotmail.com
Sun Jun 27 23:47:32 EDT 1999
I don't believe the GDK is wrapped, just GLIB and GTK. And now for a few comments:
Wrapping XLib is an ENOURMOUS amount of work. Period. I think it is important to note that we are developing an IDE. Integrated Development Environment. Delphi is an IDE. Delphi did NOT create a brand new widget set to address it's windowing controls. It used the *standard* widgets available for Windows, then wrapped them. Now, we don't have the luxury of choosing the standard widget set for XWindows and Windows, because there is none. We do, however, have two sets of widgets that are gaining VAST acceptence: Qt and GTK+. I think that using GTK+ would be a major *advantage* for us. Developers want the coolest looking widgets they can get their hands on. The GTK+ toolkit was developed by the makers of GIMP, some of the coolest graphics stuff out there. I simply doubt that any of us can make a cooler-looking widget set. Not in this century, anyway. There are other advantages to sticking to GTK+:
1. glade projects can be ported to Lazarus with minimal amounts of GUI recoding, as we can easily write a program that takes the XML and turns it into a .dfm.
2. We don't have to spend our lives keeping up with the latest component crazes, we just make a wrapper and get on with our own stuff.
3. It is currently *much* more important that we get the rest of the IDE working before we get our own widget libraries built. The most popular functions in IDE's today are:
Intellisense
GUI Form Builders
Integrated Debuggers
Database Integration
Object Browsers/Class Trees
Syntax highlighting
Integration with COM/CORBA/whatever
None of these features are helped by the choice of widget set except the Form Builder, and since glade/gIDE/etc can build interface builders with GTK, so can we. I simply don't see the *relative* worth of spending months of coding time (and it will be months, not weeks, even with several of us working) just to get a little more control over the widgets. If drawing a custom widget is so important, then we can make a TCustomControl that only provides a GDK canvas (we are wrapping the TCanvas for this, right?). Then people can build any weird thing they want.
I simply think that very few application writers are in the business of subclassing controls. Sure, low level component developers do this, but that is a very small percentage of the workforce. Most developers want the list from above.
We need to prioritize some of this FAST, before we fragment into camps.
John
----- Original Message -----
From: Cliff Baeseman <vbman at pcpros.net>
To: <lazarus at miraclec.com>
Sent: Sunday, June 27, 1999 8:51 PM
Subject: Re: [lazarus]
: Is GDK in any of our currently ported headers. I cannot remember and do not
: have the FPC loaded back just yet.
:
: Cliff
: -----Original Message-----
: From: Michael A. Hess <mhess at miraclec.com>
: To: lazarus at miraclec.com <lazarus at miraclec.com>
: Date: Sunday, June 27, 1999 8:41 PM
: Subject: Re: [lazarus]
:
:
: >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.
: >--
: >==== 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
: >
:
: _________________________________________________________________
: 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
mailing list