QED, but not what you said.
What the explicit admition was that the Java IDE performed quite well enough.
This is what was to have been shown.

QED Jessie is fast enough despite Java.

Sam

Cliff wrote

looked like a pretty good IDE shell to me. The fact that it is written in java makes no difference to me.

Maybe not to you, but many people don't have the Java engine on their machine; so for them it is useless. If you want to target all users, you must make minimal assumptions about the system they use.

And, but this is my personal opinion, java is the worst idea since Napoleon tried to invade Russia. You can maybe use it for web-pages, but that's about it.
(flames to my personal address, please, so we don't pollute the mailing list :) )

Michael.

Borland has released a java jit for linux that is supposed to be very fast.

Cliff

Samuel Liddicott wrote

Because Michael Hess is dead set against it.

Hooooold on!

I am not dead set against windproc. I am against making any of the code WIN32 specific or following a WIN32 design. If you can add windproc without the need of ifdefs and the like to implement it then fine by me. I just don't want to see alot of ifdef stuff being added so that the code will work in a pure WIN32 invironment when we already have lots of tools for doing that already. If the windproc stuff can be added to the base Lazarus classes so that it can be used with a Windows API set well then fine. However, unless I misunderstood something you wanted to add WindProc to work with GTK. Isn't that right? Since that isn't how GTK does the message handling I don't see how you could add doing it using the windproc method that Delphi uses without tying the LCL directly to GTK. If you can show me how, by all means do it.

Here is where you are mistaken. Not PLATFORM independant, WIDGET (API) independent. This is refering to GTK, Qt, wxWindows, XForms, XLib, etc. etc. etc.

In many cases such as GTK, wxWindows this widget sets already have a Windows (WIN32) version which means they would also be platform independant if they adhere to these widget sets.

He thinks supporting wndproc makes it windows dependant, despite the fact I tried to show it is just an extra layer of abstraction and therefore makes it less dependant.

Again maybe I am missing something here. Please show me again how, in code if possible, how you could do this and not tie directly to the widget API.

We can take it off of the mailing list to discuss. Just email me directly.

In a nut shell. You can build open-source with the Qt widget set for free with no charge for Qt. If you ask money for your product, which I do, then you have to pay for a Qt license. I don't believe source is available in either basic case but only if you pay real big bucks.

no flames, but its not like their isn't a java engine for most platforms. And most people don't have gtk for their platforms either but it will be a runtime environment, surely a developer is able to cope with a requirement like this?

It will at least make a good IDE until the lazarus-written one is ready?

Oh well.

Sam

Because Michael Hess is dead set against it.

We have been drawn down in to discussions of WindProc, WinHandles, etc. etc. and it just doesn't need to be talked about or done at this time.

Basically he wants to tie strongly with GTK to get the themes, DnD and Corbra for free (despite the fact it goes against his other well publicised intention to keep things platform independant).

He thinks supporting wndproc makes it windows dependant, despite the fact I tried to show it is just an extra layer of abstraction and therefore makes it less dependant.

anyway.... the form designer as it stands needs wndproc's but it is also compatable with the delphi component/control model.

If we aren't going that route, then the form designer will need redesgning anyway, so its not an issue, and we may as well write a new form designer designed for whatever component model we are using.

Personally speaking, I don't plan on using lazarus at all if it doesn't have a wndproc, my main use will be parallel development on linux/windows.

Sam

Ahh well if you read the web page it indicates that it runs quite fast enough and that Java performance is not a hinderance.

anyway....

Sam

Exactly. This is because it's interpreted, and I don't believe interpreted systems are useful for large projects. Hence my reparm

It is also my opinion, and that of the entire Free Pascal team, that they will have a really hard time getting it to run on Linux by that time. But then, Borland is a professional company, with capable people so...

I do believe that the kassandra team will be able to get a rudimentary IDE with designer up and running by the end of this year, though. As far as I know Sebastian Guenther has the component streaming basically working, the typinfo unit should be bug-free by now, and he has a binary to text converter for streamed objects, so you can import Delphi forms. The rest should be pretty straightforward.

By that time I also plan to have a first working version of TDataset in the FCL, so... seems pretty much like a 'RAD for any developer' to me ?

Competition gets stiff :-)

