Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [platform-swt-dev] GTK in CVS

Steve_Northover@xxxxxxx writes:
> The source for the GTK port of SWT is now in CVS.  Finally!

Great! (BTW, I responded to some mail from Boris and Mike Wilson a
couple weeks ago, and @oti.com email addresses were bouncing.)
 
> re GTK Warnings:
> We're having trouble tracking these down.  I can't find the GTK equivalent 
> of the X/Xt error hander (to track exactly when they happen) and I can't 
> create a simple example that causes them. We're only seeing them when 
> running Eclipse. Havoc, any ideas?

It'll probably be a bit before I can try building the whole of Eclipse
on GTK, but here's some general info on the warnings stuff and how to
debug it:

The "Gtk-WARNING" messages come from passing invalid arguments such as
NULL objects to GTK functions; so these indicate a bug in the program,
rather than a recoverable error. Think of them as equivalent to
segmentation faults in seriousness.

There are two common ways to debug them. One is to run a GTK program
with the "--g-fatal-warnings" command line option, which is parsed by
gtk_init(). Programmatically, this will do the following:

   GLogLevelFlags fatal_mask;
	      
   fatal_mask = g_log_set_always_fatal (G_LOG_FATAL_MASK);
   fatal_mask |= G_LOG_LEVEL_WARNING | G_LOG_LEVEL_CRITICAL;
   g_log_set_always_fatal (fatal_mask);

Which results in calling abort() when you get a warning. This means
you will stop in the debugger. You could also just add the above code
instead of using --g-fatal-warnings.

Another way to approach things, if you don't want to abort on the
first warning, is to set a breakpoint on the g_log or g_logv
functions, which are used to print the messages.

Finally, you can set a "log handler" with g_log_set_handler().  This
doesn't let you recover from the error or anything like that, it's
just intended to let you redirect the text of the message elsewhere.

Also of course, typically the warnings do have some meaningful info in
them. If you get "assertion foo != NULL" failed, then that's passing a
NULL pointer where none is allowed; if you get "assertion GTK_IS_FOO()
failed" that usually means you passed in a dangling/garbage pointer,
so it did not contain valid type information.
 
> Areas where we could use input from the GTK community:
> 
> - positioning widgets such that they do not move when the parent is 
> resized (we are using a fixed + hacks)
> 
> - everything to do with redraw, damaged areas, forcing paints, etc.
> 
> - making Display.sleep() work properly
> 

I'll try to check these out in the examples. The Sun guy doing the GTK
AWT peers ended up writing a simple custom widget that was a variant
of fixed, so he could get the desired behavior exactly right.

Havoc


Back to the top