I have a simple(?) question.

Why are you guys using GTK ? (or QT in the future)

Couldn't you just build the LCL directly on the
X-Window API and the Windows-API ?

The reason for using GTK is to have a platform
independant LCL. But therefore we need a platform *dependant* GTK-library. To me GTK is a kind of
Component library for X-Window applications (that is also now ported to support Windows applications).
With LCL, we create a component library based on
another component library.

It's like the Delphi VCL is based upond the good old C++ OWL library from borland.

I think the source for GTK is freely available, so wouldn't it better (easier ?) to port that to Pascal ?

The execution of programs would be faster, it would be easier to create additional components, ...
Maybe it will take more time to develop ???

Pascal

=====

__________________________________________________ Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com

No, that's another story: X-Windows doesn't provide any GUI elements etc. it provies only simple drawing routines.

Interesting. I am not saying it's a bad idea, I just don't understand what that would speed up....... What would make that faster? I guess I don't totally understand.

I feel that the editor problems are what's slowing us up. If we could get someone (other than myself, and preferably 2 or more people) to assist on the editor, once we got that working I think development would cruise for the following reasons:
1) a lot easier to write code with it.
2) People would see that it's actually possible to write code with our library's and perhaps they would help a bit more and 3) Having something that we all use that's built on the LCL would assure that we would fix the LCL and add stuff to it when we needed it.

I think we have to get some folks working on the editor. I we agree with that, and I can get myself, cliff, ??,?,?,?, (3 or 4 others) to put time into JUST the editor, I think we could move quickly and I will create an HTML page for those participating that explains everything that's going on now and excactly when I plan on going.

Can we do that? If after the editor is written and working, we can always discuss the C++ idea. I think that even if we don't think it's a perfect idea to re-write the interface, I think it's still ANOTHER method to do this and perhaps we could do it ALONG with writing the interface in pascal (as we are doing now).

I think we need to CONCENTRATE on the editor and finish it (get it working) so that we feel like we have accomplished something.....PLEASE! :-)

Thoughts? Can we get some folks that would like to concentrate on it? I can start the page design to point out the surrent problems and such...

Shane

>> "Cliff Baeseman" 10/12/99 12:37AM >>>

Hi everyone,

I would like to open up something here for discussion.

How about if we where to do somehting like this to move things along. First a little story, for the last few weeks I have been writing a n-tiered app running off of transaction server. I needed to find a way to communicate with the sever in a very flexible and efficent manner with as few server calls as possible. I also wished to do the development without breaking the COM interface compatibility. Having worked on lazarus for so long I borrowed one of our ideas.

I created a VB dll "Only because it supports ADO better" and this VB object had only one public method call.

Public Function Execute(intMessage as Integer, varData as Variant) as Variant

Now my Delphi GUI Control just calls this execute method for any thing at all it needs to do. For instance in my delphi code I call myRecords = vbdll.Execute(MSG_QUERY, 'SELECT * FROM tbl_Employee') now the VB dll sees that this is a Query and takes the data sent and executes a database sql query and returns a variant array containing the following. myRecords[1] = status "fail or ok" myRecords[2] = statusmessage myrecords[3] row count 4 was field count and then the records.

Now here is where I am going with all of this. Say I was to build a C++ library that could handle all of the UI calls by passing something like IntSendMessage(int Message, int WidgetID, pointer varDataRecord). We then define a single call back routine that would pass back the WidgetID and a event message constant. Now the only single problem that I can see with this is that you would have to have the library to run a lazarus app. On the other hand we can easily code against GTK+ and KDE and NativeWindows using this type of messaging. The linux side of the world would have to be written in C++ but the Windows side of things could be written in a Delphi library very easily. I do not mind writing the C++ library to handle things I am not perfect at writing C++ but can hold my own. I do belive I can get some stuff running very quickly in this fashion. Say for instance we need a source code editor. We have a free one in linux and in windows, we just add that widget to the library and away we go. The lcl would just have to recieve the callback event and pass the message back to the widget ID specified. The only issue I have not figured out is the data type of the sent in message, maybe just a pointer to some data?

What do you think....Putting on the Flame Suit in case that sounded totally stupid.

Cliff

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

Hi everyone,

I would like to open up something here for discussion.

How about if we where to do somehting like this to move things along. First a little story, for the last few weeks I have been writing a n-tiered app running off of transaction server. I needed to find a way to communicate with the sever in a very flexible and efficent manner with as few server calls as possible. I also wished to do the development without breaking the COM interface compatibility. Having worked on lazarus for so long I borrowed one of our ideas.

I created a VB dll "Only because it supports ADO better" and this VB object had only one public method call.

Public Function Execute(intMessage as Integer, varData as Variant) as Variant

