Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / lazarus / 1999-06

[lazarus]

4 messages · 4 people ·

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Baeseman, Cliff

michael are you suggesting possibly going all the way down to the XLevel and starting there?

Just trying to get a little flexibility out of this. The GTK + tool kit is programmed very flat. It does not lend it self very well to object based programming. This in my opinion is why everyone has such a time with it.

Programming the interface in pascal is ok by me as long as I face no restrictions.

Cliff

Earlier message 59 lines
-----Original Message----- From: Sent: Sunday, June 27, 1999 1:07 PM To: Subject: RE: [lazarus] On Sun, 27 Jun 1999, Baeseman, Cliff wrote: > Michael, > > What we really need to define is a runtime implementation of something > such as the JVM for our gui development. Perhaps we need to define a common > interface that can be ported to all platforms. > > Something like this. Our code --> Interface --> GUI Subsystem. > > The Interface would be our library dll and the GUI Subsystem would be > platform code. > > The interface code would likely have to be written in C or in C++ to talk to > the GUI of the platform on its level. I disagree. It is perfectly possible to write it in pascal. The RTL is a good example of this. I am strongly opposed to mixing languages, as it is only likely to create problems. As an example, I would mention the libc -> glibc transition in the linux community: It has given us many problems. Not to mention the a.out -> ELF transition. All C stuff which forces us to adapt our code for no good reason at all. (I never saw the need to go from libc to glibc in the first place !!) Also, if you GUI subsystem changes, you may well have to adapt 2 sets of code: The pascal set and the C set. Remember the hassle to go from gtk 1.0 to 1.2 ! > > This would be a great undertaking but our GUI code would be totally portable > as long as the Interface definition did not change. > > > This is the most flexible arrangement that I can think of... Agreed, with the exception that I think you can (and should) write your interface in pascal. Michael. _________________________________________________________________ To unsubscribe: mail with "unsubscribe" as the Subject archives at http://www.miraclec.com/list_archives/lazarus

Reply by email

Michael A. Hess
to Baeseman, Cliff
Cliff wrote
michael are you suggesting possibly going all the way down to the XLevel and starting there?

I'm also interested. Is that what you mean Michael???

At this point we seemed to have been trying to leverage on the GTK or KDE widget sets but we really don't have to. The component classes we are establishing in the FCL already are a very good basis for it's own widget set. After all that is what Delphi does. It mainly uses Windows primatives to draw the components. Maybe we should just develop our own widget set.

I am for this if everybody else is. For one reason it will allow us to make the FCL much more extensible. One of the reason I love Delphi is that I can take an existing component redefine part of the components methods such as the Draw method and create a totally new look for the component without the need to code all the messaging and event stuff. IF we still with something like GTK or anyother third party GUI we will not be able to adjust the widget set from with FPC or the FCL. We will HAVE to adjust GTK.

This might take us longer to create the FPC FCL but it would allow us to be more flexible with the porting issue. For example all that would need to be changed in the Windows version would be the low level primatives that need to do the drawing. We would call Windows API calls instead of X11 calls. Maybe we only have to go as far as GDK for the primatives. That would still tie use to GTK to a certain extent.

Frankly I'm getting confused. :-\

More opinions???

We have close to 190 members on this list. Some of you are can assume are future users and not necessary in this to help build lazarus. How do you see yourself using FPC and the FCL in the future. Do you see advantages to our doing this one way over another?

==== Programming my first best destiny! ==== Michael A. Hess Miracle Concepts, Inc. http://www.miraclec.com

Reply by email

Michael Van Canneyt
to Baeseman, Cliff: michael are you suggesting possibly going all the way down to the XLevel and starting…
Cliff wrote
michael are you suggesting possibly going all the way down to the XLevel and starting there?

No. Just program the 'Interface' in pascal.

Just trying to get a little flexibility out of this. The GTK + tool kit is programmed very flat. It does not lend it self very well to object based programming. This in my opinion is why everyone has such a time with it.

Hmm.
The designers boast that GTK was designed to resemble OOP as much as possible :-)

Programming the interface in pascal is ok by me as long as I face no restrictions.

There are none that I can think of, except maybe interfacing C++ libs. (and even that can be solved)

Michael.

Reply by email

Ove Kaaven
to Michael A. Hess: I'm also interested. Is that what you mean Michael??? At this point we seemed to have…
Michael A. Hess wrote
We have close to 190 members on this list. Some of you are can assume are future users and not necessary in this to help build lazarus. How do you see yourself using FPC and the FCL in the future. Do you see advantages to our doing this one way over another?

Well, what is the goal of this project? Isn't it to create a free and usable high-level (RAD) application framework?

Creating your own widget set does not comply with this goal, for many reasons:

GTK+ is very flexible, portable, free, and very widely used. It has language bindings and themes. If you create your own widget set, it won't be able to take advantage of this (themes etc). This creates vastly less user interface flexibility for developers and users, because whatever lazarus can do will be limited to what the lazarus programmers put in.

And unless you are 50 developers (how many developers wrote GTK+? And it took *years*), that would always be less than what's in GTK+. And unless you complete the goal (make lazarus usable), you won't get enough interested new developers over either - they will instead all go over to using GTK+ and improving it faster than you could hope to follow. The project would look hopelessly outdated and would probably also never reach its goal. And if it was released before then, nobody would use it.

You would have failed. Your effort would be wasted. The project would be a fad. And for no good reason.

For various reasons, Open Source software cannot tolerate the kind of lack of standards, flexibility loss, and fragmentation it implies to re-invent cars (not just wheels) to this degree. You'd experience this soon enough.

(By the way, it is also said that a mediocre programmer reinvents wheels - a true hacker finds existing code to work with.)

On the practical side, you can take example of the wxWindows C++ cross-platform application framework. It can use GTK+, it puts it into a full OOP framework, but it also had a small problem with what GTK+ couldn't do out-of-the-box some things developers would expect to be able to do to a window - so they simple wrote a GTK+ widget tailored for their wxWindows class (win_gtk.c, you could probably even steal it). GTK+ lets you do this, write your own custom widgets without having to change GTK+.

Isn't that everything you wanted, but with the exceptional flexibility, usability, and dependability of GTK+ in addition (not to mention GTK+'s future innovations that you could never keep up with otherwise)?

Reply by email