"Jerry U. \"Rick\" Dawson" wrote

Based upon what I have read, though, it would seem that backing down one level to the GDK would be better than backing down two levels to the XLIB.

the best would be a component library which can do whatever you want to do (use GTK, GDK, or just GGI for example)

1. Since GTK calls the GDK, is it possible to use a combination of those two libraries?

GDK cares about the windows, painting stuff etc.; GTK implements the widgets.

Why not look at the implementation of a given GTK widget and see how it fails the object model.

GTK uses a quite mighty object model, the only problem is that it is quite a pain to use, as it doesn't rely on _any_ OOP support inside the compiler (it is written in C, not in C++).

Would it be possible to put an object wrapper on it that can call the lower level GDK calls or even XLIB calls to give the desired results? We do not have to abandon one library in favor of another if we can use both.

Of couse you could do that. But it's a lot of work...

2. Does the QT have a secondary level as well between it and the XLIB similar to GDK? IF so, how different is it from the GDK?

No, not really. Qt/Win32 is build directly on top of the Win32 API, Qt/X only uses the X libraries and does almost everything for itself. Qt is quite monolithic.

3. Can programs written against the GDK and/or GTK run under KDE?

Yes; even KDE has to use X servers and window managers.

4. If it is desired to write against the GTK or the QT, is it possible to separate the code out for those libraries so that by flipping a compiler switch we could make it a Gnome or a KDE program.

You won't need a compiler switch, instead you will have several libraries which you can link.

I read somewhere that the two camps are looking at cooperating on certain points, leading to more compatibility between them in the future.

Qt and GTK? The only thing where they will probably corporate are theme managers; furthermore it is possible that KDE 2.0 and Gnome will share the same config files.

- Sebastian

Gnome only we are kidding right?

There is no possible way I would ever link against either GNOME or KDE desktops directly.

Cliff

Maybe, but I don't have GNOME, and I don't want it on my PC. I have KDE, I like it, so why would I want/use GNOME ?

Sigh. This is an old problem. The decision was made to use GTK, let's stick to it.

Until now, 3 projects have started to work on a component library annex RAD:
Megido, Lazarus, and KCL.
2 of them seem to be stranded in the discussion 'which widget set to use'. I don't want to see a third one get caught also.

This is a discussion of more tan 10 years old, which cost large companies lots of money (Motif/Open look etc) Let's not get into the same street.

So, please, stick to the original plan. Later down the road you can still make changes. Discussing all this now will NOT get you any further.

Seems like mankind NEVER learns from it's previous mistakes. Maybe a small igloo on the south pole is a good place to live after all...

Michael.

I have been following the debate, but I must confess that I do not have enough experience with the x-window development libraries to offer any constructive opinion. Based upon what I have read, though, it would seem that backing down one level to the GDK would be better than backing down two levels to the XLIB.

I have a few questions, forgive me if I seem naive.

1. Since GTK calls the GDK, is it possible to use a combination of those two libraries? Why not look at the implementation of a given GTK widget and see how it fails the object model. Would it be possible to put an object wrapper on it that can call the lower level GDK calls or even XLIB calls to give the desired results? We do not have to abandon one library in favor of another if we can use both.

2. Does the QT have a secondary level as well between it and the XLIB similar to GDK? IF so, how different is it from the GDK?

3. Can programs written against the GDK and/or GTK run under KDE?

4. If it is desired to write against the GTK or the QT, is it possible to separate the code out for those libraries so that by flipping a compiler switch we could make it a Gnome or a KDE program.

I read somewhere that the two camps are looking at cooperating on certain points, leading to more compatibility between them in the future.

**************************************************************************** not available in any store * Jerry U. "Rick" Dawson If you order now, * work:
You will get Ginsu Knives with your * home:
Custom Database Application *
****************************************************************************

Rick,

We are currently debating all of the control issues right now.

Many of you are asking us to use the GTK. This is fine but I can tell you programming against it does have limitations.

Maybe I am not as smart as I should be also. Here is the only problem that I have with running against GTK. If you wish for the IDE to be as Delphi Like as possible you have to have a couple of things that I have not been able to create cleanly.

1. X and Y control placement.

2. The ability to resize and move a control once it is on a container.