Borland also teamed up with Corel that means that a QT implementation is what I figure they are going for.

I wouldn't bet on it. There are serious problems with that approach, although it may technically be the preferred one (hell, I would prefer to write a VCL on top of Qt as well, only Free Pascal doesn't allow C++ objects yet), but the study I made shows that this leads to serious problems with e.g. C++ exceptions and so on. Also, don't forget that Object pascal doesn't allow you to declare a C++ object.

In Free Pascal we plan to do support for something like:

TQtObject = Cppclass
   MyField : TMyClass;
   Constructor Create;
   end;

so you can declare and create an object of type TQtObject. if you don't have this you can not instantiate Qt objects yourself, unless you use some C code to do it for you.

But this is for after version 1.0 (which we're trying to get out ASAP, BTW).

Not true, I thought you could get the widget set for free, but not the source ? I may be wrong, however. I'd need to check the new licensing model.

Michael.

My personal opinion (no flames) is blow the lot of them. All we need are mouse/keyboard messages, nested stupid windows and a paint.

Building round gtk (especially without wndproc which I *really* need) is a right pain.

Anyway, now I've got that off my check [no need to respond]

Sam

Building round gtk (especially without wndproc which I *really* need) is a right pain. Anyway, now I've got that off my check [no need to respond]

Why is wndproc still not added if you need it for the form designer ?

Peter

Here is one time when I agree with Sergio I love the language. But make it compiled and it then becomes something of value.

BTW Sergio have you tried the compiled java using the latest GCC... How is the speed.

Cliff

Being win32 specific is different to following win32 design. I am against being win32 specific, but there is nothing wrong with that design.

If you can add windproc without the need of ifdefs and the like to implement it then fine by me.

yep

I just don't want to see alot of ifdef stuff being added so that the code will work in a pure WIN32 invironment when we already have lots of tools for doing that already.

fine

If the windproc stuff can be added to the base Lazarus classes so that it can be used with a Windows API set well then fine.

yep, thats what I want.

However, unless I misunderstood something you wanted to add WindProc to work with GTK. Isn't that right?

Well its either that, or use IFDEF's which you are dead against.

Since that isn't how GTK does the message handling I don't see how you could add doing it using the windproc method that Delphi uses without tying the LCL directly to GTK. If you can show me how, by all means do it.

instead of calling Dispatch, call WndProc and let DefaultWndProc call dispatch. Just like Delphi.
We discussed this but you didn't like it because of the perceived overheads in message handling.

My answer was that:
a) its no issue if there are only a few messages
b) if there are a lot of messages then a lot of something else is going on too which is probably tkaing up even more time, so no-one will know. c) introduce FSkipWndProc into TControl which could be set to TRUE in all controls that don't need wndproc (which would be none of the ones I would use) as a method of postponing the fight till runtime when its hard to tell who won.

any other way requires IFDEF's which
a) we don't want
and
b) won't solve the problem.
We need wndproc in ports of lazarus.

Wndproc gives us widget indepedance. No wndproc ties us to GTK, AND ties us OUT of the Delphi component model.

In many cases such as GTK, wxWindows this widget sets already have a Windows (WIN32) version which means they would also be platform independant if they adhere to these widget sets.

So... you don't really want widget set independance then? No matter. Even under GTK, wndproc is needed, as mentioned it is the ONLY way to intercept messages to a control.

Again maybe I am missing something here. Please show me again how, in code if possible, how you could do this and not tie directly to the widget API.

let wndproc dispatch.

We can take it off of the mailing list to discuss. Just email me directly.

Well I'm happy to let it go now borland have started on their linux tool. What I've said is plain, if it diverges from the current road map I am happy to leave it, but to work, I need it.

Sam

