Nope cross platform is not a issue. My c++ code is ansi standard and can be compiled on a winbox if and when I wish to do it. As for a QT implementation we have no choice but to go down this path until Free Pascal can link C++ code. I am working like hell to get the QT event triggers working with our model now. I am very close and a few guys from the KDE teams are giving me a hand. Once the event triggers are working "next day or two" I can have all of the widgets jammed into the lib in a week's time. If I need a source editor in the qt world I can just link in KWrite which already does gutter marking and syntax highlighting. Or the lcl stuff can implement it in QT just as it does in GTK.

You guys just keep hammering away the way you are and I will have a QTObject.pp up and running soon. This way we can run whichever we wish with the same code base.

Tonight I added a trace debug window that can be popped up with a message to the lib that shows all of the messages being sent and any implementation errors that occur. This will allow us to view what is going on inside of the lazarus qt widget engine.

There is quite a bit of interest in this library due to the cross language c capability. This should allow most all fo the languages to make good use of the QT library with minimal porting.

Cliff

Shane is there any editors we can just run a linked lib against like I am doing with qt. This would certainly get you down the road very quickly.

http://wxstudio.linuxbox.com/wxs_shot1_linux.gif

How about linking in that editor for our use?.

That of course would mean that you would have a shared lib liblazgtk.so and one for my qt stuff liblazqt.so....

Cliff

I have been sitting quietly at home for about 4-5 days now working on a QT Engine for lazarus. Now before everyone has a fit let me explain a few things here. First of all the GTK library has way to many limitations and is in no way polymorphic like the QT implementation is. I have learned in the last few days just how flexible, stable, fast the QT library is. The QT library has every thing we need to get a successful class library up and running very quickly.

The bad thing or good thing depending on how you look at it is that QT is C++ which means not touchable by FPC. I have a very extendable interface engine that I built especially for use with FPC or any other language for that matter.

Here is a little about how it works....

"Messaging calls to the library"
fpc-message -calls-> C Interface -calls-> LazarusQT Engine -> Perform Message Action on widget in widget list

The C interface to the library is simple
void * IntSendMessage(int Message, char WidgetID,void * Data, int DataType, int DataSize)

so a call to the library to create a button looks like this IntSendMessage(MSG_CREATE_BUTTON_WITH_LABEL,'label1','Hello Button',0,0)

"event hooks calling from the library"
QWidget --> LCL Component WinProc(integer)

The event hook interface which I am completing now looks like this.. ProcEventHook(void * FAddress, char WidgetID)

The event will call a single procedure (per widget) passing a integer as the event that occured.

So in free pascal you can hook a event something like this.

'first hook the event'
ProcEventHook(@WinProc,'label1')

when the label fires a event it will call WinProc and pass the event id.

  procedure WinProc(Message: Integer);
    begin
      case Message of
          MSG_CLICK:    <--then dispatch the call
    end;

This does of course mean that winprock can be overridden and extended as necessary at a component level.

The drawback but not much of one is that widgets have to be defined in the library before use. This is very simple to do only 4 lines of code for most implementations. I was able to add 4 widgets to the engine yesterday in 25 minutes. I have also implemented control reparenting and x, y, height, width layout. In QT everything is a polymorphic decendant of QObject and all layout stuff is at that level. This means that X and Y positioning is gravy.

Just wanting to let everyone know what I am up to. I may be able to realese the base engine to everyone about friday if my wife quits

2 things. First, I am fine with you doing this (and it wouldn't matter if I wasn't :-) ) but try to make it plug in to our code that we have now by using the sendmessage3 calls that already exist, along with a qtinterface object.

Second, I would really like to see some work done getting an editor working like Kassandra or MWEDit. I say we get Kassandra implemented then either work on MWEDIT or continue finishing out IDE.

Shane

>> "Baeseman, Cliff" 10/18/99 09:58AM >>>

I have been sitting quietly at home for about 4-5 days now working on a QT Engine for lazarus. Now before everyone has a fit let me explain a few things here. First of all the GTK library has way to many limitations and is in no way polymorphic like the QT implementation is. I have learned in the last few days just how flexible, stable, fast the QT library is. The QT library has every thing we need to get a successful class library up and running very quickly.

The bad thing or good thing depending on how you look at it is that QT is C++ which means not touchable by FPC. I have a very extendable interface engine that I built especially for use with FPC or any other language for that matter.

Here is a little about how it works....

"Messaging calls to the library"
fpc-message -calls-> C Interface -calls-> LazarusQT Engine -> Perform Message Action on widget in widget list

The C interface to the library is simple
void * IntSendMessage(int Message, char WidgetID,void * Data, int DataType, int DataSize)

so a call to the library to create a button looks like this IntSendMessage(MSG_CREATE_BUTTON_WITH_LABEL,'label1','Hello Button',0,0)

"event hooks calling from the library"
QWidget --> LCL Component WinProc(integer)

The event hook interface which I am completing now looks like this.. ProcEventHook(void * FAddress, char WidgetID)

The event will call a single procedure (per widget) passing a integer as the event that occured.

So in free pascal you can hook a event something like this.

'first hook the event'
ProcEventHook(@WinProc,'label1')

when the label fires a event it will call WinProc and pass the event id.

  procedure WinProc(Message: Integer);
    begin
      case Message of
          MSG_CLICK:    <--then dispatch the call
    end;

This does of course mean that winprock can be overridden and extended as necessary at a component level.

The drawback but not much of one is that widgets have to be defined in the library before use. This is very simple to do only 4 lines of code for most implementations. I was able to add 4 widgets to the engine yesterday in 25 minutes. I have also implemented control reparenting and x, y, height, width layout. In QT everything is a polymorphic decendant of QObject and all layout stuff is at that level. This means that X and Y positioning is gravy.

Just wanting to let everyone know what I am up to. I may be able to realese the base engine to everyone about friday if my wife quits

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

This is a good idea if all we care about is how fast we can get an editor going. But I would personally rather see us get one working with pascal code. We have two very good editors that just need some tweaking to get them working. It might take a little longer, but not all that much since all the editor code is already written. We just need to write some of the supporting code and we are there. But if we start writing parts of Lazarus in C++, then I think we are asking for trouble when it comes time to port to other platforms (my opinion).

But that is a pretty cool editor in that image. I wonder if we could grab some of the code from it and convert it to pascal. It isn't all that hard to convert C code to pascal (C++ might be a little more challenging).

Curtis

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