3. The signal event model is not working very well. We need some way to control our own event model. We need to have something like our own event stack on TForm or something to that affect. Right now if I connect a function to the gtk events we will get code fall thru not to mention it has to be declared cdecl which cannot appear in a class definition.

Cliff

Sebastian G�nther el d�a Mon, 28 Jun 1999 19:08:45 +0200, escribi�:

not even that, they use different mechanims ...

btw, Sebastian, have you taked a deep look at Gnome widgets ?

I mean, doing Gtk-only is a pain in the ass for certain things, i.e. if you want to do a nice dialog box, in Gtk is around 50 lines, meanwhile in Gnome are about 5 lines.
Gnome a _lots_ of high level widgets that are ready to use, in contrast with the low level Gtk widgets.

btw, I've just convinced to the author of gIDE going to gnome-only, and I'm helping them now (in C) and is unbeliable how the code is simplyfied.

Sergio

kcl has solved this with a special placement object

2. The ability to resize and move a control once it is on a container.

same answer as in 1

KCL has solved this with a signal and slot mechanism like Qt has, which seems like a good idea to me.

I still think that building on top of GTK is a good idea, because it eliminates a lot of low-level coding, which is slow, painfully and error-prone.

Michael.

Despite the look of it, EFLIB is being discontinued, Latest I heard the author has decided to move to Java. Knowing the history of the project, i regard it highly unlikely that anything wil come of it, however much I regret it. I had high hopes for eflib :(

Concerning the OpenGUI subsystem=
1) It's not really part of eflib, in fact it was developed completely independent. I met it's author in Ukraine. It still is a mystery to me what it has to do with EFLIB.
2) Yes, it runs with FPC, under certain conditions.

But all in all, I wouldn't put my money on it. No longer, that is. A pity.

Michael.

Ok I am taking a look at the GTK + now and it looks like a move function is specified in the fixed container widget.

Shane if you get up and running today try to call that move method. If that thing works as advertised and setting widgets by calling usize works we can move forward.

This is of course if it works.

Cliff

Hello:

Interesting reading of late :)

I haven't seen eflib mentioned here. I haven't studied that project in depth, and I'm not sure how the development is going, but they've got some nice looking screenshots of their graphical componants. I'm pretty sure they're building their stuff around fpc. More info is at:

http://ftp.sunet.se/EFLIB/

mz.

I'm a bit surprised or saddened that this coinversation is stil going on. I understand it's needed but was hoping everyone would agree to go with GTK for now and worry about multi-platform later.

I have a few points that I'd like to make before giving in:

1) If we use GTK we are multiplatform. GTK runs under win32 and linux.
2) Can't we write GTK for now and seperate it as needed later? Would this be so tough?

OK, now besides those two things how can we continue? Should we start seperating the code? I would like to continue with GTK but we could seperate it right away...

Shane

>> "Sergio A. Kessler" 06/30 12:45 PM >>>

"Jeff Wormsley" el d�a Wed, 30 Jun 1999 13:16:31 -0400, escribi�:

>Yes, but also WORKABILITY. gtk compiles on Win32 - GNOME doesn't. This does assume a higher lever than is actually needed. A Dialog wrapper

could call the 60 Gtk lines to do it, the 3 Gnome lines to do it, or however many WinAPI lines to do it. The current approach is to make things with Gtk first, then seperate and add things like Qt later. Personally I think this could lead to trouble, as there may be really killer differences in the libs that might cause a complete restructuring to accomodate, and that would probably mean the first lib that didn't fit wouldn't get done. If, however, the development begins multi-lib, multi-platform, then any pitfalls like this get caught a lot earlier, and should guarantee a more flexible and well thought out design.

Agreed 100%

(btw, can you press the enter key sometimes :)

Sergio

_________________________________________________________________ To unsubscribe: mail with
"unsubscribe" as the Subject
archives at http://www.miraclec.com/list_archives/lazarus

Hello,

1. X and Y control placement. 2. The ability to resize and move a control once it is on a container.

This works for me using gtk_fixed. The code is at
http://www.clubdelphi.com/nico/ since a couple of months ago, I remember I posted here some messages about, containing code fragments.

