Cliff Baeseman wrote

Yep there is still some GTK specific calls in there yet like in menu that stuff has tons of calls to gtk maybe that is what is causing your grief.

Yeah, there are still a lot of dependencies right now. Menus, most of the stuff in StdControls, Notebook, all over the place, really. Unfortunately, I don't know how to go about seperating that stuff myself, as it looks like adding a _lot_ of stuff to the TGtkInterfaceObject (is this correct?). I think I can get an example going with nothing but a form, if I can find a way not to use the units that haven't been split yet. I was under the impression that most things had already been split, but obviously not. It's getting late here, so it will have to wait until tomorrow to try it again. Or, maybe I need to wait until the rest are split? I know Curtis was going to do this soon for the Notebook, but I don't know the schedule for the others. Advice? Should I wait, or trudge on?

Jeff.

Jeffrey A. Wormsley wrote

Or, maybe I need to wait until the rest are split? I know Curtis was going to do this soon for the Notebook, but I don't know the schedule for the others. Advice? Should I wait, or trudge on?

I would say wait. Let learn to walk before we start to run. As you noted with the TColorDialog even with GTK things work fine in Linux but might not work in Windows. Let's try to get all the bugs cleaned up and working with one API before getting things to confused.

IMHO :-)

After looking a bit and vclglobals.pp it seems that the gtk references are truly not needed. There is one place in controls.pp that some variables are declared that need them, but the variables themselves are not used, so if you remove the gtk stuff from the uses clause of controls.pp, then those variable references, everything still compiles as normal.

I have copied the gtkint.pp and it's include files to a stripped down WinAPIint.pp with appropriate include files, as well as modifying the interfaces.pp file. There is no code implemented, just a bare shell of TWinAPIInterface, but it does compile. However, something, somewhere is still calling gtk stuff, because when I run the executable thus produced. I think it's the make file, but will get on this shortly. I hope to at least get a form up this evening, if all goes well.

Jeff.

Yep there is still some GTK specific calls in there yet like in menu that stuff has tons of calls to gtk maybe that is what is causing your grief.

Cliff

Michael A. Hess wrote

I would say wait. Let learn to walk before we start to run. As you noted with the TColorDialog even with GTK things work fine in Linux but might not work in Windows. Let's try to get all the bugs cleaned up and working with one API before getting things to confused.

The only thing I worry about is getting all the way through GTK, debugged, working fine, then finding half of it has to be redone to put in another toolkit. Which would mean yet another round of debugging that may be wasteful. Starting early seemed like a good way to go. As it is right now, everyone is concentrating on linux gtk. Even winbloze gtk is getting something of a short shrift. Since I am much more familiar with the win32 environment than gtk in either flavor, it seemed to make some sense to me to work on that, and hopefully catch anything big along the multi-toolkit lines much earlier in the game.

Jeff.

In fact that's the reason why I'm hesitate to jump into the lazarus project. I don't know a thing about GTK, so I should first look a bit to that library before I could start to participate. It would be much easier for me if I could use win32 api. On the other hand, I like to use lazarus under linux, so finally I should learn GTK a bit, I guess ...

Pascal

_____________________________________________________________ Do You Yahoo!?
Free instant messaging and more at http://messenger.yahoo.com