Andrew Johnson wrote

1st - I am going to start this now - with gtk2, gdkpixbuf is built in,

*cough* uhm. I seem to have underestimated how hard it was going to be to support GTK1 and deprectated widgets, some things are simple enough, some is just time consuming, but there are a few places I cannot figure out how to handle without having both pixmaps and pixbufs, and double up in memory(the worst I think are Window Icon, CList PixData, BitBtn, msg dialogs) so.. I backed up my changes to another dir.. and just changed the geometry routines which were preventing proper loading of the pixmaps and commited ;)

and the other problem looks to be the way we overrride/handle mouse events. so I disabled a few of them. TControl's don't work still.

Trying to run a gtk2 lazarus gives some wierd segfaults I haven't traced yet in widget focus, I think check menu items based on some gtk errors but not sure, but basic widget tests work, if not all examples yet....

Andrew

Alright. For those who wish to help out, there is much that actually seems to work, only a few major areas need working(and a whoooooooole lot a little areas ;)

1st - I am going to start this now - with gtk2, gdkpixbuf is built in, so the current hacks we have to store extra pixmaps and bitmap masks etc is not only broken because of changes in gdk, but redundant and slow(especially on remote displays. which since my laptop is down and out is how I am working) so we need to use just a pixbuf for internal storage, and only create a pixmap or mask as needed which in gtk2 for most of what we do should be almost never, some of this can be done in the gtk1 so that when gdkpixbuf is enabled we use gdkpixbufs for everything, which may also effect(positively) everyone who enables it for gtk1 build as well.

2nd - input is currently broken, not sure all the problems it may be simple but it affects a lot of things, buttons edits memos etc, menus partly work(input doesn't affect them since we don't have any intercepts).

3rd - we need to break out all the complexities in the gtk1 interface for deprecated widgets, so we can override them properly in gtk2. sometimes as was done to make it compile it is simply a matter of creating a wrapper of the gtk2 function name, which does what we already do, sometimes it will be more tricky.

4th - related to the above, we need to get rid of Gtkclist and GtkText for list and memo in the gtk2 interface(perferably with actual {$ifdef GTK1} in the gtk files). these are not only deprecated but quite buggy at times, we should replace them with the far more reliable/featurefull TextView/TreeView which should allow us to be more accurate to the original Delphi anyway, though it will likely require quite a significant amount of work to implement properly.. (volunteers anyone?)

5th - make sure all the little routines are optimized for native gtk2 whenever possible, message dialogs especially, likely can do this easily, but this is important for gtk2 integration because of the standardized(and which is somewhat opposite windows) button layout.

at least 1 & 2 need to be done to make the ide work, plus all the little bugs which will crop up as we go.

please note we should strive as much as possible to abstract version specific things into the gtkproc.pp/.inc files(and if needed create a gtk2proc.pp/.inc), and use lots of {$IFdef GTK1} so before to long we can compile without using any deprecated functions, and so the future GNOME2 interface will be easier to accomplish(I will look into creating the basics extra libs headers as soon as gtk2 interface works).

This will also make the backend code cleaner for supporting features of future version/sub-versions of GTK and GNOME without the same level of changes needed(hopefully).

Andrew

At 19:54 5-9-2003 -0400, Andrew Johnson wrote:

[snip]

I hope that some of those IFDEF GTK1 are temporary ?

I noticed one in TGTKObject.GetCursorpos.
IMO it is complete useless to have defines there. GetCursorpos is virtual and the proper implementation should appear in an overridden TGTK2Object.GetCursorpos.
IMO we have an object model for that, don't pollute it with ifdefs to get another object.

Marc

much of this is temporary. many of these are done this way _because_ the stuff is not easy to override, thus problem #3. as for instance the getcursorpos. that particular routine I was testing, and plan on redoing in gtk2 interface anyway. But for instance that {$IFdef GTK1} and more an {$IfNdef Win32} need to be used around that routine, because in gtk2 almost no X calls should be needed(especially in gtk 2.2) for what we do, and on windows obviously we can't use it. Given that gtk2 is nearly as featurfull on windows as linux nowadays(if quite a bit slower) we will want to disable calls like that etc. When I mean {$IfDef GTK1} I mean around things like this which don't exist, or shouldn't be used in gtk2 interface, not that we won't be overriding them in the gtk2 interface anyway. aka -

TGtkObject.GetCursorPos;
begin
{$Ifdef GTK1}
  the deprecated stuff
  {$IfDef X11}
  X11 specific hack to do this
  {$Else}
    {$IfDef Win32}
     win32 specific hack to do this
    {$Else}
    dummy stuff other workarounds etc.
    {$EndIF}
  {$EndIF}
{$EndIf}
end;
TGtk2Object.GetCursorPos;
begin
{$Ifdef GTK2_2}
gtk2_2 function to do this
{$else}
  gtk2_0 specific workaround
  {$IfDef X11}
  X11 specific hack to do this
  {$Else}
    {$IfDef Win32}
     win32 specific hack to do this
    {$Else}
    dummy stuff other workarounds etc.
    {$EndIF}
{$EndIf}
end;

hopefully not every function will need to be like this, but right now the X vs GTK, widget and widget hacks are so intertwined that overriding for gtk2 or for X11 vs win32 vs maybe framebuffer support later etc is a major pain. And When I say a GTK2 interface I don't mean an overlay on top of the gtk1 which inherits all its deprecated functionaliy, or has hacks for X11. I want the ability to compile lazarus with the gtk2 backend and have it link against the proper libs so we could run anywhere that gtk2 runs. right now thats flat out impossible, in fact its quite plausible that it will only work as well as it does for me with gtk2.2.3 on X114.3 and with pangoxft backend (what I am using).

Also note that much of this is what I said I wanted in proc functions, not in the object hierarchy in the long run. where an issue like this arrises put the version/interface specific functionality into a called function, which is then $IfDef'ed or put into version/os/etc specific includes like the ide has.

Andrew

p.s pardon my inability to be consise and to the point and my in general long windedness. :)

Hi all,

Thanks to Andrew, the gtk2 interface can now be compiled. And I ran the first gtk2 lazarus application without error.
Now it has the same problem as the win32 interface. We need developers to test and fix the bugs. The current gtk2 interface needs special compilation and can not be built with 'make'. See lcl/interfaces/gtk2/README for details. You need the latest gtk2forpascal. cvs is recommended.

Mattias

Andrew Johnson wrote

Alright. For those who wish to help out, there is much that actually seems to work, only a few major areas need working(and a whoooooooole lot a little areas ;)

Just realized that another area which could theoretically be its own project is Pango. Right now we use GdkFont and XLFD Translation, Pango supports a lot more, and is far better supported anyway, we should try and create a Pango String -> XLFD and XLFD -> Pango String conversion to support using either or font style in the font name, so we can easily convert gtk2 interface over to only using pango while still retaining backward compatibility with XLFDs.

The converstion routines probably won't be too hard to do since we already have the current logfont -> XLFD and XLFD description string, but changing everywhere else might be, since we can also use layout for textrect etc, and so forth, and the hacks to get gtk style fonts needs to be updated as well.

Andrew