3. The signal event model is not working very well. We need some way to control our own event model.

My only experience with events is too simple. I wonder what gtk offers in order to handle a long process called from an event handler.

We need to have something like our own event stack on TForm or something to that affect. Right now if I connect a function to the gtk events we will get code fall thru not to mention it has to be declared cdecl which cannot appear in a class definition.

I don't think it's a terrible thing if you keep it in a particular gtk unit. You identify gtk wrappers and Lazarus controls so...

greetings

Nico

Agreed :-)

Amen to that :-)

Michael.

sorry to re-introduce this to the mailing list

Sebastian G�nther wrote

I'm personally quite bored of this discussion. Do you really think it's _that_ difficult to write a re-targetable component library, i.e. a CL which supports whatever you want to?

*NO*
and this is what I've been saying in previous emails, check the mailing list archive if you want (one with the subject 'multiplatform ?')

But I've heard many people here to say:

"we must work on gtk because it's multiplatform"

and this is wrong, /wrong/, *wrong*

YOU must deal with the multiplatform issue, not expect that the toolkit resolve it for you.

and this can be done somewhat easily, in fact I've done it in my house, but stopped for lack of time.

I've done something like:

fcl/
gui/
/inc -> interfaces and multiplatform code
/gtk
/gnome
/win32
/qt
/kde
/be
/motif
/<include your platform here>

if someone want the code for this, just tell me.
(I don't know if it compile with 0.99.12, and is pretty basic) But I guess the people of KCL (FCL, MCL, LCL .. this is driving me crazy) have done a similar approach.

Megido and Lazarus.

I will not comment on KCL until I see the code.

> and this is _not_ how open source work, saying: > 'hey, let's do this, let's do that' just doesn't work who is saying this, currently

all the people.

I agree, but this come for the reasons above.

I'm quite amused about all those component library problems in Lazarus, as KCL just worked fine after just a few days of development.

because they started with the wrong idea, the very wrong idea look at the "code" if you want ...
Absolutely tied to gtk and horribly structured.

I was talking about the /gtk/ code (not pascal) vs. the gnome code needed to implement a showMessage() routine (60 lines vs. 3 lines)

and in the /long run/, when you have to do DB access, Corba access, media (audio, video, etc) access, desktop access, etc HOW do you do it with Gtk-only approach ? (or Qt-only ?)

In the long run, you will =need= Gnome or KDE, no matter what you think, no matter if you like it or not.
So _I_ think that going with the full toolkit from the begining will simplify things.
Anyway, I'm out of Lazarus for the time being.

Using GTK at least insures that the same code recompiles on 2 platforms: linux and Win32

They have.

[cut]

Nobody denies this. But for the BASIC functionality we currently need, GTK is more than enough. Add to that the alledged multi-platform issue, and there you have our reasons for sticking to GTK *at the moment*

So _I_ think that going with the full toolkit from the begining will simplify things.

No-one denies that. But you loose
1) The cross-platform issue
2) The KDE users.

For me personally, these are enough reasons to stick to GTK. But everyone is entitled to his own opinion; everyone can say 'I can do better', and implement something else (though not necessarily better).

Michael.

Hello,

And in free software the better ideas prevail, so competition

Let us the chance to make wrong decissions. To be infalible, even as part of a group, is a terrible idea :)

I don't think that there is such thing as a "better idea" most of the times, but more or less suitable one to your intentions.

Now use libgnomeui (wich is built on *TOP* of Gtk), and you can have a really nice looking dialog (modal or not) with THREE lines.

Delphi is component based. Couldn't you wrap this dialogs and put them into components that can be used from a non-Gnome app??

simplicity, simplicity, simplicity ...

Why did you write it three times then? It would have been simpler to write it just once ;)

greetings

Nico

"Shane Miller" el d�a Wed, 30 Jun 1999 13:40:50 -0500, escribi�:

I'm a bit surprised or saddened that this coinversation is stil going on. I understand it's needed but was hoping everyone would agree to go with GTK for now and worry about multi-platform later.

if you are expecting that everyone agree, you are expecting a miracle..

I have a few points that I'd like to make before giving in: 1) If we use GTK we are multiplatform. GTK runs under win32 and linux.

ok, go ahead ..

