[lazarus]

[Nicolas Aragon]

Hello,

>Wrapping XLib is an ENOURMOUS amount of work.  Period.  

Do you know that headers are translated long time ago? Yes, I know
that it isn't all the work to do. But after some tests, I haven't
found much harder to program for Xlib than for gtk, provided that you
are writing wrappers, not programs and that sooner or later you'll
need to write some canvas stuff, UNLESS you intend to tell your
customers "if you want to customize this component, learn C".

Please notice that I don't propose to throw away gtk. I propose to
leave the door open to support gtk, qt, Xlib, winapi.... please read
my other message about "multiplataform".

>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.  

They didn't do that because of saving code time. But looking for
performance. 

>Now, we don't have the luxury of choosing the standard widget set for XWindows and Windows, because there is none.  

Let the user choose his favourite widget set instead.

> 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.  

The look is the smallest problem. The main problems are:

1. Creating efficient code to responde to paint events
2. Caring about alot of details about keyboard, mouse, coulours,
captions...
3. Things like c&p and communication with other applications.

>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.  

Why not use XML natively? Delphi 5 is said to abandon dfms in favour
of XML, BTW.

>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.

You can also do it with my proposal.

>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

Let's build the ide on top of a portable set of components, and use
gtk at first, or simply work in parallel. There seem to be here enough
people. And in Megido list. And KCL people seem to be quite advanced.

>the *relative* worth of spending months of coding time (and it will be months, not weeks, even with several of us working) 

It depends on what you want to do. Anyway, again: you don't need to
choose. Versions for all libraries don't need to be completed at the
same time.

>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.  

You'll find out that people wants that "weird" things most of time. No
powerful language/library/environment is so poweful if you can't step
down some levels when you need to.

>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.  

I completely disagree. Take a look at Delphi sites. They're plenty of
components using low level features. People love weird buttons,
toolbars, labels... Of course, component users don't need to be aware
of how they're implemented. But component writers do. I don't like the
landscape of component programmers in the need of learning C in order
to write custom components.

>We need to prioritize some of this FAST, before we fragment into camps.

I don't think it would be bad if we keep a common part that works for
everybody.

greetings

   Nico