[lazarus]

Sun Jun 27 23:50:34 EDT 1999

You have my support.  I like the idea of allowing developers as much flexibility
as possible, even at the expense of a little longer time to develop. 

There isn't really a timeline here.  It will be nice to have Lazarus complete,
but it seems to me that it would be much better to take longer and do it right
than to just throw something together so we can have it done fast. I think we
would regret it eventually.  If Lazarus is too limited, it will get a bad
reputation and people won't use it. 

So my vote is to go to the XLib level if necessary and do it right. If we can
accomplish the same thing and use GDK, then all the better. But if not, we
should go down to the XLib level.

Curtis

On 28-Jun-99 Cliff Baeseman wrote:
> Yes this is exactly what we are talking about you are right on track.
> 
> This will seperate us from the great GNOME and KDE debate all together.
> 
> As for how long it soley depends on support from the others on the list.
> 
> 
> Cliff
> 
> 
> -----Original Message-----
> From: d0hb0y <d0hb0y at lynq.com>
> To: lazarus at miraclec.com <lazarus at miraclec.com>
> Date: Sunday, June 27, 1999 9:07 PM
> Subject: Re: [lazarus]
> 
> 
>>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
>>
>>
>>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
>>>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
>>
> 
> _________________________________________________________________
>      To unsubscribe: mail lazarus-request at miraclec.com with
>                 "unsubscribe" as the Subject
>     archives at http://www.miraclec.com/list_archives/lazarus

----------------------------------
Curtis White
Curtis White <osiriz at teleport.com>
http://www.teleport.com/~osiriz/
----------------------------------