2) Can't we write GTK for now and seperate it as needed later? Would this be so tough?

DON'T ASK ! You are (togheter with Cliff) one of the leaders, then make decisions, evaluate ways and take decisions, go ahead, if you are going to ask for _every_ move then you will never finish a simple f* component.

Please, act with leadership, scream, insult me if you want, but take decisions, and try that everyone follow you because you have the most sensitive solution, show them the code ... show them the way ...
(and don't write messy code, please, I have nothing personal against you, Shane, but your code is the most messy code I've ever seen)

Sergio

hey, a year ago I was without Gtk, this imply that doing Xlib-only is a good decision ?
(if you like KDE so much, why you have Gtk after all)

I've looked at Gtk *and* I've looked at Gnome, I can say that doing an app gtk-only and not using /at least/ the gnomeui library is plain stupid.
Is like using Delphi without the VCL, exactly like this.

And see all apps that started Gtk-only, a _lots_ of them have evolucioned to use Gnome. Now ask why.

Sigh. This is an old problem. The decision was made to use GTK, let's stick to it.

I'm not the desicion maker here, I'm out of Lazarus (if anybody has doubts before)

this is because 2 of them have started with /just/ ideas, and even worse those ideas are not clean nor well designed.

and this is _not_ how open source work, saying:
'hey, let's do this, let's do that' just doesn't work

you need something done first (read the "Cathedral and.."), something to play, you need a benevolent dictator, someone with clever ideas and spare free time, someone who knows /what is doing/ and knows where to go.

This is a discussion of more tan 10 years old, which cost large companies lots of money (Motif/Open look etc) Let's not get into the same street.

I don't care about companies nor business, I only care about free software.
And in free software the better ideas prevail, so competition is good.

So, please, stick to the original plan. Later down the road you can still make changes. Discussing all this now will NOT get you any further.

Michael, I'm out, but for example, of lazarus
the function ShowMessage, it's a little mess, no ? and indeed is a very crapy dialog, if you like a dialog like Delphi you have to add more than 40 lines of code.
Now use libgnomeui (wich is built on *TOP* of Gtk), and you can have a really nice looking dialog (modal or not) with THREE lines.

simplicity, simplicity, simplicity ...

Sergio

ok, I really think it _is_ possible and we will do this, in KCL.

agreed

YOU must deal with the multiplatform issue, not expect that the toolkit resolve it for you.

I'm expecting that the component library will solve most of those multiplatform issues. Each platform has its own best-suited toolkit, so we need an abstraction layer above those toolkits.

This is quite similar to the structure of KCL:
kcl/
src/
kcl_all/
kcl_gtk/
kcl_w32/
...

> Very intersting. IMHO the biggest problem of Lazarus is that there is > too much talk and too slow progress. I agree, but this come for the reasons above.

I personally think that it is better to start with only a limited group of people and to add public discussions later on.

because they started with the wrong idea, the very wrong idea look at the "code" if you want ... Absolutely tied to gtk and horribly structured.

That's the reason why we started with KCL this soon. At first it was planned to add Qt and KDE support to FPC, but after the announcement of Lazarus and some unresolved issues regarding the compiler we decided to start with the GTK and Win32 targets.

I don't think this is important when you have a component library which wraps those internals from you.

But it will limit you in a way. BTW:
- DB access has _nothing_ to do with desktop environments
- Corba support is only partly dependend on it
- Media access is usually independent from it
- Desktop access: Most applications won't need it

But, the main problem is, that there are at least three different groups of people:
- KDE fans
- Gnome fans
- People who won't use any of them

I think a RAD IDE for FreePascal is _extremely_ important, especially under Linux; and if you choose to support *only* KDE *or* Gnome you can be sure to have about 2/3 of the people against you.

- Sebastian

"Jeff Wormsley" el d�a Wed, 30 Jun 1999 13:16:31 -0400, escribi�:

>Yes, but also WORKABILITY. gtk compiles on Win32 - GNOME doesn't. This does assume a higher lever than is actually needed. A Dialog wrapper