Hello:

I'm having a rough time getting GTK colors working, maybe one of you can help. First, I can't seem to create a drawing area then initialize it's background color. Second, even if I could do that, I'm really hazy on setting a color to draw on that surface. The GC examples I've seen just don't make sense to me (malloc vs. new or maybe some easier way altogether).

Ideally, I'd like to see a code snippet that just has a main window, a container filled with a drawing area, then have it filled with a back-pixmap of a specified color. Then I'd like to draw a line (with code, not mouse) of another color on the surface. Short of a code snippet, any tips or references to lazarus code that does this sort of thing would be great.

TIA!

HankC

... so they implicitly admit that Java performance is not good. QED.

:-)

Michael.

Look at the gtkobject.inc file. There are many examples of this. Look at the procedures called FillRect or DrawText , etc. I am passing the color into the gtk_draw_??? method to modify the colors. Remember, this is PASCAL not C++ but it's really the same.

Shane

>> HankC 09/29/99 03:02PM >>>

Hello:

I'm having a rough time getting GTK colors working, maybe one of you can help. First, I can't seem to create a drawing area then initialize it's background color. Second, even if I could do that, I'm really hazy on setting a color to draw on that surface. The GC examples I've seen just don't make sense to me (malloc vs. new or maybe some easier way altogether).

Ideally, I'd like to see a code snippet that just has a main window, a container filled with a drawing area, then have it filled with a back-pixmap of a specified color. Then I'd like to draw a line (with code, not mouse) of another color on the surface. Short of a code snippet, any tips or references to lazarus code that does this sort of thing would be great.

TIA!

HankC

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

"Baeseman, Cliff" el d�a Wed, 29 Sep 1999
12:15:55 -0500, escribi�:

Here is one time when I agree with Sergio I love the language. But make it compiled and it then becomes something of value.

glad to agree, Cliff :)

BTW Sergio have you tried the compiled java using the latest GCC... How is the speed.

I have not tryed myself, but I've heard good reports, altough support for full java (and 1.2) is not completed yet... more info at http://egcs.cygnus.com/

Sergio

Michael Van Canneyt el d�a Wed, 29 Sep 1999
16:58:03 +0200 (W. Europe Daylight Time), escribi�:

list :) )

I like the way java is used in gcc 2.95.x, ie. like a real languaje (binary compiled)

Sergio

I will not discount looking at it because it is java. But I tend to agree with you. I have tried to write some stuff with Java I like the language. It is a very elegant model. But the performance sucks so bad it will not be of use to me until everyone has a pc that runs in the 2 gigahertz range. "then it will be as fast as C++ code running on a 486 now"

Now tell me the kaylix model or whatever does not already sound like our stuff. Knowing what I know about writing on linux if borland can pull off a mid 2000 release I will be shocked. Maybe they could do it if they did not have to interface with X Windows. X throws in a totally unique set of challenges.

Borland also teamed up with Corel that means that a QT implementation is what I figure they are going for. QT has a more object based model C++ based than GTK which is programmed flatter. I do wish to stay with GTK because we cannot support QT on windows. Troll Tech charges like a 1000 dollars a seat for a windows version QT now that really sucks.

This eliminates the QT widget set for anything open source and cross platform.

Cliff

looked like a pretty good IDE shell to me.

The fact that it is written in java makes no difference to me.

Cliff

But why not have the call back function simply call TControl(self).wndproc or something like that.

For example, once the callback gtkshowCB(widget ... ; Data ...;) is called the code would be....
var
msg : TMessage
begin
TControl(data).wndProc(msg);
end;

Now, the problem I see is that if we have a component that isn't declared from TControl, but we can get around that by checking what type the DATA is.

Shane

>> "Michael A. Hess" 09/30/99 11:39AM >>>

Samuel Liddicott wrote

Michael I am saying we should take the GTK callback handlers we now have (you wrote them?) and have THEM call .wndproc instead of .dispatch.

