In the above patch, the Makfile.in's are done that way so that we can compile both gtk and xlib together using configure --with-gtk --with-xlib

r=pavlov

Oh, man does this make a mess of the plugin code. Maybe we need to break this out into plugins for each platform like the xpcom IO code? It's starting to get a little unmaintainable. Comments: What is this "COMPILING_XLIB" define? Shouldn't this be MOZ_WIDGET_XLIB or something? When you are filling out the ws_info structure you are still referencing superwin when you are creating the new mXtBin. Is that right? When you have to fill out the display bits you are using: + ws->depth = xlib_rgb_get_depth(); can't you get that from the parent native window using nsIWidget::GetNativeData() ? Those are my immediate comments.

Response to blizzards comments/suggestions: > Oh, man does this make a mess of the plugin code. Maybe we need to break this> out into plugins for each platform like the xpcom IO code? It's starting to i> get a little unmaintainable. Agreed. Is now really the time to rework the plugins code? Quy said he doesn't mind putting resources to reworking plugins and splitting into platform specific parts, when the time comes. >What is this "COMPILING_XLIB" define? Shouldn't this be MOZ_WIDGET_XLIB or >something? Firstly we've looked at MOZ_WIDGET_XLIB and decided against it. Since if at some stage in the future MOZ_WIDGET_XLIB and MOZ_WIDGET_GTK can be defined at the same time from configure, then the plugin will break. By using a totally separate define, we're removing that possible problem. We could ofcourse just tell people use two separate builds, but so far (over a year) building both at once has been very useful. >When you have to fill out the display bits you are using: > + ws->depth = xlib_rgb_get_depth(); >can't you get that from the parent native window using nsIWidget::GetNativeData() ? Well, looked into GetNativeData but decided to change from the xlibrgb method we orignally used to using the same method gtk uses. (which is not the GetNativeData method). Attached the new patch.

Now that Qt is also being ressurected, I'd like to ask: How does one compile Xlib or Qt ports? I've tried --with-xlib, and it doesn't work. I also tried --enable-toolkit=xlib, but this also konks out, cause there appears to be a dependency on GTK+ in the Plugin code. WHY? How do I get around this?

yeah, taking this too

Xlib port has been removed from trunk (bug 326152) Qt port will be removed soon (bug 380196) -> WONTFIX