could call the 60 Gtk lines to do it, the 3 Gnome lines to do it, or however many WinAPI lines to do it. The current approach is to make things with Gtk first, then seperate and add things like Qt later. Personally I think this could lead to trouble, as there may be really killer differences in the libs that might cause a complete restructuring to accomodate, and that would probably mean the first lib that didn't fit wouldn't get done. If, however, the development begins multi-lib, multi-platform, then any pitfalls like this get caught a lot earlier, and should guarantee a more flexible and well thought out design.

Agreed 100%

(btw, can you press the enter key sometimes :)

Sergio

Because Qt is C++, and we can't connect to it. If we could connect to C++, I would have used Qt.

I've looked at Gtk *and* I've looked at Gnome, I can say that doing an app gtk-only and not using /at least/ the gnomeui library is plain stupid.

Thanks for the compliment :-)

Is like using Delphi without the VCL, exactly like this. And see all apps that started Gtk-only, a _lots_ of them have evolucioned to use Gnome. Now ask why.

I can understand why THEY did it.
I'm only saying that WE have different goals, which make this step NOT so obvious.

A pity. You seem to know what you're talking about. If your coding is as good as your arguments, we would evolve much faster. If we don't spend too much time discussing, that is :-)

You're telling ME ! This is how I have worked from the start of FPC ! Glad to see we agree on this :)

That is why I don't publish e.g. TDataset code yet. I'll finish it first, publish it, and then I am open for suggestions.

I will be the first to agree.

I don't look at lazarus' code, no time. I checked it in the beginning, and I was amazed that it actually worked then %-) But it does.

But this is a matter of design: If the lazarus people have messy code, then that is a problem. But it doesn't influence the discussion 'which widget set' At most, a code cleanup is needed.

Now use libgnomeui (wich is built on *TOP* of Gtk), and you can have a really nice looking dialog (modal or not) with THREE lines. simplicity, simplicity, simplicity ...

Yes, but also WORKABILITY. gtk compiles on Win32 - GNOME doesn't. If we can throw in multiplatform support, then I think it outweighs the advantage of GNOME. (yes I know you don't think that gtk ensures multiplatformness, but it at least ensures that the same code runs on 2 platforms)

Finally, nothing stops you from making a 'advdialog.pp' with a gnome dialog in it. Then that component would be available on Linux only.

Michael.

Please forgive my ignorance, but I didn't find anything on the web site and there is no mailing list archive (that I know of). Where is its web page for KCL? When I look in the Linux Software Encyclopedia all I get is Kyoto Common Lisp.

Thanks

Matt Henley

> >Qt and GTK? The only thing where they will probably corporate are theme > >managers; > > not even that, they use different mechanims ...

I've read this somewhere on the KDE homepage, they are planning to use the same theme engines in future releases.

> btw, Sebastian, have you taked a deep look at Gnome widgets ? Maybe, but I don't have GNOME, and I don't want it on my PC. I have KDE, I like it, so why would I want/use GNOME ?

yes, Gnome and KDE are a little bit too high-level for most purposes, and they add certain limitations regarding compatiblity to other desktop environments; e.g. GTK application may run under Windows, Gnome applications won't. And, as you won't use this widget sets directly but component libraries (LCL, KCL...) instead, there is no problem in using GTK or Qt. I can only speak for KCL, and currently I think there just will be several 'targets', i.e. KCL/GTK, KCL/Gnome, KCL/Qt, KCL/KDE and KCL/Win32; whereas KCL/Gnome is an extended KCL/GTK, and so on.

as you already know, KCL will not be bound to any specific widget set

- Sebastian

If these are problems or deficiencies of the gtk, isn't there a way to get these fixes or improvements rolled into the standard release of the gtk.

Matt Henley

looks good to me ...

yes, yes, yes, and when you go public, have something to play, something to hack on ...

you will ignore all the funcionality in gnome-db and kde-db ?

- Corba support is only partly dependend on it - Media access is usually independent from it

same here, there is much funcionality in gnome (gnome media framework) and kde to be ignored

- Desktop access: Most applications won't need it

Hmmm, will see ...

how about Gnome _and_ Kde _and_ Gtk-only _and_ Motif, etc ?

anyway, I think you have a winner where this thinghs can be reality, don't go public before things are cemented and you know exactly what you want.

best regards,
Sergio

