Sign in Join

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

Mailing lists / lazarus / 1999-06

[lazarus]

3 messages · 3 people ·

Reply by email Subscribe to this list Your subscription

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

John Margaglione
to Baeseman, Cliff: What we really need to define is a runtime implementation of something such as the JVM…

My vote is as follows: NO VIRTUAL MACHINES, NO NEW API'S.

If we stick to the FCL layer, then we can swap out whatever GUI library makes us happy. Having said that, here are my thoughts on the available options:

1. Make our own GUI library: Do we want to finish the first release this century?
2. Use GTK+: the gtk project is going very well. I see no reason (non-technical) that we should not use these widgets. They are already portable to Win32 as well. Qt is portable to Win32, but only if you feel like paying a $1300 developer fee.
3. Use raw X stuff: not portable to Windows. Or anything but unix for that matter.
4. Use an XY compatible library: the whole reason for layout managers under Unix is that there is no standard video configuration. Doing X,Y coordinates for any operating system other than Windows will cause funky placement problems for components.

By the way, there is nothing in GLIB that will help you make widgets. You would have to use GDK for that, and that is exactly what GTK is built on! So there would be no savings there.

John

Earlier message 74 lines
----- Original Message ----- From: Baeseman, Cliff To: Sent: Sunday, June 27, 1999 12:17 PM Subject: RE: [lazarus] : 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. : : 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... : : Cliff : : -----Original Message----- : From: Michael A. Hess : Sent: Sunday, June 27, 1999 11:57 AM : To: : Subject: Re: [lazarus] : : : Baeseman, Cliff wrote: : > : > I have not looked to closely at it but should we be implementing at : > the glib level? Maybe totaly define our component structures based : > from glib vs the already defined widgets. : > : > What does everyone think? Suggestions Welcome. : : I have thought about this in the past. If we were intending on making : Lazarus (aka the FCL) GUI API dependent then coding directly to glib : would be the best idea. Then all compenents would be designed within the : FCL and would make inheritence of components and the ability to redesign : components based on a parent much easier. : : However, that would tie us more closely to GTK. It might make using : other APIs such as QT for KDE much more difficult. By not going stright : to glib we will be able to make interfaces directly to the GNOME widget : set which gives our FPC code immediate D&D, Corba, etc. etc. without our : having to add any of that into the FCL. So it is a trade off. I think : setting up interfaces to the various GUI APIs is the best way to go. It : removes that headache from our shoulders. : : -- : ==== Programming my first best destiny! ==== : : Michael A. Hess Miracle Concepts, Inc. : http://www.miraclec.com : : _________________________________________________________________ : To unsubscribe: mail with : "unsubscribe" as the Subject : archives at http://www.miraclec.com/list_archives/lazarus : : _________________________________________________________________ : To unsubscribe: mail with : "unsubscribe" as the Subject : archives at http://www.miraclec.com/list_archives/lazarus :

Reply by email

Unknown author
to Baeseman, Cliff: What we really need to define is a runtime implementation of something such as the JVM…
Cliff wrote 13 lines
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 !

Show quoted text 6 lines
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.

Reply by email

Baeseman, Cliff

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.

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

Cliff

Earlier message 39 lines
-----Original Message----- From: Michael A. Hess Sent: Sunday, June 27, 1999 11:57 AM To: Subject: Re: [lazarus] Baeseman, Cliff wrote: > > I have not looked to closely at it but should we be implementing at > the glib level? Maybe totaly define our component structures based > from glib vs the already defined widgets. > > What does everyone think? Suggestions Welcome. I have thought about this in the past. If we were intending on making Lazarus (aka the FCL) GUI API dependent then coding directly to glib would be the best idea. Then all compenents would be designed within the FCL and would make inheritence of components and the ability to redesign components based on a parent much easier. However, that would tie us more closely to GTK. It might make using other APIs such as QT for KDE much more difficult. By not going stright to glib we will be able to make interfaces directly to the GNOME widget set which gives our FPC code immediate D&D, Corba, etc. etc. without our having to add any of that into the FCL. So it is a trade off. I think setting up interfaces to the various GUI APIs is the best way to go. It removes that headache from our shoulders. -- ==== Programming my first best destiny! ==== Michael A. Hess Miracle Concepts, Inc. http://www.miraclec.com _________________________________________________________________ To unsubscribe: mail with "unsubscribe" as the Subject archives at http://www.miraclec.com/list_archives/lazarus

Reply by email