The problem is, what wndproc does it call? Which control or component is it suppose to call? That is what dispatch does. It is a lower level RTL feature of all classes (objects). The dispatch routine is what routes the call to the correct control (object). In other words if you had a form with 3 buttons on it and a button click message was returned by a GTK button widget, which LCL button does it report to? The message from GTK doesn't know. All it contains is the Self pointer established when the LCL class was created. The only way it can send the message to the correct LCL control is to call dispatch which can determine from the table that FPC creates which LCL object should be called with the message.

That is why I asked whether you want to use a global wndproc or one for every object. A global could be done. One for every object can't easily be done. The only way it could be done would be to attach the GTK call backs directly to the LCL object when it was created. Then the messages from that widget would be returned to the LCL object and that object only. The problem with this is that means we need to link GTK directly to the LCL which then blows away the ability to use WIN32 which is what you are after in the first place. The GTK callback routine must be a CDECL procedure that is NOT part of a class. It can not be a method of a pascal class.

What you would have to do is create a message for the LCL controls (I guess the base class) that is the wndproc method. then you would have to have all messages (signals) that come in from GTK be sent to the Dispatch which would call the wndproc for the correct object. Then this wndproc method would have to have a large case statement to deal with every kind of message that needs to be dealt with.

Does that get you where you want to go?

no, not as such.

or do you invision a WndProc for every control?

yes

If it is one global WndProc how does that differ from what is done now?

interceptability

And if it is for every control how do you invision sending the message to the control?

Very similar to dispatch.

Control.WndProc(Message);

Something like it. I'll try to keep calm.

Because your reason against wndproc is to avoid being like windows which avoids the windows own widget set. I am not exactly against the "GTK only on any GTK platform" approach, I just need wndproc, and want to show wndproc doesn't break anything GTK.

> let wndproc dispatch. Again please show me how this would work with the GTK signal method.

Procedure TControl.WndProc;
begin
  { This is the default wndproc }
  Dispatch(Message);
end;

Although it will probably be more like:

procedure TControl.WndProc(var Message: TMessage);
var
  Form: TForm;
begin
  { **NEEDED FOR FORM DESIGNER** }
  if csDesigning in ComponentState then
    If ParentFormPreview(self,Message) then exit;
  { You can handle dragging some other way if you want }
  if isMouseMessage(Message) then begin
    if Dragging then DragMouseMessage(Message)
  end else { deal with csDoubleClicks in ControlStyle if we really need to}
  else { if dragMode=dmAutomatic etc etc }
  ;
  Dispatch(Message);
end;

This breaks the independence. If you translate GTK to LCL in Interfaces, then the LCL components only ever get LCL messages. You do the same for Win32, you translate Win32 messages to LCL messages in Interfaces. The WindProc in LCL always gets LCL messages, regardless of whether you are using GTK or Win32 or whatever widget set you want.

Now, the problem I see is that if we have a component that isn't declared from TControl, but we can get around that by checking what type the DATA is.

The translation object would have to be different for each component class, I think. A TButton wouldn't need nearly as many callbacks or messages as, say, a TDBLookupCombo. By focusing on just what is needed, you can keep it pretty fast. The limitation is that the application programmer cannot override or attach a handler to something we as LCL/Interface designers did not provide a translation/callback for. That is a limitation already with our GTK, so it is no big deal.

Jeff.

OK, once you have done this, call Control.WndProc
My use of dispatch was refering to TControl.Dispatch (the delphi message dispatcher).
Any GTK dispatch calculations were done in the GTK unit I thought. But yes, look up the control as normal, and then call its wndproc. The wndproc will end up calling the delphi .dispatch which will call all the delphi message handlers.

That is why I asked whether you want to use a global wndproc or one for every object. A global could be done. One for every object can't easily be done.

You manage to calculate the LCL object somehow. All I am saying is call its .wndproc once you have.

What you would have to do is create a message for the LCL controls (I guess the base class) that is the wndproc method. then you would have to have all messages (signals) that come in from GTK be sent to the Dispatch