Yes, but also WORKABILITY. gtk compiles on Win32 - GNOME doesn't.

This does assume a higher lever than is actually needed. A Dialog wrapper could call the 60 Gtk lines to do it, the 3 Gnome lines to do it, or however many WinAPI lines to do it. The current approach is to make things with Gtk first, then seperate and add things like Qt later. Personally I think this could lead to trouble, as there may be really killer differences in the libs that might cause a complete restructuring to accomodate, and that would probably mean the first lib that didn't fit wouldn't get done. If, however, the development begins multi-lib, multi-platform, then any pitfalls like this get caught a lot earlier, and should guarantee a more flexible and well thought out design.

Jeff.

Exactly this.
KCL and its IDE has another problem: It has to look better than Lazarus, when the first public announcement will be done... ;-)

you will ignore all the funcionality in gnome-db and kde-db ?

Sorry, I don't know them. I just know that KDE runs fine without kde-db on my system.
I think Michael v.C. is doing the right in implementing database support on a much lower level; database widgets can be added to LCL or KCL easily.

same here, there is much funcionality in gnome (gnome media framework) and kde to be ignored

can you give some examples, please?

>- Desktop access: Most applications won't need it Hmmm, will see ...

OK, the IDE won't need it, so this is not our first priority.

how about Gnome _and_ Kde _and_ Gtk-only _and_ Motif, etc ?

that is exactly what I want to do with KCL. The main reason why I started KCL whas that there isn't any comparable project for FreePascal yet.

anyway, I think you have a winner where this thinghs can be reality,

IMO it's possible

don't go public before things are cemented and you know exactly what you want.

I think I already know what I want _in the long term_...

- Sebastian

if you are expecting that everyone agree, you are expecting a miracle..

I'm not expecting everyone to agree, but I'd rather here reasons for their opinions instead of simply opinions.

I am asking so I can make a decision. Without asking for other people's REASONS behind the idea's I can't make a decision. Now perhaps this has gone opn long enough, but I still don't see any reason to change the way we are doing it..

And, btw, my code IS very messy. I know this, but remember, I'm the only one doing any code. Cliff and I started this and unless someone else gets involved, it'll stay this way until I am ready to clean it up. I am doing 98% of the coding so I don't need to clean it up for myself. However, you are correct that it is a mess, and I guess I'll clean it up a bit more so others can read it.

I have time to kill until the parsing bug in FPC is fixed.

Another point. You say "Act with leadership, scream, insult me if you want, " etc. That's not how I lead. I am writing code and if anyone wants to follow, they are free to do so. None of them work for me and none of them have offered to help in anything specific so there's nothing to tell anyone.

Shane

I am asking so I can make a decision. Without asking for other people's REASONS behind the idea's I can't make a decision. Now perhaps this has gone opn long enough, but I still don't see any reason to change the way we are doing it..

The only reason I have for questioning an intial tight integration with GTK comes from my experience with working on other programs.

As an example, the company I work for makes equipment for the vending industry. Some of our devices are similar to ATM machines, in that you insert a card and recieve funds from an account (placed on the card, though, not cash). One device is very simple, no user put in their card, and it adds some amount of funds based on the software settings. Another device is more complicated, and allows the user to select an amount. These two devices use very different communications protocols. One device was controlled by one piece of software, designed soley to control that device. The other had it's own software for controlling it. And then came the day that someone decided it would be great if each piece of software could control each device. Neither piece of software had been designed with the other device in mind, and believe me, getting those pieces of code to communicate efficiently and cleanly was not a small effort. If they had been designed differently, anticipating the need for multiple protocols (shared on the same RS-485 port), then the job would have been much simpler.

This type of situation is what I see could happen to this project as well, if it isn't approached from the beginning with multiple interfaces in mind.

In an attempt to make this easier, it would seem that what we may need is to do work concurrently on more than one platform. If you keep going on Gtk, I could work on native (non Gtk) Win32. At least that way, we could decide early on where the divisions lie. Hopefully, most of the issues that would affect other platforms like Qt, Gnome, etc. would have already been worked out. At least it would give us the advantage of having a system that was designed for multiplatform from the ground up.

I will check out the sources on my Win machine at home this evening and see if I can find good place to start.

Jeff.