Now my Delphi GUI Control just calls this execute method for any thing at all it needs to do. For instance in my delphi code I call myRecords = vbdll.Execute(MSG_QUERY, 'SELECT * FROM tbl_Employee') now the VB dll sees that this is a Query and takes the data sent and executes a database sql query and returns a variant array containing the following. myRecords[1] = status "fail or ok" myRecords[2] = statusmessage myrecords[3] row count 4 was field count and then the records.

Now here is where I am going with all of this. Say I was to build a C++ library that could handle all of the UI calls by passing something like IntSendMessage(int Message, int WidgetID, pointer varDataRecord). We then define a single call back routine that would pass back the WidgetID and a event message constant. Now the only single problem that I can see with this is that you would have to have the library to run a lazarus app. On the other hand we can easily code against GTK+ and KDE and NativeWindows using this type of messaging. The linux side of the world would have to be written in C++ but the Windows side of things could be written in a Delphi library very easily. I do not mind writing the C++ library to handle things I am not perfect at writing C++ but can hold my own. I do belive I can get some stuff running very quickly in this fashion. Say for instance we need a source code editor. We have a free one in linux and in windows, we just add that widget to the library and away we go. The lcl would just have to recieve the callback event and pass the message back to the widget ID specified. The only issue I have not figured out is the data type of the sent in message, maybe just a pointer to some data?

What do you think....Putting on the Flame Suit in case that sounded totally stupid.

Cliff

I totally agree. I'm game. I will be happy to help with the editor. Shane, just let me know what you need me to help with and I will get started working on it.

Curtis

What am I missing here. Isn't this exactly the same thing we are already doing? The only difference is that you have it as an external library instead of linked code. Is that the difference?

The linux side of the world would have to be written in C++ ....

Why??

Shane Miller wrote

I think we need to CONCENTRATE on the editor and finish it (get it working) so that we feel like we have accomplished something.....PLEASE! :-)

I think this should be the first and only goal for the moment.

Get a working editor written with the LCL and USE it to program with.

It is the only way to do things:
1) You'll test the LCL
2) You'll test the editor.
Otherwise you'll never get a decent IDE, in my opinon.

Implementing TCanvas and bitmaps is all nice, but first and formemost the basic components should be working. A decent editor doesn't need anything except an edit box, a notebook to allow multiple documents and some dialogs to do search/cut&paste etc. The coloring stuff can be thrown in as a bonus at a later time...

Michael

Cliff wrote

Well first of all it will gain us access to every widget set on a even ground.

You still lost me here. How is it more even then what we are doing now? We intend to move the code to a method similar to wndproc where all of the signals and messages go through one method for a control. (At least that is what we discussed 2 weeks ago.) That means that all interface units would talk to the LCL and the LCL would talk to them in the exact same manner. Isn't this an even ground?

It would also give us access to all of the C++ libs and there is a bunch of them. Say for instance we needed to load a image to a widget. I could do it inside of the library with just a few simple lines of C++ because of all of the libs that already exist for it.

You have lost me here again. How does this existing C++ library add an image to a GTK widget?

I definately see this as a way to speed along development. Say we wish to use the editor for GEdit or KWrite we can do this with a couple of lines of code in the library to expose the methods.

So why don't you just expose them with Pascal code the same way it has been done for GTK? Why do you need this intermediate C++ library? For that matter there is a gtkeditor widget that we could expose and use now for the editor. It is what gIDE uses and it does everything Shane is trying to do in Pascal. The reason he isn't using it is so that the LCL Editor will be portable to other platforms.

Are you saying that we should move the portability issue out into another set of libraries that are written in C++? I have already been pounded on because I felt that we should rely on the external widget libraries which are written in C. If people want new widgets they have to write them in "C" or add a whole lot more connection to the widget set in the LCL. Are you suggesting now that new features for the LCL will have to be written in C++ in an external library? Then why are we doing any of this in Pascal? Just recreate Builder++ instead.

Before anyone things I am against or shooting down this idea, I am not. It is just that I don't understand the advantages or benefits of it.

I would like someone to look at the editor and add ANYTHING that they can. Currently it is writing to the CANVAS of the form. Eventually I need to change that to write to the canvas of the notebook but the canvas for the notebook isn't quite working yet.

Please feel free to examin the code and add any helpful code. I'll create a html page that can provide help on the editor.

Thanks
Shane

>> Curtis White 10/12/99 09:45PM >>>

I totally agree. I'm game. I will be happy to help with the editor. Shane, just let me know what you need me to help with and I will get started working on it.

Curtis

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

Well first of all it will gain us access to every widget set on a even ground. It would also give us access to all of the C++ libs and there is a bunch of them. Say for instance we needed to load a image to a widget. I could do it inside of the library with just a few simple lines of C++ because of all of the libs that already exist for it. I definately see this as a way to speed along development. Say we wish to use the editor for GEdit or KWrite we can do this with a couple of lines of code in the library to expose the methods.

Now that I think about it a little I would not be suprised if borland did not go this route.

Cliff