**** [this must be a different dispatch to the delphi .dispatch - more confusion]

which would call the wndproc for the correct object. Then this wndproc method would have to have a large case statement to deal with every kind of message that needs to be dealt with.

No, because the the .wndproc doesn't do much except call the delphi message dispatcher. but it does do some other things.

Does that get you where you want to go?

nearly.

This is the way delphi works

WINDOWS MESSAGE -> StandardWndProc** -> TXXXControl.WndProc[virtual] -> TXXXControl.Dispatch

StandardWndProc is make using MakeObjectInstance, it is the glue between the winapi and delphi, it is a flat (object-less) routine that calls an object method.

We need a similar glue that takes a GTK callback, looks up the related object (as we do now) and then calls its wndproc.

This is a very slight change to what we do now, but I think the words are getting in the way.

Sam

This is where you lose me. Do you invision one WndProc routine that handles all messages or do you invision a WndProc for every control? If it is one global WndProc how does that differ from what is done now? And if it is for every control how do you invision sending the message to the control?

Do we have a syntax problem in our communication??? A definition of terms problem or what??

I thought I clearly stated above that we are trying to code the LCL so that it doesn't need any given widget set library. We want it to use a variety of libaries. Since these libaries are becoming more and more available on Win32 as well that also makes it platform independent. So exactly where am I stating that I, "don't really want widget set independance"?

let wndproc dispatch.

Again please show me how this would work with the GTK signal method.

Samuel Liddicott wrote

Michael I am saying we should take the GTK callback handlers we now have (you wrote them?) and have THEM call .wndproc instead of .dispatch.

The problem is, what wndproc does it call? Which control or component is it suppose to call? That is what dispatch does. It is a lower level RTL feature of all classes (objects). The dispatch routine is what routes the call to the correct control (object). In other words if you had a form with 3 buttons on it and a button click message was returned by a GTK button widget, which LCL button does it report to? The message from GTK doesn't know. All it contains is the Self pointer established when the LCL class was created. The only way it can send the message to the correct LCL control is to call dispatch which can determine from the table that FPC creates which LCL object should be called with the message.

That is why I asked whether you want to use a global wndproc or one for every object. A global could be done. One for every object can't easily be done. The only way it could be done would be to attach the GTK call backs directly to the LCL object when it was created. Then the messages from that widget would be returned to the LCL object and that object only. The problem with this is that means we need to link GTK directly to the LCL which then blows away the ability to use WIN32 which is what you are after in the first place. The GTK callback routine must be a CDECL procedure that is NOT part of a class. It can not be a method of a pascal class.

What you would have to do is create a message for the LCL controls (I guess the base class) that is the wndproc method. then you would have to have all messages (signals) that come in from GTK be sent to the Dispatch which would call the wndproc for the correct object. Then this wndproc method would have to have a large case statement to deal with every kind of message that needs to be dealt with.

Does that get you where you want to go?

Hi!

That's no problem at all Michael. For example have a look at gtkTimerCB which calls a procedure of the timer-object without using dispatch. (This behaviuor was neccessary for some reason I can't remember now) The only drawback I'm aware of is that it requires the TTimer.Timer procedure to be a public member of the class.

A more elegant way of doing the same thing for each control could look like this:

1. generic Message type for lmessages.pp

  type
  TLM_WndProcMsg = record
     msg     : integer;
     realMsg : integer;
     userdata: pointer;
  end;

2. A class

  interface
  TControl = class (TComponent)
    constructor Create (aOwner : TComponent); override;
    procedure  WindProc (var msg); message LM_WindProc;
  end;
  implementation
  constructor TControl.Create (aOwner : TComponent);
  begin
     inherited Create (aOwner);
     SetCallback (LM_WindProc);
  end;
  procedure TControl.WindProc (var msg : TLM_WndProcMsg);
  begin
    // do the stuff & Dispatch
  end;

3. A callback

  Procedure SomeCallback (var widget; data : Pointer);
  var MessI : TLM_WndProcMsg;
  begin
      MessI.msg      := LM_WindProc;
      MessI.realMsg  := LM_SomeMessage;
      MessI.UserData := data;
      TObject (data).Dispatch (MessI);
  end;

Another approach could be to make TControl.WindProc a function, and in the callback we could the decide if we have to dispatch "realMsg" from also from the callback or if windproc already did everthing;

bye,

Stefan

PS: Reading this again I'm not sure if this approach works because I don't know if a message function can be virtual. Can it?

Michael A. Hess wrote

The GTK callback routine must be a CDECL procedure that is NOT part of a class. It can not be a method of a pascal class.

How does the Interfaces unit handle this requirement? (I don't have code here at work to look)

This helps me see where we are confused.
Thanks.

Michael I am saying we should take the GTK callback handlers we now have (you wrote them?) and have THEM call .wndproc instead of .dispatch.

This would work too. I had imagined.

sed -e "s/\.dispatch/.wndproc/g" as the solution.

The LCL message would be recieved by the "WindProc" and handled appropriately.

Most of which would call .dispatch almost right away.

This differs from the current implementation by adding a layer to the component that handles the messages before dispatch, rather than having the Interfaces unit handle it directly.

yep. Nice abstraction.

that is what I mean, but the reason for wanting this is not to support the windows widget set (tho as Michael says he doesn't want to be widget-set dependant I would think he woould want this), but because too many delphi program depend.

It is, as I made clear in earlier discussions; but I don't see we need that much abstraction in implementing this. The current gtk until (which intergaces GTK to LCL) which receives the callback can just call .wndproc and all will be fine.

Don't take the above as a recommendation on how to do things. It is just an example of one way that should be feasable. I have started again on another method, which is making Win32 look like GTK.

Good luck.

Sam

Just to jump in a sec, while that does give "platform independence" it is a very sub-optimal solution, since you have to distribute the widget set DLL's with every win32 app. Vey VB'ish there (but then again, even Delphi succombed to the 'package' thing).

> let wndproc dispatch. Again please show me how this would work with the GTK signal method.

GTK signals are just function callbacks, correct? Instead of being redirected through a messaging system, they are called directly by the widget.

A GTK "windproc" could be set up be creating an object at component creation time that had all of the callbacks for that component, assign the appropriate ones to the widget, then when the widget called the callback (sic) it would send a LCL message with SendMessage. The LCL message would be recieved by the "WindProc" and handled appropriately. This differs from the current implementation by adding a layer to the component that handles the messages before dispatch, rather than having the Interfaces unit handle it directly.

In the Win32 world, the interfacing object would be slightly different. Instead of having the callbacks, it would have a "true" (in the Windows sense) WindProc routine. This routine would recieve the windows messages, translate them to LCL messages, and send them to the "WindProc" of the component.

This way, all messages recieved by the component are the same, regardless of widget set or platform.

Something like this:

LCL Object (GTK)
WindProc
CallBackObject

LCL Object (Win32)
WindProc
MessageTranslator

The difference between the CallBackObject for GTK and the MessageTranslator for Win32 would be hidden in the Interfaces unit, which maintains the widget and platform independence. So a more accurate diagram would be:

LCL Object (GTK)
WindProc
Interfaces (GTK)
CallBackObject

LCL Object (Win32)
WindProc
Interfaces (Win32)
MessageTranslator

There are two drawbacks that I can see to this. One, is it adds an extra layer to every widget set used. I really don't see that as huge, but it is there. Second, the CallBackObject and MessageTranslator will likely be different for each component, or at least component class, which will mean a lot of work generating them, on top of the normal component work. Especially difficult will be mapping each widget set into a generic LCL set of behaviors. It will mean programming to the lowest common denominator of all supported widget sets. I believe that is the price you pay for widget set independence.

Don't take the above as a recommendation on how to do things. It is just an example of one way that should be feasable. I have started again on another method, which is making Win32 look like GTK.

Jeff.